xine / kaffeine core dumps with bus error

[David Kirchner]

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.