Observed variable #0 has invalid type 192 [(null)]

[niden]

I am experiencing a "weird" behavior. Running the test suite on v4 branch (my fork) produces errors in travis.

https://travis-ci.org/niden/cphalcon/jobs/492392066#L4269

Initially the errors pointed to xdebug but continued after disabling it

- CreateRequestCest: Test Http\Message\RequestFactory - createRequest()zephir_memory_restore_stack_common: observed variable #0 (0x7fff77ed6730) has invalid type 192 [(null)]
zephir_memory_restore_stack_common: observed variable #1 (0x7fff77ed6750) has invalid type 240 [(null)]
zephir_memory_restore_stack_common: observed variable #2 (0x7fff77ed6720) has invalid type 32 [(null)]
#0  0x7fb3984d56c7 [/home/travis/.phpenv/versions/7.2.15/lib/php/extensions/no-debug-zts-20170718/phalcon.so(zephir_print_backtrace+0x40) [0x7fb3984d56c7]]

The test that fails is:

use Phalcon\Http\Message\RequestFactory;
use Psr\Http\Message\RequestInterface;
use UnitTester;

/**
 * Class CreateRequestCest
 */
class CreateRequestCest
{
    /**
     * Tests Phalcon\Http\Message\RequestFactory :: createRequest()
     *
     * @param UnitTester $I
     *
     * @author Phalcon Team <team@phalconphp.com>
     * @since  2019-02-10
     */
    public function httpMessageRequestFactoryCreateRequest(UnitTester $I)
    {
        $I->wantToTest('Http\Message\RequestFactory - createRequest()');
        $factory = new RequestFactory();
        $request = $factory->createRequest('https://dev.phalcon.ld', 'GET');
        $class   = RequestInterface::class;
        $I->assertInstanceOf($class, $request);
    }
}

and the underlying zephir code is:

    /**
     * Create a new request.
     */
    public function createRequest(string method, var uri) -> <RequestInterface>
    {
    	var factory;

		let factory = new Request(uri, method);

		return factory;
    }

and the Request is:

	public function __construct(var uri = null, string method = null, var body = "php://temp", array headers = [])
	{

	}

[danhunsaker]

Pretty sure this is tied to the fact Travis only provides ZTS versions of PHP, which aren't exactly stable, still. Hence why none of the major distros ship it, preferring the non-thread-safe (NTS) builds instead. I'm guessing this isn't an issue you see locally?

[niden]

Yes locally all tests pass just fine :/

[danhunsaker]

Then yeah, it's almost certainly a ZTS bug.

[ruudboon]

Is there a workaround to run Travis non-thread-safe so it's not blocking development?
@danhunsaker I see your pull here (travis-ci/php-src-builder#24) is this something we have to wait for to get integrated?

[danhunsaker]

Build it ourselves, and yes, respectively.

[sergeyklay]

backtrace

#0  0x00007fffe86da869 in zend_gc_refcount (p=0x1e) at /home/klay/.phpenv/versions/7.3.0-zts-debug/include/php/Zend/zend_types.h:981
#1  0x00007fffe86da901 in zval_refcount_p (pz=0x7fffffffa5d0) at /home/klay/.phpenv/versions/7.3.0-zts-debug/include/php/Zend/zend_types.h:1015
#2  0x00007fffe86db006 in zephir_memory_restore_stack_common (g=0x1b5ea60) at /home/klay/workspace/c/zephir-issue-1802/ext/kernel/memory.c:159
#3  0x00007fffe86db50a in zephir_memory_restore_stack (func=0x0) at /home/klay/workspace/c/zephir-issue-1802/ext/kernel/memory.c:259
#4  0x00007fffe86f2083 in zim_Issue1802_Factory_createRequest (execute_data=0x7fffed4220f0, return_value=0x7fffed4220d0) at /home/klay/workspace/c/zephir-issue-1802/ext/issue1802/factory.zep.c:47
#5  0x0000000000ce8b06 in ZEND_DO_FCALL_SPEC_RETVAL_USED_HANDLER () at /tmp/php-build/source/7.3.0/Zend/zend_vm_execute.h:1102
#6  0x0000000000d5b40e in execute_ex (ex=0x7fffed422030) at /tmp/php-build/source/7.3.0/Zend/zend_vm_execute.h:55442
#7  0x0000000000d60af0 in zend_execute (op_array=0x7fffed484300, return_value=0x0) at /tmp/php-build/source/7.3.0/Zend/zend_vm_execute.h:60834
#8  0x0000000000c7541d in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /tmp/php-build/source/7.3.0/Zend/zend.c:1568
#9  0x0000000000baea60 in php_execute_script (primary_file=0x7fffffffc3e0) at /tmp/php-build/source/7.3.0/main/main.c:2630
#10 0x0000000000d63b4a in do_cli (argc=4, argv=0x19c1f80) at /tmp/php-build/source/7.3.0/sapi/cli/php_cli.c:997
#11 0x0000000000d64f95 in main (argc=4, argv=0x19c1f80) at /tmp/php-build/source/7.3.0/sapi/cli/php_cli.c:1389

[sergeyklay]

In C (Zend Engine) the string data type is not scalar type. It is complex type. So we have to grow memory stack to handle each complex variable. Besides this we must free the memory. I researched your Request class and saw that you pass a string variable to the constructor, but do not use it.

class Request implements RequestInterface
{
  public function __construct(var uri = null, string method = null, var body = "php://temp", array headers = [])
  {
  }
}

After this fix

class Request implements RequestInterface
{
+  protected method;

  public function __construct(var uri = null, string method = null, var body = "php://temp", array headers = [])
  {
+    let this->method = method;
  }

}

the problem was resolved

[danhunsaker]

Seems like the kind of thing we'd want to detect during generate, so we can either optimize the code we generate to skip handling values that aren't used, or to at least warn the dev that they need to use such variables in order to prevent runtime crashes. I'd probably do both, personally.