Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[realcruncher]

(gdb) run
Starting program: /usr/bin/amulegui
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 31607)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 31607)]
0x4055e71d in operator+ () from /usr/lib/libwx_baseu-2.8.so.0
(gdb) where
#0  0x4055e71d in operator+ () from /usr/lib/libwx_baseu-2.8.so.0
#1  0x0810e0e7 in wxTimer::IsRunning ()
#2  0x080663ed in ?? ()
#3  0x080716bf in ?? ()
#4  0x080764b1 in wxAppConsole::CallOnInit ()
#5  0x40539e10 in wxEntry () from /usr/lib/libwx_baseu-2.8.so.0
#6  0x40539ee7 in wxEntry () from /usr/lib/libwx_baseu-2.8.so.0
#7  0x080665a0 in ?? ()
#8  0x4074c3be in __libc_start_main () from /lib/libc.so.6
#9  0x08065d91 in ?? ()

This happens with amule-cvs 2007-04-11 on debian linux and cpu:

Vendor ID: "GenuineIntel"; CPUID level 2

Intel-specific functions:
Version 00000665:
Type 0 - Original OEM
Family 6 - Pentium Pro
Model 6 - Celeron
Stepping 5
Reserved 0

The same binary works on a debian machine with

Vendor ID: "AuthenticAMD"; CPUID level 1

AMD-specific functions
Version 00000671:
Family: 6 Model: 7 [Mobile Duron Model 7]

which also has wxwidgets 2.8.3 installed.

Any ideas what happens ? It worked with a 1 year old version linked to wxwidgets 2.6 on both machines.

[phoenix]

Hi realcruncher,

There is not much information in this backtrace. Are you sure you have debug information?

You should try to compile wxWidgets (with debug information too), so that we can go a little further.

Cheers!

[realcruncher]

Hi with a new wxwidgets with debugging enabled this is the result:

Starting program: /usr/bin/amulegui
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 28053)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 28053)]
0x4057171d in operator+ (str=@0x7c, psz=0x821ddf8) at ./include/wx/string.h:424
warning: Source file is more recent than executable.
424       void reserve(size_t sz) { Alloc(sz); }
Current language:  auto; currently c++
(gdb) where
#0  0x4057171d in operator+ (str=@0x7c, psz=0x821ddf8) at ./include/wx/string.h:424
#1  0x0810e0e7 in wxTimer::IsRunning ()
#2  0x080663ed in ?? ()
#3  0x080716bf in ?? ()
#4  0x080764b1 in wxAppConsole::CallOnInit ()
#5  0x4054ce10 in wxEntry (argc=@0x4061e14c, argv=0x82bcd50) at ./src/common/init.cpp:433
#6  0x4054cee7 in wxEntry (argc=@0xbffffab0, argv=0xbffffaf4) at ./src/common/init.cpp:461
#7  0x080665a0 in ?? ()
#8  0x4075f3be in __libc_start_main () from /lib/libc.so.6
#9  0x08065d91 in ?? ()
(gdb) quit

So this is the problem:
void reserve(size_t sz) { Alloc(sz); } ?

What to do ?

Thanks,
rc

[phoenix]

Unfortunately, this backtrace does not help much.

On the other hand, one thing that is "good" about this error is that you have recompiled wxWidgets and the error is still in the same place.

Are you sure amulegui has debug information? I see no amulegui line numbers in your backtrace. Maybe you are running a copy different from the one you compiled?

Cheers!

[realcruncher]

Hi Phoenix,

i recompiled amulegui and the funny thing is with debugging enabled it runs without crash !
Any ideas ?

Thanks,
rc

[phoenix]

I see no amulegui line numbers in your backtrace. Maybe you are running a copy different from the one you compiled?

Cheers!

[realcruncher]

I don't think so. The amulegui that crashed was just compiled without debugging options, i just compiled wxwidgets again with debugging because the crash came from the libwxbase.
Then after compiling the same source again but with debugging enabled the amulegui runs. This must be a compiler/preprocessor issue or some flags in a header file.

Greets, rc

[phoenix]

Yeah, good theory. And would mean that the crash is not aMule related.

Another thing is if you have updated gtk+. gtk+ also has bugs and wxWidgets knows how to trigger them