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
+#1 Twig\Extension\SandboxExtension->checkMethodAllowed() called at [/app/vendor/twig/twig/src/Extension/CoreExtension.php:1505]\n
+0000002 twig_get_attribute() called at [/app/vendor/twig/twig/src/Environment.php(418) : eval()'d code:39]\n
+0000003 __TwigTemplate_0279bfe316a0f801ca5ed61604c97480866742f477ee94f97f0117d5b7591e33->doDisplay() called at [/app/vendor/twig/twig/src/Template.php:405]\n
+0000004 Twig\Template->displayWithErrorHandling() called at [/app/vendor/twig/twig/src/Template.php:378]\n
+0000005 Twig\Template->display() called at [/app/vendor/twig/twig/src/Template.php:390]\n
+0000006 Twig\Template->render() called at [/app/vendor/twig/twig/src/TemplateWrapper.php:45]\n
+0000007 Twig\TemplateWrapper->render() called at [/app/vendor/twig/twig/src/Environment.php:318]\n
+0000008 Twig\Environment->render() called at [/app/core/tests/Drupal/Tests/Core/Template/TwigSandboxTest.php:244]\n
+0000009 Drupal\Tests\Core\Template\TwigSandboxTest->testOverrideCollision() called at [/app/sites/simpletest/TestCase.php:1474]\n
+0000010 PHPUnit\Framework\TestCase->runTest() called at [/app/sites/simpletest/TestCase.php:1094]\n
+0000011 PHPUnit\Framework\TestCase->runBare() called at [/app/vendor/phpunit/phpunit/src/Framework/TestResult.php:703]\n
+0000012 PHPUnit\Framework\TestResult->run() called at [/app/sites/simpletest/TestCase.php:822]\n
+0000013 PHPUnit\Framework\TestCase->run() called at [/app/vendor/phpunit/phpunit/src/Framework/TestSuite.php:627]\n
+0000014 PHPUnit\Framework\TestSuite->run() called at [/app/vendor/phpunit/phpunit/src/Framework/TestSuite.php:627]\n
+0000015 PHPUnit\Framework\TestSuite->run() called at [/app/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:656]\n
+0000016 PHPUnit\TextUI\TestRunner->doRun() called at [/app/vendor/phpunit/phpunit/src/TextUI/Command.php:235]\n
+0000017 PHPUnit\TextUI\Command->run() called at [/app/vendor/phpunit/phpunit/src/TextUI/Command.php:194]\n
+0000018 PHPUnit\TextUI\Command::main() called at [/app/vendor/phpunit/phpunit/phpunit:92]\n

simplified test case

<?php

class foo {
    function test() {
      xdebug_break();
    }
}

eval('(new foo)->test();');

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

<?php

eval('
class foo {
  protected $foo = "bar";
  public function bar() {
    xdebug_break();
    echo $this->foo;
  }
}
');

$tmp = new class() extends foo {
  function baz() {
    // step into this.
    $this->bar();
  }
};
$tmp->baz();

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.

461     end_marker = ZSTR_VAL(filename_in) + ZSTR_LEN(filename_in) - strlen("eval()'d code");
(gdb) n
462     if (end_marker >= ZSTR_VAL(filename_in) && strcmp("eval()'d code", end_marker) == 0) {
(gdb) info locals
end_marker = 0x7f76c486e1ee "eval()'d code"
ei = 0x558b4d2cfa40
(gdb) p (int) strcmp("eval()'d code", end_marker)
$1 = 0

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.

Hi,

I've tracked this down to a different cause that you stipulated, although I can see how you came to that conclusion.
Thanks for the short and succinct reproducible case.

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.

cheers,
Derick

https://github.com/xdebug/xdebug/pull/791