More details: it seems it happens on conditional BPs, but not straight from the start; I think it happens when it hits a conditional BP after an unconditional BP, or something of sorts.

Seems there's a 0000020:0000020% chance of triggering this bug by adding a conditional breakpoint

Hi,

I can't quite think what has changed here, but can you provide more information? https://xdebug.org/support.php#remote lists exactly what I would need.

cheers,
Derick

I added crash report as "private" (because of old habit). I don't know Mantis, if you don't get a notification it's https://bugs.xdebug.org/view.php?id=1647#c4957

Additional note: only happens on conditional breakpoint; removing the condition, it works.

I'm running into a similar problem when debugging an old Magento version with the PHP 7.3.3 and XDebug 2.7.0. I have the OpCache turned off (it crashes, too, when it's turned on).

I ran GDB with a breakpoint on the final write() call which sends the "zend_mm_heap corrupted" to get the backtrace. This is what I get

#0 write () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007f6330f2c0b3 in _IO_new_file_write (f=0x7f63312791c0 <_IO_2_1stderr>, data=0x7fff9594c0c0, n=23) at fileops.c:1258
0000002 0x00007f6330f2c950 in new_do_write (to_do=<optimized out>, data=0x7fff9594c0c0 "zend_mm_heap corrupted\n", fp=0x7f63312791c0 <_IO_2_1stderr>) at fileops.c:519
0000003 _IO_new_file_xsputn (f=0x7f63312791c0 <_IO_2_1stderr>, data=<optimized out>, n=23) at fileops.c:1337
0000004 0x00007f6330effd4d in buffered_vfprintf (s=s@entry=0x7f63312791c0 <_IO_2_1stderr>, format=format@entry=0x55e5f897a068 "%s\n", args=args@entry=0x7fff9594e6f8) at vfprintf.c:2340
0000005 0x00007f6330efa69e in _IO_vfprintf_internal (s=s@entry=0x7f63312791c0 <_IO_2_1stderr>, format=format@entry=0x55e5f897a068 "%s\n", ap=ap@entry=0x7fff9594e6f8) at vfprintf.c:1289
0000006 0x00007f6330fc7565 in _fprintf_chk (fp=0x7f63312791c0 <_IO_2_1stderr>, flag=flag@entry=1, format=format@entry=0x55e5f897a068 "%s\n") at fprintf_chk.c:36
0000007 0x000055e5f86c1d88 in fprintf (fmt=0x55e5f897a068 "%s\n", __stream=<optimized out>) at /usr/include/bits/stdio2.h:97
0000008 zend_mm_panic (message=0x55e5f89ddc23 "zend_mm_heap corrupted") at /usr/src/debug/php-7.3.3/Zend/zend_alloc.c:353
0000009 0x000055e5f88a9d31 in zend_mm_free_heap (ptr=<optimized out>, heap=<optimized out>) at /usr/src/debug/php-7.3.3/Zend/zend_alloc.c:1402
0000010 _efree (ptr=<optimized out>) at /usr/src/debug/php-7.3.3/Zend/zend_alloc.c:2515
0000011 0x00007f63282b35d9 in xdebug_brk_info_dtor () from /opt/remi/php73/root/usr/lib64/php/modules/xdebug.so
0000012 0x00007f63282b3807 in xdebug_llist_remove () from /opt/remi/php73/root/usr/lib64/php/modules/xdebug.so
0000013 0x00007f63282b3904 in xdebug_llist_empty () from /opt/remi/php73/root/usr/lib64/php/modules/xdebug.so
0000014 0x00007f63282b3929 in xdebug_llist_destroy () from /opt/remi/php73/root/usr/lib64/php/modules/xdebug.so
0000015 0x00007f63282b288b in xdebug_dbgp_deinit () from /opt/remi/php73/root/usr/lib64/php/modules/xdebug.so
0000016 0x00007f632829fd77 in zm_post_zend_deactivate_xdebug () from /opt/remi/php73/root/usr/lib64/php/modules/xdebug.so
0000017 0x000055e5f88d516a in zend_post_deactivate_modules () at /usr/src/debug/php-7.3.3/Zend/zend_API.c:2701
0000018 0x000055e5f886e145 in php_request_shutdown (dummy=dummy@entry=0x0) at /usr/src/debug/php-7.3.3/main/main.c:1930
0000019 0x000055e5f86d3c4b in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/php-7.3.3/sapi/fpm/fpm/fpm_main.c:1978

When I look at the remote debug log the last items I get are:

[180867]
[180867] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="run" transaction_id="16" status="stopping" reason="ok"></response>
[180867]
[180867] <- run -i 17
[180867] Log closed at 2019-03-13 21:36:20
[180867]

When I strace the process the last thing I see before the error is the "run" command.

BUT!!!!

Now suddenly it's working after not working for the past day. I turned off the remote log and suddenly it's working. And I don't know why. I turned on the Opcache and it's working too, now. Flummoxed.

But I'll leave the backtrace there in case it helps. If not, feel free to delete this note.

I, too, feel this and https://bugs.xdebug.org/view.php?id=1649 are somehow related: I noticed both after installing 2.7.0 and always in immediate proximity in the FPM log files. Could it be that on the pipe work you did for allowing Xdebug to work with fork() you are breaking some of the handles you use for logging/communication?

I don't thinks so for my experience. I started, stopped, restarted, and did a number of things over again. The only thing that triggered this for me was running "yum update". The only thing that seems to have fixed it was restarting AFTER I had run gdb and subsequently disabled the remote log to do another strace. It's weird.

yes, previous note was @derick.
From what I read, one of the biggest changes in 2.7 is supporting fork() -ing, which in turn was not working properly because of some pipe communication issues.
From the weird behavior we are seing, and your report that it was fixed after turning off logging (i.e. a seemingly completely unrelated I/O process), and my report that logging seems to just fail without reason, I was hypothesizing that this irregular behavior might be related to some pipes being broken or badly forwarded between processes for IPC.

... and now it's not working for me again. I did a few successful debugs last night then went away, I came back this morning and it's happening again! It looks like my VM might have restarted.

Then I went into my 15-xdebug.ini file, turned on remote_logging and restarted PHP-FPM

I debugged a request and it worked.

Then I went into my 15-xdebug.ini file, turned remote_logging off and restarted PHP-FPM

I debugged a request and it continued to work.

... and then it stops working. And this time I get the strace

write(5, "188\0<?xml version=\"1.0\" encoding"..., 193) = 193
munmap(0x7f567faa1000, 258048) = 0
sendto(9, "\1\0\0\0\1", 5, MSG_DONTWAIT, NULL, 0) = 5
close(9) = 0
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={30, 0}}, NULL) = 0
write(4, "[24939] -> <response xmlns=\"urn:"..., 184) = 184
write(5, "208\0<?xml version=\"1.0\" encoding"..., 213) = 213
recvfrom(5, "run -i 68\0", 128, 0, NULL, NULL) = 10
write(4, "[24939] <- run -i 68\n", 21) = 21
write(2, "zend_mm_heap corrupted\n", 23) = 23
exit_group(1) = ?

Incidentally, the same issue with xdebug 2.7 happens on PHP 7.2.16 as well. In the yum update I did recently it also updated xdebug to 2.7 for PHP 7.2 with the same issue. Downgrading to 2.6.1 works as a temporary fix on PHP 7.2 for me.

It triggers for me as well when I use conditional BPs. But there are more conditions to be revealed, as using a conditional BP itself doesn't necessary lead to the crash.
(And I use apache with mod_php, not fastcgi.)

I can reproduce this easily now, with your script dinu.

Fixed in GIT for Xdebug 2.7.1.

Cool, thanks! Can this be related to the logging problem related in https://bugs.xdebug.org/view.php?id=1649 ?
So I know if I should try to reproduce that when I find some time or forget about it.

No dinu, that seems unrelated.