xine / kaffeine core dumps with bus error
David Kirchner
dpk at dpk.net
Tue Oct 4 20:58:20 PDT 2005
On 10/4/05, Ian Moore <no-spam at 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.
More information about the freebsd-questions
mailing list