View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002021||Xdebug||Step Debugging||public||2021-09-23 19:14||2021-10-04 09:29|
|Target Version||3.1dev||Fixed in Version||3.1.0|
|Summary||0002021: Segmentation fault due to NULL bytes in internal anonymous class names|
#0 0x00007fb913a0ce87 in strlen () from /lib/ld-musl-x86_64.so.1
|Steps To Reproduce|
Working through a simplified use case still. Currently triggering why trying to write/debug tests in Drupal phpunit test suite. The twig template class name in the backtrace and the null filename suggest to me maybe there's some sort of dynamic class involved.
Seems similar/duplicate of the earlier issue 0001407? That rightfully asked for a test case so I'll get one.
Running in alpine container but musl is def a less common runtime so i'll try to get the test case running in ubuntu as well.
|Tags||No tags attached.|
This debug_print_backtrace() seems to support the assumption this is connected to a dynamic class. There's an eval in the stack. That eval is running a generated.
+'#0 Drupal\Core\Template\TwigSandboxPolicy->checkMethodAllowed() called at [/app/vendor/twig/twig/src/Extension/SandboxExtension.php:84]\n
simplified test case
Realized I'd seem something similar a while back doing weird things with prophecy mocks which lead me to work out a simplified test case for a similar crash in xdebug_dbgp_breakpoint
This has really been frying my brain trying to get failing on my ubuntu install. Digging in further though maybe I can give more info as to maybe why but this is getting out of my ability to debug.
I started stepping through the code more inside the alpine container. I was sort of following the wrong rabbit hole for a bit because on the latest code its actually failing on 389 and tmp_filename is null since its eval but we're in the wrong code branch.
So started digging in more, clearly check_evaled_code should not have let the code get here for the eval statement. cloned xdebug, built without optimizations and started stepping through and... no error. Everything ran cleanly without a segfault. Turned on -O2 and back to a segfault. O boy, the best sort of bugs, compiler optimizations.
So started digging into check_evaled_code and I can see this.
So the string comparison should work and it seems like maybe the >= is being broken? Now, my C is a bit rusty so I'm drawing a blank on how that >= would behave with char* and what its trying to accomplish but it seems like its being optimized in some way that's breaking the expectation.
Since it seems like we're into compiler quirks, my ubuntu environment has gcc 10.3.0 and the alpine environment i'm testing this in is 9.3.0.
I've tracked this down to a different cause that you stipulated, although I can see how you came to that conclusion.
PR is going to be on the way with a test case, and a fix for a different issue in a moment, and this will be part of 3.1.0.
|2021-09-23 19:14||neclimdul||New Issue|
|2021-09-23 19:25||neclimdul||Note Added: 0006045|
|2021-09-23 19:28||neclimdul||Note Added: 0006046|
|2021-09-23 19:28||neclimdul||File Added: eval_segfault.php|
|2021-09-23 19:55||neclimdul||Note Added: 0006047|
|2021-09-23 19:55||neclimdul||File Added: eval_segfault2.php|
|2021-09-27 17:24||neclimdul||Note Added: 0006052|
|2021-10-01 12:24||derick||Target Version||=> 3.1dev|
|2021-10-01 12:24||derick||Summary||Segmentation fault in return_stackframe => Segmentation fault due to NULL bytes in internal anonymous class names|
|2021-10-01 12:24||derick||Note Added: 0006064|
|2021-10-01 16:21||derick||Note Added: 0006069|
|2021-10-01 16:52||derick||Assigned To||=> derick|
|2021-10-01 16:52||derick||Status||new => closed|
|2021-10-01 16:52||derick||Resolution||open => fixed|
|2021-10-01 16:52||derick||Fixed in Version||=> 3.1dev|
|2021-10-04 09:29||derick||Fixed in Version||3.1dev => 3.1.0|