View Issue Details

IDProjectCategoryView StatusLast Update
0001647XdebugUncategorizedpublic2019-03-21 20:43
Reporterdinu Assigned Toderick  
Status closedResolutionfixed 
Platformphp7 + php-fpmOSCentOS 
Product Version2.7.0 
Target Version2.7.1Fixed in Version2.7.1 
Summary0001647: Memory corruption when a conditional breakpoint is used

Only with 2.7.x (0 and RC2 tested), 2.6.1 doesn't exhibit the same behavior.
I am using Eclipse on the receiving end, with xdebug.remote_host=
Breakpoints generally work, but after setting some breakpoints, I had this error:

[08-Mar-2019 03:42:12] WARNING: [pool www] child 15249 said into stderr: "zend_mm_heap corrupted"
[08-Mar-2019 03:42:12] WARNING: [pool www] child 15249 exited with code 1 after 3.841827 seconds from start

Reproducible 100%, on every request. by removing the breakpoints, it works again. Other breakpoints work, I can't produce a minimal TC because I don't know which breakpoint was triggering the error.

TagsNo tags attached.
Operating System
PHP Version7.2.10-7.2.14



2019-03-09 09:45

reporter   ~0004950

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.


2019-03-10 14:21

reporter   ~0004951

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


2019-03-10 16:48

administrator   ~0004953


I can't quite think what has changed here, but can you provide more information? lists exactly what I would need.



2019-03-12 16:16

reporter   ~0004958

I added crash report as "private" (because of old habit). I don't know Mantis, if you don't get a notification it's


2019-03-12 16:20

reporter   ~0004959

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


2019-03-13 21:46

reporter   ~0004963

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/
0000012 0x00007f63282b3807 in xdebug_llist_remove () from /opt/remi/php73/root/usr/lib64/php/modules/
0000013 0x00007f63282b3904 in xdebug_llist_empty () from /opt/remi/php73/root/usr/lib64/php/modules/
0000014 0x00007f63282b3929 in xdebug_llist_destroy () from /opt/remi/php73/root/usr/lib64/php/modules/
0000015 0x00007f63282b288b in xdebug_dbgp_deinit () from /opt/remi/php73/root/usr/lib64/php/modules/
0000016 0x00007f632829fd77 in zm_post_zend_deactivate_xdebug () from /opt/remi/php73/root/usr/lib64/php/modules/
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] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="; command="run" transaction_id="16" status="stopping" reason="ok"></response>
[180867] <- run -i 17
[180867] Log closed at 2019-03-13 21:36:20

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


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.


2019-03-13 21:53

reporter   ~0004964

I, too, feel this and 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?


2019-03-13 22:22

reporter   ~0004965

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.


2019-03-14 03:17

reporter   ~0004966

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.


2019-03-14 14:37

reporter   ~0004967

... 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.


2019-03-14 15:13

reporter   ~0004968

... 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) = ?


2019-03-14 15:32

reporter   ~0004969

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.


2019-03-20 14:24

reporter   ~0004971

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.)


2019-03-21 12:49

administrator   ~0004972

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


2019-03-21 14:11

administrator   ~0004973

Fixed in GIT for Xdebug 2.7.1.


2019-03-21 14:31

reporter   ~0004976

Cool, thanks! Can this be related to the logging problem related in ?
So I know if I should try to reproduce that when I find some time or forget about it.


2019-03-21 20:43

administrator   ~0004977

No dinu, that seems unrelated.

Issue History

Date Modified Username Field Change
2019-03-08 01:56 dinu New Issue
2019-03-09 09:45 dinu Note Added: 0004950
2019-03-10 14:21 dinu Note Added: 0004951
2019-03-10 16:48 derick Assigned To => derick
2019-03-10 16:48 derick Status new => feedback
2019-03-10 16:48 derick Note Added: 0004953
2019-03-12 16:11 dinu Status feedback => assigned
2019-03-12 16:16 dinu Note Added: 0004958
2019-03-12 16:20 dinu Note Added: 0004959
2019-03-13 21:46 kschroeder Note Added: 0004963
2019-03-13 21:53 dinu Note Added: 0004964
2019-03-13 22:22 kschroeder Note Added: 0004965
2019-03-14 03:17 dinu Note Added: 0004966
2019-03-14 14:37 kschroeder Note Added: 0004967
2019-03-14 15:13 kschroeder Note Added: 0004968
2019-03-14 15:32 kschroeder Note Added: 0004969
2019-03-20 14:24 onkeltem Note Added: 0004971
2019-03-21 12:49 derick Status assigned => confirmed
2019-03-21 12:49 derick Note Added: 0004972
2019-03-21 12:49 derick Target Version => 2.7.1
2019-03-21 13:58 derick Summary Crash with "zend_mm_heap corrupted" => Memory corruption when a conditional breakpoint is used
2019-03-21 14:11 derick Status confirmed => closed
2019-03-21 14:11 derick Resolution open => fixed
2019-03-21 14:11 derick Fixed in Version => 2.7.1
2019-03-21 14:11 derick Note Added: 0004973
2019-03-21 14:31 dinu Note Added: 0004976
2019-03-21 20:43 derick Note Added: 0004977
2020-03-12 16:35 derick Category Usage problems (Wrong Results) => Variable Display
2020-03-12 16:38 derick Category Variable Display => Uncategorized