Re: segfault on one debian, but not on the other ?
> Hi !
>
> I have problems compiling & running a program on one of my debian/testing systems.
> I have two machines:
> 1) "Eddie", a not-very-up-to-date woody machine (Athlon) with new libc6
> 2) "Zaphod", a very old woody P100 system. Last dist-upgrade was in september, I think...
>
> The program is "sampeg3" an (IMHO) excellent mpeg encoder. You can find it on www.linuxtv.org.
>
> My Problem is: after compiling without any errors (on each machine), the program immediately segfaults on Eddie, but runs perfectly on Zaphod. I tried to debug, but the segfault occurs even before the first line of main()...
>
> I asked the author who said (I'll try to translate:)
> "Quite a lot C++ Comiplers seem to have problems to call the constructor of global objects. I had the problem with Solaris, too. But on Linux it worked allways."
>
> I tried it with gcc 2.95.4 and 3.0.2, but no difference.
>
> ldd says:
> libvideogfx-0.0.so.1 => /usr/local/lib/libvideogfx-0.0.so.1 (0x40020000)
> libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4006a000)
> libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40089000)
> libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40098000)
> libm.so.6 => /lib/libm.so.6 (0x40173000)
> libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x40195000)
> libc.so.6 => /lib/libc.so.6 (0x401e0000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>
> Version information:
> src/sampeg:
> libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
> libm.so.6 (GLIBC_2.0) => /lib/libm.so.6
> /usr/local/lib/libvideogfx-0.0.so.1:
> libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.2) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
> /usr/lib/libjpeg.so.62:
> libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
> /usr/X11R6/lib/libXext.so.6:
> libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
> /usr/X11R6/lib/libX11.so.6:
> libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.2) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.1.2) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
> /lib/libm.so.6:
> libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
> /usr/lib/libstdc++-libc6.2-2.so.3:
> libm.so.6 (GLIBC_2.0) => /lib/libm.so.6
> libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
> /lib/libc.so.6:
> ld-linux.so.2 (GLIBC_2.1.1) => /lib/ld-linux.so.2
> ld-linux.so.2 (GLIBC_2.2.3) => /lib/ld-linux.so.2
> ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
> ld-linux.so.2 (GLIBC_2.2) => /lib/ld-linux.so.2
> ld-linux.so.2 (GLIBC_2.0) => /lib/ld-linux.so.2
>
> Can anyone help me, please ? I like that encoder so much and am sad, the newer Versions don't run...
> --
> Markus Grunwald
>
> Registered Linux User Nr 101577
> http://counter.li.org http://www.grunwald.2xs.de
>
What are the versions of the compiler involved?
You can try to set break points at the constructors of the global
objects in order to locate the point of failure.
Another option is to dump core and examine it.
Could it be that the order of the creation of the global objects is
significant?
--
Shaul Karl
email: shaulka(at-no-spam)bezeqint.net
Please replace (at-no-spam) with an at - @ - character.
(at-no-spam) is meant for unsolicitate mail senders only.
Reply to: