Ursache für Segfault bestimmen?

Seite 1 von 1 - Forum: Linux and other OS auf overclockers.at

URL: https://www.overclockers.at/linux/ursache_fuer_segfault_bestimmen_153494/page_1 - zur Vollversion wechseln!

DJ_Cyberdance schrieb am 28.11.2005 um 11:06

Ich hab Software compiled - konkret OpenWBEM - und zwar sowohl unter einem relativ gewöhnlichen 2.6.14.2 und einem User-Mode Kernel, ebenfalls 2.6.14.2, jeweils mit gcc4.0.2. Unterm "normalen" Kernel funktioniert alles bestens, unterm UML bekomm ich beim Ausführen der software (bzw. gibts da ein 'make check', dort ebenfalls) einen Segfault.
Ich möcht wissen, warum, aber meine Kenntnisse gehen leider nicht so ins Detail. Ich hab mal versucht, ein wenig zu debuggen und hab folgende Daten gesammelt:

Backtrace auf Coredump:

Zitat
#0 0x00000000 in ?? ()
#1 0x40020cfd in start_thread () from /lib/tls/libpthread.so.0
#2 0x407f113e in clone () from /lib/tls/libc.so.6

strace erzählt mir folgendes (Nur leider hilfts mir nix weiter...)

Zitat
[...]
write(1, "OW_ThreadPool", 13) = 13
write(2, ".", 1.) = 1
rt_sigaction(SIGFPE, {0x811edd0, [FPE], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGFPE, {SIG_DFL}, {0x811edd0, [FPE], SA_RESTART}, 8) = 0
rt_sigaction(SIGTRAP, {0x811edd0, [TRAP], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTRAP, {SIG_DFL}, {0x811edd0, [TRAP], SA_RESTART}, 8) = 0
rt_sigaction(SIGBUS, {0x811edd0, [BUS], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGBUS, {SIG_DFL}, {0x811edd0, [BUS], SA_RESTART}, 8) = 0
rt_sigaction(SIGSEGV, {0x811edd0, [SEGV], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGSEGV, {SIG_DFL}, {0x811edd0, [SEGV], SA_RESTART}, 8) = 0
rt_sigaction(SIGABRT, {0x811edd0, [ABRT], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGABRT, {SIG_DFL}, {0x811edd0, [ABRT], SA_RESTART}, 8) = 0
rt_sigaction(SIGFPE, {0x811edd0, [FPE], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGFPE, {SIG_DFL}, {0x811edd0, [FPE], SA_RESTART}, 8) = 0
rt_sigaction(SIGTRAP, {0x811edd0, [TRAP], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTRAP, {SIG_DFL}, {0x811edd0, [TRAP], SA_RESTART}, 8) = 0
rt_sigaction(SIGBUS, {0x811edd0, [BUS], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGBUS, {SIG_DFL}, {0x811edd0, [BUS], SA_RESTART}, 8) = 0
rt_sigaction(SIGSEGV, {0x811edd0, [SEGV], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGSEGV, {SIG_DFL}, {0x811edd0, [SEGV], SA_RESTART}, 8) = 0
rt_sigaction(SIGABRT, {0x811edd0, [ABRT], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGABRT, {SIG_DFL}, {0x811edd0, [ABRT], SA_RESTART}, 8) = 0
mmap2(NULL, 8388608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4085d000
mprotect(0x4085d000, 4096, PROT_NONE) = 0
clone(child_stack=0x4105c4c4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|CLONE_DETACHED, parent_tidptr=0x4105cbf8ptrace: umoven: No such process
, tls=0xbf722afc, child_tidptr=0x4105cbf8) = 1160
trace: ptrace(PTRACE_SYSCALL, ...): No such process

Kann damit jemand von euch etwas anfangen? Oder mir einen Tip geben, wo der Fehler liegen könnte?

DJ_Cyberdance schrieb am 29.11.2005 um 08:47

Habs mittlerweile gelöst: UML hat keinen TLS-Support, umbenennen von /lib/tls nach /lib/tls.old und ein anschließender Reboot lösen das Problem. Infos:

http://www.mythic-beasts.com/umlwik....pl?2.6_And_TLS

Marcellus schrieb am 05.12.2005 um 21:56

Ist ja der ur monotone thread :P

mat schrieb am 05.12.2005 um 22:58

lässt sich sicher mit den richtigen compileflags schöner lösen..

finds trotzdem super, dass du deine lösung hier postest!

Marcellus schrieb am 06.12.2005 um 08:40

jojo me 2

SYSMATRIX schrieb am 06.12.2005 um 16:14

2.6er kernel brauchen kein NPTL, warum sollten die das auch?
thread local storage support ist ein feature der glibc, einfach TLS beim compilen der glibc disablen. sollts auch tun.

also glibc + linuxthreads -tls anstatt glibc + nptl