Date: Tue, 4 Oct 2005 20:58:18 -0700 From: David Kirchner <dpk@dpk.net> To: Ian Moore <no-spam@swiftdsl.com.au> Cc: Brian John <brianjohn@fusemail.com>, freebsd-questions@freebsd.org Subject: Re: xine / kaffeine core dumps with bus error Message-ID: <35c231bf0510042058w3f5c5da8lcf2c2f9562c7d4fd@mail.gmail.com> In-Reply-To: <200510051241.40810.no-spam@swiftdsl.com.au> References: <200510050915.12491.no-spam@swiftdsl.com.au> <43431DD9.2000806@fusemail.com> <35c231bf0510041855i6c623341ge4c5766538079d76@mail.gmail.com> <200510051241.40810.no-spam@swiftdsl.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/4/05, Ian Moore <no-spam@swiftdsl.com.au> wrote: > OK, I've done that for xine, here's the last bit: > 1935 xine RET read 4096/0x1000 > 1935 xine CALL mmap(0,0x5e000,0x5,0x20002,0x6,0,0,0) > 1935 xine RET mmap 692838400/0x294be000 > 1935 xine CALL mprotect(0x294ec000,0x1000,0x7) > 1935 xine RET mprotect 0 > 1935 xine CALL mprotect(0x294ec000,0x1000,0x5) > 1935 xine RET mprotect 0 > 1935 xine CALL mmap(0x294ed000,0x3000,0x3,0x12,0x6,0,0x2e000,0) > 1935 xine RET mmap 693030912/0x294ed000 > 1935 xine CALL mmap(0x294f0000,0x2c000,0x3,0x1012,0xffffffff,0,0,0= ) > 1935 xine RET mmap 693043200/0x294f0000 > 1935 xine CALL close(0x6) > 1935 xine RET close 0 > 1935 xine CALL access(0x2816a000,0) > 1935 xine NAMI "/usr/X11R6/lib/libstdc++.so.4" > 1935 xine RET access -1 errno 2 No such file or directory > 1935 xine CALL access(0x2816a000,0) > 1935 xine NAMI "/usr/local/lib/libstdc++.so.4" > 1935 xine RET access -1 errno 2 No such file or directory > 1935 xine CALL access(0x2816a000,0) > 1935 xine NAMI "/lib/libstdc++.so.4" > 1935 xine RET access -1 errno 2 No such file or directory > 1935 xine CALL access(0x2816a000,0) > 1935 xine NAMI "/usr/lib/libstdc++.so.4" > 1935 xine RET access 0 > 1935 xine CALL access(0x2816a000,0) > 1935 xine NAMI "/usr/X11R6/lib/libm.so.3" > 1935 xine RET access -1 errno 2 No such file or directory > 1935 xine CALL access(0x2816a000,0) > 1935 xine NAMI "/usr/local/lib/libm.so.3" > 1935 xine RET access -1 errno 2 No such file or directory > 1935 xine CALL access(0x2816a000,0) > 1935 xine NAMI "/lib/libm.so.3" > 1935 xine RET access 0 > 1935 xine CALL mprotect(0x294ae000,0xf000,0x7) > 1935 xine RET mprotect 0 > 1935 xine CALL mmap(0,0x348,0x3,0x1000,0xffffffff,0,0,0) > 1935 xine RET mmap 693223424/0x2951c000 > 1935 xine CALL munmap(0x2951c000,0x348) > 1935 xine RET munmap 0 > 1935 xine CALL mprotect(0x294ae000,0xf000,0x5) > 1935 xine RET mprotect 0 > 1935 xine CALL mmap(0,0xb48,0x3,0x1000,0xffffffff,0,0,0) > 1935 xine RET mmap 693223424/0x2951c000 > 1935 xine CALL munmap(0x2951c000,0xb48) > 1935 xine RET munmap 0 > 1935 xine PSIG SIGBUS SIG_DFL > 1935 xine CALL kse_thr_interrupt(0,0x4,0xa) > 1935 xine NAMI "xine.core" > > Looks like it can't see lib files that really are there: > %ll /lib/libm* > -r--r--r-- 1 root wheel 108400 Feb 24 2004 /lib/libm.so.2 > -r--r--r-- 1 root wheel 120004 Jul 29 17:38 /lib/libm.so.3 > -r--r--r-- 1 root wheel 41096 Jul 29 17:38 /lib/libmd.so.2 > %ll /usr/lib/libstdc++.* > -r--r--r-- 1 root wheel 1754130 Jul 29 17:39 /usr/lib/libstdc++.a > lrwxr-xr-x 1 root wheel 14 Jul 29 17:39 /usr/lib/libstdc++.so -> > libstdc++.so.4 > -r--r--r-- 1 root wheel 881208 Jul 29 17:39 /usr/lib/libstdc++.so.4 > > So I don't know what's going on there. What it's doing there is checking the library path to try and find the requested library -- it does eventually find it, so that's OK. What this ktrace shows is that the dump occurs before anything else goes on -- ie just after loading the initial set of libraries it does something not related to a system call (like mishandling a pointer). I hate to suggest this, especially since you've had world built for so long without trouble, but maybe a freshly updated world would help? libstdc++ hasn't been updated in quite a while, but libm has had some radical changes made to it, it seems. It may not actually mean anything specific, though. I'm stuck at this point, I think. I don't know a lot about the X server internals or the drivers (specifically to the Radeon question). Might be best just to downgrade the port rather than mess around with something as big as rebuilding the entire world.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35c231bf0510042058w3f5c5da8lcf2c2f9562c7d4fd>