#0 0x284ed95b in kill () from /lib/libc.so.7 #1 0x28412b52 in raise () from /lib/libthr.so.3 #2 0x284ec654 in abort () from /lib/libc.so.7 #3 0x283d07ca in _dbus_abort () at dbus-sysdeps.c:86 #4 0x283cb4e5 in _dbus_warn_check_failed ( format=0x283daa80 "arguments to %s() were incorrect, assertion \"%s\" failed in file %s line %d.\nThis is normally a bug in some application using the D-Bus library.\n") at dbus-internals.c:283 args = 0xbfbfe684 "Àr=(Zg=(Hg=(÷\017" #5 0x283aee68 in dbus_connection_get_dispatch_status ( connection=0x0) at dbus-connection.c:4087 status = DBUS_DISPATCH_DATA_REMAINS __FUNCTION__ = "dbus_connection_get_dispatch_status" #6 0x080b48bd in wakeup_handler (data=0x8248eb0, err=-1, read_mask=0x826b740) at dbus-core.c:59 info = (struct dbus_core_info *) 0x8248eb0 #7 0x080934ed in WakeupHandler (result=-1, pReadmask=0x826b740) at dixutils.c:475 i = 1 j = 136598800 #8 0x0820d3c2 in WaitForSomething (pClientsReady=0xbfbfe9e0) ---Type <return> to continue, or q <return> to quit--- at WaitFor.c:238 i = -1 waittime = {tv_sec = 599, tv_usec = 72000} wt = (struct timeval *) 0xbfbfe93c timeout = 599072 clientsReadable = {__fds_bits = { 0 <repeats 32 times>}} clientsWritable = {__fds_bits = {3217025112, 135851890, 144958688, 135821159, 3217025112, 695570306, 2, 136598800, 3217025160, 135852171, 137550880, 0, 3217025288, 0, 0, 137736560, 137556240, 0, 0, 136598800, 3217025320, 135875016, 137550880, 64, 0, 0, 136741220, 3217025288, 64, 137736560, 137556240, 4194356}} curclient = 136393443 selecterr = 4 nready = 145076224 devicesReadable = {__fds_bits = {3217025000, 134823171, 136741224, 0, 3217025200, 675793094, ---Type <return> to continue, or q <return> to quit--- 144958576, 136598800, 137529088, 675793094, 136741224, 136598800, 3217025016, 144703586, 136741224, 136756188, 136756304, 135812348, 136741224, 3217025200, 3217025048, 136598800, 3217026772, 0, 3217025064, 136412311, 144958688, 136598800, 3217025080, 135624187, 144958688, 136598800}} now = 493673 someReady = 0 #9 0x08084f6d in Dispatch () at dispatch.c:425 clientReady = (int *) 0xbfbfe9e0 result = 0 client = 0x8357bc0 nready = -1 icheck = (HWEventQueuePtr *) 0x826ab68 start_tick = 360 #10 0x0806dd88 in main (argc=7, argv=0xbfbfeeb4, envp=0xbfbfeed4) at main.c:452 i = 1 j = 2 k = 2 error = 676396992 xauthfile = 0x0 alwaysCheckForInput = {0, 1} > pkg_version -v | egrep 'xorg|dbus' "Makefile", line 115: warning: DjVu requires threads and will not be supported dbus-1.2.1 = up-to-date with port dbus-glib-0.76 = up-to-date with port dbus-qt3-0.70_2 = up-to-date with port xorg-7.3_1 < needs updating (port has 7.3_2) xorg-server-1.4.2,1 = up-to-date with port
What did you do to cause this segfault? Is it reproduceable?
I'm not sure, but I was fighting with Compiz and beryl to get this working (because it was very slow) and before this I tried to reproduce other bug that I found (this was when I've started compiz and run gliv software, then X unexpectedly always crashed). Maybe this core was was created before reboot (probably), changing consoles or in other time, for sure I don't know when;( This bug I wanted to reproduce it's: #0 0x2846a95b in kill () from /lib/libc.so.7 #1 0x2838fb52 in raise () from /lib/libthr.so.3 #2 0x28469654 in abort () from /lib/libc.so.7 #3 0x080a06a6 in ddxGiveUp () #4 0x081a899c in AbortServer () #5 0x081a8e8d in FatalError () #6 0x080bcebf in xf86SigHandler () #7 <signal handler called> #8 0x294bc353 in _nv002738X () from /usr/local/lib/xorg/modules/drivers//nvidia_drv.so #9 0xbfbfe658 in ?? () ... #16 0x2968c1a0 in ?? () from /usr/local/lib/xorg/modules/drivers//nvidia_drv.so ... #20 0x294e3bd2 in _nv002738X () from /usr/local/lib/xorg/modules/drivers//nvidia_drv.so ... #34 0x294e3b00 in _nv002738X () from /usr/local/lib/xorg/modules/drivers//nvidia_drv.so But this crash that I sent here is different that above. So I don't know if I can reproduce it;(
On Sun, Jun 22, 2008 at 05:31:25AM -0700, bugzilla-daemon@freedesktop.org wrote: > --- Comment #2 from Rafal W. <kenorb@gmail.com> 2008-06-22 05:31:25 PST --- > I'm not sure, but I was fighting with Compiz and beryl to get this working > (because it was very slow) and before this I tried to reproduce other bug that > I found (this was when I've started compiz and run gliv software, then X > unexpectedly always crashed). Maybe this core was was created before reboot > (probably), changing consoles or in other time, for sure I don't know when;( > > This bug I wanted to reproduce it's: > #0 0x2846a95b in kill () from /lib/libc.so.7 > #1 0x2838fb52 in raise () from /lib/libthr.so.3 > #2 0x28469654 in abort () from /lib/libc.so.7 > #3 0x080a06a6 in ddxGiveUp () > #4 0x081a899c in AbortServer () > #5 0x081a8e8d in FatalError () > #6 0x080bcebf in xf86SigHandler () > #7 <signal handler called> > #8 0x294bc353 in _nv002738X () from > /usr/local/lib/xorg/modules/drivers//nvidia_drv.so > #9 0xbfbfe658 in ?? () > ... > #16 0x2968c1a0 in ?? () from /usr/local/lib/xorg/modules/drivers//nvidia_drv.so > ... > #20 0x294e3bd2 in _nv002738X () from > /usr/local/lib/xorg/modules/drivers//nvidia_drv.so > ... > #34 0x294e3b00 in _nv002738X () from > /usr/local/lib/xorg/modules/drivers//nvidia_drv.so > > But this crash that I sent here is different that above. > So I don't know if I can reproduce it;( this crash suggests that the driver aborted the server for some reason. since this is the binary driver, there isn't much more we know.
But this can be not related. What about the first one?
> --- Comment #4 from Rafal W. <kenorb@gmail.com> 2008-06-26 03:44:42 PST --- > But this can be not related. correct, they are not related. > What about the first one? I don't know. I had a look at it and the only thing I could think of was a race condition that I realised cannot occur in the single-threaded X server. So we really need a way to reproduce this.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.