-
-
Save bnoordhuis/e4455e6f2e2b272e5782 to your computer and use it in GitHub Desktop.
smartos malloc segfault
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Program received signal SIGSEGV, Segmentation fault. | |
[Switching to LWP 5] | |
0xfecd8853 in _malloc_unlocked () from /lib/libc.so.1 | |
(gdb) bt | |
#0 0xfecd8853 in _malloc_unlocked () from /lib/libc.so.1 | |
#1 0xfecd869d in malloc () from /lib/libc.so.1 | |
#2 0x0809c9c1 in uv__fs_readlink (req=0x80478cc) at ../src/unix/fs.c:238 | |
#3 0x0809cd10 in uv__fs_work (w=0x8047930) at ../src/unix/fs.c:327 | |
#4 0x080a6645 in worker (arg=0x0) at ../src/unix/threadpool.c:64 | |
#5 0x08047930 in ?? () | |
#6 0x080c84a8 in single_accept.7267 () | |
#7 0x00000000 in ?? () | |
(gdb) f 2 | |
#2 0x0809c9c1 in uv__fs_readlink (req=0x80478cc) at ../src/unix/fs.c:238 | |
238 buf = malloc(len + 1); | |
(gdb) p len | |
$1 = 1024 |
Never mind, solved the issue. It was indeed memory corruption but it only triggered with libc's malloc in 32 bits mode.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For the record, this happens with my branch here.
I would suspect some kind of memory corruption but it's odd that the exact same code works fine when linked against libumem.