incompatible with PHP8.1 on debian #595
Comments
Is not an error message generated by snmalloc. I am guessing that php has statically linked part of the C runtime, or partially overridden the allocator, so that it is not possible to LD_PRELOAD a new allocator. Could you get a stack trace of the failure? Do other systems like jemalloc or mimalloc work with PHP? |
|
So I got a stack trace: * thread #1, name = 'php8.1', stop reason = signal SIGABRT
* frame #0: 0x00007ffff764300b libc.so.6`raise + 203
frame #1: 0x00007ffff7622859 libc.so.6`abort + 299
frame #2: 0x00007ffff768d26e libc.so.6`___lldb_unnamed_symbol329$$libc.so.6 + 670
frame #3: 0x00007ffff76952fc libc.so.6`___lldb_unnamed_symbol397$$libc.so.6 + 28
frame #4: 0x00007ffff7696b2c libc.so.6`___lldb_unnamed_symbol410$$libc.so.6 + 748
frame #5: 0x00007ebff46a4318 pdo.so`___lldb_unnamed_symbol64$$pdo.so + 440
frame #6: 0x00007ebff46a4390 pdo.so`___lldb_unnamed_symbol65$$pdo.so + 80
frame #7: 0x000055555583f8b8 php8.1`zend_startup_module_ex + 296
frame #8: 0x000055555583f950 php8.1`___lldb_unnamed_symbol5971$$php8.1 + 16
frame #9: 0x000055555584d61b php8.1`zend_hash_apply + 91
frame #10: 0x00005555557d7976 php8.1`php_module_startup + 2102
frame #11: 0x0000555555922dd1 php8.1`___lldb_unnamed_symbol7339$$php8.1 + 17
frame #12: 0x0000555555679db3 php8.1`___lldb_unnamed_symbol2809$$php8.1 + 419
frame #13: 0x00007ffff7624083 libc.so.6`__libc_start_main + 243
frame #14: 0x000055555567a7ee php8.1`_start + 46So it is not freeing using snmalloc. I get a similar crash with mimalloc. |
|
jemalloc seems to be working fine and I did find a mimalloc issue on this now: microsoft/mimalloc#377 |
|
So Scudo also crashes. I confirm works. The mimalloc crash is a bit different as it seems to be freeing #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff71c7859 in __GI_abort () at abort.c:79
#2 0x00007ffff723226e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff735c298 "%s\n")
at ../sysdeps/posix/libc_fatal.c:155
#3 0x00007ffff723a2fc in malloc_printerr (str=str@entry=0x7ffff735a4c1 "free(): invalid pointer") at malloc.c:5347
#4 0x00007ffff723bb2c in _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:4173
#5 0x00007fd2f501f318 in ?? () from /usr/lib/php/20210902/pdo.so
#6 0x00007fd2f501f390 in ?? () from /usr/lib/php/20210902/pdo.so
#7 0x000055555583f8b8 in zend_startup_module_ex ()
#8 0x000055555583f950 in ?? ()
#9 0x000055555584d61b in zend_hash_apply ()
#10 0x00005555557d7976 in php_module_startup ()
#11 0x0000555555922dd1 in ?? ()
#12 0x0000555555679db3 in ?? ()
#13 0x00007ffff71c9083 in __libc_start_main (main=0x555555679c10, argc=1, argv=0x7fffffffe118,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe108)
at ../csu/libc-start.c:308
#14 0x000055555567a7ee in _start ()I got a slightly better stack trace from gdb. I wonder if there is something in libc tail calling |
|
here is a valgrind trace: |
|
I believe based on the mimalloc issue you link, and skimming the php source, something is being freed with a different kind of allocator to it is being allocated with. Without building php, so I have the symbols, I am not sure how to proceed. Your valgrind trace shows calls to both E.g. and Given so many allocators are failing, I would suggest it is a PHP problem. That one succeeds is potentially just look that the corruption is not detected. |
|
@ryancinsight apologies for editing your comment, but I couldn't read it with the original formatting. |
Indeed, I just tested with jemalloc and had the same errors so it seems they are going undetected with it. |
Those are memory leaks rather than heap corruption. I think Valgrind is replacing both the libc.so:malloc and libsnmalloc.so:malloc with its own implementation. So it would mask what I suspect is the underlying bug. |
|
I wonder if using Could provide a fix for this. It seems RTLDEEPBIND is the problem in PHP and that doesn't look like it will go away. This is how jemalloc deals with the problem: |
|
@ryancinsight does this now work for you? #598 I believe should fix this. |
It's fixed and working well! I can now share an allocator between containers and images are loading much faster, thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Using Docker debian bullseye with php8.1 receive a free: invalid pointer error:
root@7ead17e03ea3:/home/snmalloc/out/release# export LD_PRELOAD=/home/snmalloc/out/release/libsnmallocshim.so
root@7ead17e03ea3:/home/snmalloc/out/release# php
free(): invalid pointer
Aborted
The text was updated successfully, but these errors were encountered: