[C] Segmentation Fault Problem

Hallo zusammen,

das Informatik-Forum geht in den Archivmodus, genaue Informationen kann man der entsprechenden Ankündigung entnehmen. Als Dankeschön für die Treue bekommt man von uns einen Gutscheincode (informatikforum30) womit man bei netzliving.de 30% auf das erste Jahr sparen kann. (Genaue Infos sind ebenfalls in der Ankündigung)

Vielen Dank für die Treue und das Verständnis!

    > ./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.

    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...

    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?

    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.

    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.

    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]