frame 21 -- malloc_printerr() gets called due to arena corruption frame 19 -- __libc_message() calls backtrace() frame 6 -- rtld calls calloc(), and then things blow up even more #0 pthread_once () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_once.S:85 #1 0x000000388bef3b74 in *__GI___backtrace (array=<value optimized out>, size=32) at ../sysdeps/ia64/backtrace.c:79 #2 0x00000000004e89b6 in xorg_backtrace () at backtrace.c:39 #3 0x000000000047d63f in xf86SigHandler (signo=11) at xf86Events.c:385 #4 <signal handler called> #5 _int_malloc (av=0x388c169e80, bytes=1174) at malloc.c:4629 #6 0x000000388be79ef8 in __libc_calloc (n=<value optimized out>, elem_size=<value optimized out>) at malloc.c:4041 #7 0x000000388ba0b2af in _dl_new_object (realname=0x1e030a0 "/lib64/libgcc_s.so.1", libname=<value optimized out>, type=<value optimized out>, loader=0x0, mode=<value optimized out>, nsid=0) at dl-object.c:52 #8 0x000000388ba064bc in _dl_map_object_from_fd (name=<value optimized out>, fd=<value optimized out>, fbp=0x7fff3328a9b0, realname=<value optimized out>, loader=0x0, l_type=2, mode=<value optimized out>, stack_endp=0x7fff3328acf8, nsid=0) at dl-load.c:966 #9 0x000000388ba088d2 in _dl_map_object (loader=0x0, name=0x388bf318fa "libgcc_s.so.1", preloaded=<value optimized out>, type=<value optimized out>, trace_mode=<value optimized out>, mode=-1879048191, nsid=0) at dl-load.c:2235 #10 0x000000388ba130a9 in dl_open_worker (a=<value optimized out>) at dl-open.c:289 #11 0x000000388ba0e706 in _dl_catch_error (objname=<value optimized out>, errstring=<value optimized out>, mallocedp=<value optimized out>, operate=<value optimized out>, args=<value optimized out>) at dl-error.c:178 #12 0x000000388ba12a27 in _dl_open (file=0x388bf318fa "libgcc_s.so.1", mode=-2147483647, caller_dlopen=0x0, nsid=-2, argc=8, argv=0x2, env=0x7fff3328c110) at dl-open.c:615 #13 0x000000388bf1b010 in do_dlopen (ptr=0x7fff3328b110) at dl-libc.c:86 #14 0x000000388ba0e706 in _dl_catch_error (objname=<value optimized out>, errstring=<value optimized out>, mallocedp=<value optimized out>, operate=<value optimized out>, args=<value optimized out>) at dl-error.c:178 #15 0x000000388bf1b177 in dlerror_run (args=<value optimized out>, operate=<value optimized out>) at dl-libc.c:47 #16 *__GI___libc_dlopen_mode (args=<value optimized out>, operate=<value optimized out>) at dl-libc.c:160 #17 0x000000388bef3a75 in init () at ../sysdeps/ia64/backtrace.c:41 #18 0x000000388ca0c4f3 in pthread_once () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_once.S:94 #19 0x000000388bef3b74 in *__GI___backtrace (array=<value optimized out>, size=64) at ../sysdeps/ia64/backtrace.c:79 #20 0x000000388be70071 in __libc_message (do_abort=2, fmt=0x388bf35bd0 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:150 #21 0x000000388be75a26 in malloc_printerr (action=3, str=0x388bf35d48 "double free or corruption (!prev)", ptr=<value optimized out>) at malloc.c:6196 #22 0x00007ff92e57a70d in RADEONCSReleaseIndirect (pScrn=<value optimized out>) at radeon_accel.c:743
This commit introduced the regression: http://sourceware.org/git/?p=glibc.git;a=commit;f=sysdeps/posix/libc_fatal.c;h=48dcd0ba84c5a0fa08a0bd000b24af07d20dce44
Collin, This bug is reproducible in ubuntu as well running udev bug https://bugs.launchpad.net/ubuntu/+source/udev/+bug/601356 You mentioned commit http://sourceware.org/git/?p=glibc.git;a=commit;f=sysdeps/posix/libc_fatal.c;h=48dcd0ba84c5a0fa08a0bd000b24af07d20dce44 introduced the bug. This commit adds assert/fatal messages into the core file. So, reverting this means it will be missing in the core file, however messages printed by libc on stdout will continue to happen. Is this correct? Thanks Bharath
> This commit adds assert/fatal messages into the core file. So, reverting this > means it will be missing in the core file, however messages printed by libc on > stdout will continue to happen. Is this correct? When looking to sysdeps/posix/libc_fatal.c there is no longer malloc present. Running git blame shows it was changed in commit f8a3b5bf from 2011-05-15 which is after Colin's message. Did you tested with libc that contain commit f8a3b5bf ?
Hi OndrejBilka, >>When looking to sysdeps/posix/libc_fatal.c there is no longer malloc present. Running git blame shows it was changed in commit f8a3b5bf from 2011-05-15 which is after Colin's message. I checked the commits and I saw that latest code uses mmap. >>Did you tested with libc that contain commit f8a3b5bf ? I had not tested this. From the bug, it seemed that this issue is present since 2.10 onwards and since it is not fixed. It will be in version 2.15 also. I have a usecase for glibc-2.15 and hence wondered if there is a fix for this bug. If a proposed fix does not exist, I was wondering the repercussions of reverting the commit that caused the bug which is http://sourceware.org/git/?p=glibc.git;a=commit;f=sysdeps/posix/libc_fatal.c;h=48dcd0ba84c5a0fa08a0bd000b24af07d20dce44 Since, you pointed out the the commit f8a3b5bf replaces malloc with mmap in libc_fatal.c, it seems to me commit f8a3b5bf itself is the fix for this bug also. Isn't it? If yes, we can close the bug setting "Target Milestone = 2.13" corresponding to commit f8a3b5bf. As of my usecase, since f8a3b5bf is before 2.15, this bug would be already fixed in 2.15. Thanks Bharath
> As of my usecase, since f8a3b5bf is before 2.15, this bug would be already > fixed in 2.15. It should so I asked if you could reproduce it there. As you did not answer if that works I will assume it works on 2.15