Fehlermeldung 1798 Segmentation fault



  • Danke mngbd,

    ich habe einfach vor jeden fclose(...) ein fflush(...) gesetzt! Jetzt stürzt das Board nnicht mehr so schnell ab. D.h beim ersten ausprobieren hat es bestimmt 5min gehalten. Dann ist es allerdings wieder abgestürzt.

    Aber das fflush hat mir auf jeden Fall geholfen.

    Ich kann mir vorstellen, das mein Board mit z.B. usleep(10) nicht klarkommt. Das ist ja eine echt kurze Zeit.

    Kann mir vielleicht jemand sagen, wie schnell so ein C Programm abgearbeitet wird. Ich meine von Befehl zu Befehl brauch der Rechner ja auch eine Zeit. (Vielleicht ns).

    Leider ist die Funktion immer noch viel zu ungenau, da werde ich mich mal an den Support von den SRF05 wenden müssen.

    Gruß aus D

    Pascal



  • iwrobot schrieb:

    ich habe einfach vor jeden fclose(...) ein fflush(...) gesetzt! Jetzt stürzt das Board nnicht mehr so schnell ab. D.h beim ersten ausprobieren hat es bestimmt 5min gehalten. Dann ist es allerdings wieder abgestürzt.

    Aber das fflush hat mir auf jeden Fall geholfen.

    Diese Ausgaben sollen nicht dafür sorgen, dass dein Prorgamm "stabiler" wird. Sie sollen dir zeigen, an welcher Stelle in deinem Code der Absturz passiert.



  • Hallo MFK,

    das weiß ich. Aber das Programm läuft ja nicht stabiler, seit dem ich die ganzen printf() reingeschrieben habe, sondern seit dem ich das fflush() verwendet habe.

    Und das die printf() mir anzeigen sollen, wo der Fehler ist, bzw. wo das Programm abstürzt ist mir auch klar. Nur leider stürzt das Programm an verschiedenen Stellen ab.



  • iwrobot schrieb:

    ich habe einfach vor jeden fclose(...) ein fflush(...) gesetzt! Jetzt stürzt das Board nnicht mehr so schnell ab. D.h beim ersten ausprobieren hat es bestimmt 5min gehalten. Dann ist es allerdings wieder abgestürzt.

    Hmm, das klingt nach irgendeinem Ausdruck mit undefiniertem Verhalten, der dann schliesslich dazu führt. Ein fflush() vor einem fclose() sollte gar keine Auswirkungen haben, weil fclose() den Puffer sowieso leert, bevor es die Datei zurückgibt.

    iwrobot schrieb:

    Kann mir vielleicht jemand sagen, wie schnell so ein C Programm abgearbeitet wird. Ich meine von Befehl zu Befehl brauch der Rechner ja auch eine Zeit.

    Messen hilft. Eine gewisse Genauigkeit haben die Funktionen aus time.h. Falls die nicht reicht, hat das System wahrscheinlich was besseres auf Lager.
    🙂



  • FILE *fp;
    
      fp = fopen( "/sys/class/gpio/gpio85/direction","w");            
      fprintf(fp,"out");                                                
      fclose(fp); /* <--- */
    
      if(!fp)     /* <--- */
      {                                                                        
        printf("Fehler beim oeffnen der direction Datei (Sensor)\n");                  
      }
    

    Das ist nicht dein Ernst, oder?



  • seldon schrieb:

    Das ist nicht dein Ernst, oder?

    Allein aus logischer Sicht, müsste das ins Auge stechen. Aber es steht dem switch( Wiederholung ) in nichts nach.

    Du solltest den ganzen Code nochmal überdenken.

    int signalverarbeiten()
    {
    	FILE* fp;
    	int erg = 0;
    
    	if( fp = fopen("/sys/class/gpio/gpio85/value","r") )
    	{
    		fscanf(fp, "%d", &erg
    		fclose(fp);
    
    		return 1;
    	}
    	else
    		return 0;
    }
    
    int i = 0;
    while( !signalverarbeiten() && i++ < 5 );
    


  • @seldon:

    Was meinst du damit? Ist die Vorgehensweise falsch?

    @FrEEzE2046:

    Deine Aussage verstehe ich nicht. Was ist mit switch(wiederholung)?
    Und was macht denn die while Schleife in deiner Antwort?



  • Du öffnest die Datei, schreibst hinein, schließt sie wieder und prüfst dann, ob das Öffnen funktioniert hat. Wenn also beim Öffnen tatsächlich etwas schief geht, arbeitest du eine ganze Weile mit einem NULL-Zeiger, und dass er dabei abstürzt, ist wenig verwunderlich.

    Richtig wär's etwa so:

    FILE *fp = fopen(...);
    
    if(fp != NULL) {
      /*  Hier kannst du gefahrlos mit der Datei arbeiten */
      fclose(fp);
    } else {
      /* Fehler beim Öffnen */
    }
    


  • Naja, das stimmt nicht ganz. Ich überprüfe noch vor dem schließen der Datei, ob sie geöffnet werden konnte. Aber deine Lösung ist natürlich elganter und übersichtlicher! Ich werde das bestimmt noch ändern. Danke für den Tipp!



  • Aus deinem Code:

    fclose(fp);
    
      if(!fp)
    

    Was passiert da zuerst?

    Abgesehen davon hilft es dir nichts, wenn du prüfst, ob der Zeiger NULL ist, nachdem du in ihm rumgeschrieben hast. Du musst prüfen, ob fp gültig ist, bevor du damit arbeitest, nicht nur bevor du ihn schließt.



  • Hallo seldon,

    du hast mich überzeugt. Ich werde den Code bearbeiten und erneut ausprobieren. Nur momentan hat das Board irgendwelche Probleme mit den Sensoren. Sobald ich den Code verändert und getestet habe, werde ich berichten.



  • iwrobot schrieb:

    Naja, das stimmt nicht ganz. Ich überprüfe noch vor dem schließen der Datei, ob sie geöffnet werden konnte. Aber deine Lösung ist natürlich elganter und übersichtlicher!

    Bitte? Das hat nichts mit eleganter zu tun. Deine "Lösung" ist inexistent, da der Code so wie er ist einfach keinen Sinn macht.

    Noch mal - du machst folgendes:
    1. Datei öffnen
    2. In Datei schreiben
    3. Datei schließen
    4. Überprüfen ob das Dateihandle korrekt ist

    Was denkst du was passiert, wenn "4." negativ ist und du gerade "2." machst?



  • Ich habs gesehen.

    Ich mache es mal so, mal so. Und Ihr habt vollkommen Recht, an mindestens zwei Stellen überprüfe ich das Öffnen der Datei, obwohl ich sie schon geschlossen habe.

    Sorry, ich habe an genau den falschen Stellen nachgeschaut. Ihr habt natürlich Recht. Danke für die Hinweise!



  • Also das Programm stürzt jetzt auf jeden Fall nicht mehr ab. Das ist ja schonmal ein riesen Fortschritt. Allerdings ist die Funktion immer noch nicht so gegeben, wie ich das möchte. Damit muss ich mich aber wahrscheinlich an ein SRF05 Forum oder so was wenden. Ich danke euch auf jeden Fall für eure Hilfe.

    Pascal



  • Vielen Dank nochmal für eure Hilfe.

    Mittlerweile ist das Projekt schon vorgestellt worden. Wem es interessiert kann sich ja mal auf http://iwrobot.bplaced.net/ informieren.

    MFG

    Pascal



  • mngbd schrieb:

    void log(char *s)
    {
        fputs(s, stderr);
        fflush(stderr);
    }
    

    müsste stderr nicht sowieso ungepuffert sein?



  • linux_c89 schrieb:

    müsste stderr nicht sowieso ungepuffert sein?

    Warum sollte das so sein?
    🙂


  • Mod

    mngbd schrieb:

    linux_c89 schrieb:

    müsste stderr nicht sowieso ungepuffert sein?

    Warum sollte das so sein?
    🙂

    Damit im Fehlerfall möglichst viel Ausgabe erscheint anstatt in einem Puffer zu versanden.



  • SeppJ schrieb:

    Damit im Fehlerfall möglichst viel Ausgabe erscheint anstatt in einem Puffer zu versanden.

    Ich denke eher, dass stderr verhindern soll, dass eine Fehlermeldung mit der Ausgabe vermischt wird. Was ihr meint, ist kein geplanter Fehlerfall sondern ein Crash. Darauf kann man zur Laufzeit gar nicht reagieren, denn könnte man, wäre es kein Crash.

    Darf man eigentlich setvbuf() auf die Standard-Streams anwenden?
    🙂



  • Zitat aus dem C89-Standard

    At program startup, three text streams are predefined and need not
    be opened explicitly --- standard input (for reading conventional
    input), standard output (for writing conventional output), and
    standard error (for writing diagnostic output). When opened, the
    standard error stream is not fully buffered

    Das heißt stderr ist maximal line-buffered
    (Das Zitat habe ich von http://flash-gordon.me.uk/ansi.c.txt)


Anmelden zum Antworten