zend_mm_heap corrupted

[keywinf]

I just updated uopz in my docker image with the last master commit e2b61ef

The very first unit test I tried to run immediately threw "zend_mm_heap corrupted"

Don't hesitate to ask for more details (phpunit version, etc.) if needed, if it's not immediate to solve it and it's worth it (I don't have a lot of time today for this).

[krakjoe]

Was this opened by mistake?

…

On Wednesday, 28 July 2021, keywinf ***@***.***> wrote: Closed #147 <#147>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#147 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARB52QRTT2YRZYYYP4GGUTTZ725ZANCNFSM5BEIQFLA> .

[keywinf]

No, I closed it because I thought the bug was related to other stuff, but re-open it because I was able to ensure the source of the problem was one of the last commits on master (pushed today).

[keywinf]

I don't know if all's done now, but I tried the very last commit again (9e23460), and I still have the same problem. I tried to get a backtrace with gdb, but none could have been made:

PHPUnit 9.5.3 by Sebastian Bergmann and contributors.

[New Thread 0x7ffff29ff700 (LWP 456)]
[Thread 0x7ffff29ff700 (LWP 456) exited]
zend_mm_heap corrupted
[Inferior 1 (process 438) exited with code 01]
(gdb) bt
No stack.
(gdb) q

[krakjoe]

I've noticed my CI has gone to shit in the last few months because of travis changes.

It's passing now on travis, so you might try again ... or else I'll need a reproducing test case to investigate further.

[keywinf]

Still crashing. But I found that commenting my uopz_del_function lines could potentially "solve" the case. I'll come back to you with more details if you wish

[krakjoe]

@keywinf could you pull in latest source and do another test please (with delete call) ?

[keywinf]

Yes, I'll try that very soon

[keywinf]

Still the same problem, with a6cf9c6

This is clearly related to uopz_add_function now