#0 0xb75bcb69 in ?? () from /lib/libc.so.6
#1 0xb75be682 in calloc () from /lib/libc.so.6
#2 0x080abb2c in AllocateOutputBuffer (who=0x978ae48, count=32, __buf=0xbfda255c) at ../../os/io.c:1044
#3 WriteToClient (who=0x978ae48, count=32, __buf=0xbfda255c) at ../../os/io.c:758
#4 0x0806515f in WriteEventsToClient (pClient=0x978ae48, count=1, events=0xbfda255c) at ../../dix/events.c:5705
#5 0x08067b72 in TryClientEvents (client=0x978ae48, dev=0xbfda21e8, pEvents=0xbfda255c, count=1, mask=4325376, filter=131072, grab=0x0)
at ../../dix/events.c:1953
#6 0x0806ab60 in DeliverEventsToWindow (pDev=0xbfda21e8, pWin=0x98cae40, pEvents=0xbfda255c, count=1, filter=131072, grab=0x0) at ../../dix/events.c:2053
#7 0x0806b728 in DeliverEvents (pWin=0x98cae40, xE=0xbfda255c, count=1, otherParent=0x0) at ../../dix/events.c:2530
#8 0x080987ab in DeleteWindow (value=0x98cae40, wid=88080385) at ../../dix/window.c:943
#9 0x080711ad in FreeClientResources (client=0x9c07a60) at ../../dix/resource.c:859
#10 0x08072bc9 in CloseDownClient (client=0x9c07a60) at ../../dix/dispatch.c:3490
#11 0x08077b65 in Dispatch () at ../../dix/dispatch.c:442
#12 0x080625ba in main (argc=4, argv=0xbfda2794, envp=0xbfda27a8) at ../../dix/main.c:291
The odd thing here is that it segfaulted from AllocateOutputBuffer. The function takes no arguments (it's inlined, so it has args in the backtrace, but it doesn't really) and returns a pointer to freshly allocated data. I also added debugging symbols for calloc from libc6-dbg=2.12.1-0ubuntu10 and everything looks sane in terms of the stack. I think it's unlikely this is a stack corruption based on this data. However, it's even more unlikely, imo, that this is a bug in eglibc. Unfortunately, it's hard to tell what is going on through remote debugging.
Gustavo, can you try to reproduce again and see if the backtrace is the same? If so, it would point the finger towards eglibc. If not, then there really may be some weird stack corruption going on. Maybe something odd is occurring due to input handling in a signal handler?
The backtrace from the core dump shows:
#0 0xb75bcb69 in ?? () from /lib/libc.so.6 uffer (who=0x978ae48, count=32, __buf=0xbfda255c) at ../../os/io.c:1044 events. c:5705 events. c:1953 Window (pDev=0xbfda21e8, pWin=0x98cae40, pEvents=0xbfda255c, count=1, filter=131072, grab=0x0) at ../../dix/ events. c:2053 events. c:2530 window. c:943 resource. c:859 dispatch. c:3490 dispatch. c:442 main.c: 291
#1 0xb75be682 in calloc () from /lib/libc.so.6
#2 0x080abb2c in AllocateOutputB
#3 WriteToClient (who=0x978ae48, count=32, __buf=0xbfda255c) at ../../os/io.c:758
#4 0x0806515f in WriteEventsToClient (pClient=0x978ae48, count=1, events=0xbfda255c) at ../../dix/
#5 0x08067b72 in TryClientEvents (client=0x978ae48, dev=0xbfda21e8, pEvents=0xbfda255c, count=1, mask=4325376, filter=131072, grab=0x0)
at ../../dix/
#6 0x0806ab60 in DeliverEventsTo
#7 0x0806b728 in DeliverEvents (pWin=0x98cae40, xE=0xbfda255c, count=1, otherParent=0x0) at ../../dix/
#8 0x080987ab in DeleteWindow (value=0x98cae40, wid=88080385) at ../../dix/
#9 0x080711ad in FreeClientResources (client=0x9c07a60) at ../../dix/
#10 0x08072bc9 in CloseDownClient (client=0x9c07a60) at ../../dix/
#11 0x08077b65 in Dispatch () at ../../dix/
#12 0x080625ba in main (argc=4, argv=0xbfda2794, envp=0xbfda27a8) at ../../dix/
The odd thing here is that it segfaulted from AllocateOutputB uffer. The function takes no arguments (it's inlined, so it has args in the backtrace, but it doesn't really) and returns a pointer to freshly allocated data. I also added debugging symbols for calloc from libc6-dbg= 2.12.1- 0ubuntu10 and everything looks sane in terms of the stack. I think it's unlikely this is a stack corruption based on this data. However, it's even more unlikely, imo, that this is a bug in eglibc. Unfortunately, it's hard to tell what is going on through remote debugging.
Gustavo, can you try to reproduce again and see if the backtrace is the same? If so, it would point the finger towards eglibc. If not, then there really may be some weird stack corruption going on. Maybe something odd is occurring due to input handling in a signal handler?