[C] Segmentation Fault Problem

davewood

> ./sample
> Segmentation fault (core dumped)

Und dass obwohl ich als allererstes Statement ein printf("debug\n") habe.

Wie geh ich denn am gscheitesten vor das Problem zu finden. Wohin schreibt er den coredump, im aktuellen working directory hab ich ihn nicht gefunden. Anfangen könnte ich allerdings auch nicht viel damit. =)

Ich hab naemlich ein Patchfile bekommen dass im autoconf einiges umgestellt hat, im Source allerdings praktisch nichts. Vorher gings, nun bekomm ich den segfault.

Über Hilfe bin ich sehr dankbar, weil meine Augen brennen schon vom reinstarren in den Monitor.

jeuneS2

Was sagt gdb bzw. der Debugger deines Vertrauens?

Spike101

Hmm probier mal fflush(stdout); nach dem printf.. Vllt verschluckt er das nur weil er so schnell abstürzt..

Zentor

fprintf(stderr,"TEST"); sollte auch funktionieren
mfg Oliver

Plantschkuh!

Zitat

probier mal fflush(stdout); nach dem printf

Wenn stdout an ein interaktives Device wie ein Terminal geht, ist es nicht "fully buffered", sondern "unbuffered" oder "line buffered". Dabei bedeutet "unbuffered", daß Zeichen sofort ausgegeben werden, und "line buffered", daß sie spätestens bei einem Newline ausgegeben werden. In obigem Beispiel muß "debug" also sofort auf dem Bildschirm erscheinen.

(Ja, ich bin ein Geek.)

Zum Thema hätt ich auch einen Debugger vorgeschlagen, bzw. ein sehr gründliches make clean und alles neu bauen. Falsch gelinkte Files können sehr seltsame segfaults verursachen, die auch Debugger verwirren.

Und wo in meinem Ubuntu die cores landen, wüßt ich auch gern...

davewood

ein fflush(NULL) hab ich bereits gemacht bevor ich das posting schrieb.

wenn der Parameter NULL ist werden alle offenen Dateideskriptoren geflushed.

gdb werd ich mir wohl endlich anschaun muessen =)

Hab ebenfalls Ubuntu am rennen btw.

der Source is frisch ausm SVN ausgecheckt, patch drüberlaufen lassen, autoconf und dann make, also nix mit Dateileichen.

Kann evt die Reihenfolge in der die libs an den Linker übergeben werden einen Segfault zur Folge habe?

jeuneS2

Zitat von Plantschkuh!

Und wo in meinem Ubuntu die cores landen, wüßt ich auch gern...

"ulimit -c unlimited" sollte helfen.

Plantschkuh!

Zitat von jeuneS2

"ulimit -c unlimited" sollte helfen.

Sollte, tuts aber nicht. (Und ist auch die default-Einstellung.)

Mittlerweile mühsam zusammengereimt: Aktuelle Ubuntus schicken coredumps durch ein Python-Skript, das ungern coredumps von Programmen macht, die nicht in /usr wohnen und daher nicht zu einem Package gehören. Es ist zwar vorgesehen, daß auch coredumps für User gemacht werden, aber nur, wenn eine mysteriöse Umgebungsvariable CORE_REAL_RLIM vom Kernel dies erlaubt, und die ist zumindest bei mir auf 0 gesetzt, obwohl der Wert -1, also unlimited, wünschenswert wäre.

davewood: Wenn du es dir antun willst und kannst, ändere in /usr/share/apport/apport um Zeile 290 herum (such nach "likely_packaged") den Code des if-Statements auf sowas:

Code

# changed this section to make sure we also get core dumps for
    # non-package programs---we might want to debug our own applications!
    if not apport.fileutils.likely_packaged(info['ExecutablePath']):
        # error_log('executable does not belong to a package, ignoring')
        error_log('executable does not belong to a package, dumping anyway')
        # check if the user wants a core dump
        drop_privileges(pid)
        # write_user_coredump(pid, cwd, core_ulimit, elfhead)
        write_user_coredump(pid, cwd, None, elfhead)
        sys.exit(1)

D.h. das dritte Argument an write_user_coredump auf None ändern, das ignoriert diese CORE_REAL_RLIM-Variable und schreibt dir im aktuellen Verzeichnis einen coredump in core.PID.

sauzachn

Mit "-g" compilieren (bzw. --debug oder so ähnlich im configure Script, wenn es eines gibt)
gdb ./sample
run
bt
Dann solltest du mehr sehen.

jeuneS2

Zitat von Plantschkuh!

Sollte, tuts aber nicht. (Und ist auch die default-Einstellung.)

Seltsam, seltsam. Unter Xubuntu funktionierts damit einwandfrei.

davewood

Hier die Kompilier- und Linkanweisungen falls das was bringen sollte.

Werd mich gleich mal an Sauzachns Tipp wagen

Code

david@pcdt:~/ndoutils-1.4b7-oracle/liboci/src$ make
gcc -g -O2 -fPIC -I/home/david/ndoutils-1.4b7-oracle/liboci/lib/oracle_instantclient_10_2-32/include -I../../liboci/include  -DHAVE_CONFIG_H -I../../include -I../../include -I../../liboci/include  -DHAVE_CONFIG_H -I../../include -I../../include -I../../liboci/include  -c -o sample.o sample.c
gcc -g -O2 -fPIC -I/home/david/ndoutils-1.4b7-oracle/liboci/lib/oracle_instantclient_10_2-32/include -I../../liboci/include  -DHAVE_CONFIG_H -I../../include -I../../include -I../../liboci/include  -DHAVE_CONFIG_H -I../../include -I../../include -I../../liboci/include  -c -o liboci.o liboci.c
ar rcs liboci.a liboci.o
ranlib liboci.a
gcc -shared -L/home/david/ndoutils-1.4b7-oracle/liboci/lib/oracle_instantclient_10_2-32/lib -L../../liboci/src  sample.o liboci.a   -o sample

die C und CPP Flags sind doppelt gemoppelt, komisch.

davewood

Code

$ gdb ./sample 
GNU gdb 6.6-debian
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".


(gdb) run
Starting program: /home/david/ndoutils-1.4b7-oracle/liboci/src/sample 


Program received signal SIGSEGV, Segmentation fault.
0x80000f06 in __do_global_dtors_aux ()


(gdb) bt
#0  0x80000f06 in __do_global_dtors_aux ()
(gdb)

Alles anzeigen

davewood

erm

ja da fehlen noch total viele linkerflags. hab ich erst jetzt gesehen.

entweder patch inkorrekt oder ich hab einen mist beim applien vom patch gedreht.

davewood

Der Fehler lag am -shared welches der patch eingebaut hat.

Mag mir jemand erklaeren warum?

Zitat

-shared
Produce a shared object which can then be linked with other objects to form an executable. Not all systems support this option. For predictable results, you
must also specify the same set of options that were used to generate code (-fpic, -fPIC, or model suboptions) when you specify this option.[1]

Jetzt mitmachen!