View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001626||Xdebug||Step Debugging||public||2019-02-07 04:31||2019-02-14 15:26|
|Summary||0001626: Segmentation fault when superglobal query is run|
When trying to debug a local script a segmentation faults would occur. After pairing down the code I was able to make the segmentation fault occur at multiple locations. The simplest case is below. I believe it is similar to ticket 1625
|Steps To Reproduce|
$clientID = 1234;
When running the test file it would correctly enter the breakpoint. However if you click on the
PHP 7.3.1 (cli) (built: Jan 10 2019 13:15:37) ( NTS )
|Tags||No tags attached.|
thanks for this report. I can unfortunately not reproduce this. When locally the context_get -c 1 is run (for Superglobals) I get a right answer, and valgrind is silent too. It's a pity that GDB didn't produce anything useful, as it would have been really handy right now. I don't have a mac to try myself either.
From https://stackoverflow.com/questions/49001329/gdb-doesnt-work-on-macos-high-sierra-10-13-3 it seems that your gdb is too new, and you might need to downgrade to 8.0.1 — and that link also suggest that you temporarily turn off SIP as is described at https://www.imore.com/how-turn-system-integrity-protection-macos
Would you please mind trying these things?
I've tried a few things, including the links provided, with gdb without much success. I was however able to get something to trigger using lldb.
Process 39156 stopped
Is this helpful? I will continue to look into getting gdb working since that seems to be the main debugger being used.
Is there any additional logging I can turn on for local debugging?
that's a bit closer. It's possible that because there are no debugging symbols, we don't get to see the exact line and arguments. As I don't have access to OSX, and never have used lldb, it is a bit tricky for me to suggest how to do debug this.
The following might do the trick:
cd /tmp (or any other tmp directory)
(this does nearly the same as PECL would do, but adds the --enable-xdebug-dev options that add debugging symbols to xdebug).
Then try triggering the issue with lldb again. It hopefully shows more information. On the lldb prompt, perhaps you can do:
show values in the current stack frame:
And do that for frame 1 and 2 too:
I'm closing this out as "duplicate" for now.
|2019-02-07 04:31||deek||New Issue|
|2019-02-07 04:31||deek||File Added: Screen Shot 2019-02-06 at 8.25.16 PM.png|
|2019-02-11 17:06||derick||Relationship added||has duplicate 0001627|
|2019-02-11 17:13||derick||Note Added: 0004883|
|2019-02-11 17:13||derick||Assigned To||=> derick|
|2019-02-11 17:13||derick||Status||new => feedback|
|2019-02-11 19:24||deek||Note Added: 0004886|
|2019-02-11 19:24||deek||Status||feedback => assigned|
|2019-02-12 13:52||derick||Note Added: 0004889|
|2019-02-12 13:52||derick||Status||assigned => feedback|
|2019-02-12 16:01||derick||Note Added: 0004891|
|2019-02-12 16:01||derick||Relationship added||duplicate of 0001625|
|2019-02-12 16:01||derick||Status||feedback => resolved|
|2019-02-12 16:01||derick||Resolution||open => duplicate|
|2019-02-14 15:26||derick||Relationship deleted||has duplicate 0001627|
|2020-03-12 16:33||derick||Category||Remote Debugging => Step Debugging|