Segmentation Fault Problem!!!

manu1984

Hi @ all,

ich hab ein etwas seltsames problem.
ich habe einen etwas längeren code geschrieben mit mehreren if-schleifen in einer while-schleife. (eine datei wird zeilenweise eingelesen und dann per if-schleifen einfach umgeschrieben in eine neue datei)
mit meinem (recht schnellen) pc klappt das ohne probleme.
mein nachbar hat einen etwas langsameren pc und da bekomme ich bei "größeren" dateien immer mal einen segmentation fault.
ich dachte immer, ein segmentation fault ist eine zugriffsverletzung. aber das kann ja irgendwie nicht sein, weil es ja sonst klappt. nur bei etwas längeren dateien nicht.
weiss jemand, was da das problem sein könnte?

Vielen dank im voraus!
Manu

Fedaykin

natürlich kann es immer noch eine zugriffsverletzung sein, die du halt an deinen schnelleren rechner nicht bemerkst. Ich kann jetzt nicht 100 % sagen wie das läuft.

Aber dein programm ist ja nicht das einzige programm was läuft.

Wenn du nun speicher allokierst diesen rein technisch frei gibst aber immer noch auf die inhalte zugreifst kann das gut gehen solange noch niemand anders diesen bereich für sich gefordert hat.

Bei deinen schnellen programm bist du ggf schnell genug über die stelle hinweg wo es kracht. Da ist noch keiner dazu gekommen genau den bereich den du eigentlich freigegeben hast, aber auf den du nochmal zugreifst, an zu fordern.

Beim langsamen ist ja auch die Zeit nach dem Freigeben und dem nochmaligen zugriff auf so einen bereich länger, daraus folgt das die chance größer ist das irgend ein anderer Prozess nun genau diesen Speicher schon wieder für sich angefordert hat was zum Segfault führt. Weil eben dein prozess nun genau speicher anfordert der jemand anderen gehört und dort segfaultet es dann.

die chancen das es segfaultet steigen dann natürlich auch mit weniger ram

manu1984

ja ... ich mit meinen 3 gig hab da keine probleme.
aber klingt einleuchtend, dass der langsamere pc den speicher nicht so schnell allokieren und wieder freigeben kann...
aber was kann ich dagegen machen?
irgendwie muss der fehler ja weg.

CStoll

Vielleicht zeigst du mal dein Programm

(PS: Es gibt keine if-Schleife ;))

manu1984

if(inpline[0]=='e' && inpline[1]=='v' && inpline[2]=='e' && inpline[3]=='n')
        {  

         if(inpline[DQS0]=='H' && inpline[DQ-1]=='Z' && inpline[DQ-8]=='Z')
           { if(inpline[70+t]=='>')
		        fprintf(fout,"    (DDR_READ__03 ");
             else if(inpline[70+t]=='d')
			    fprintf(fout,"    (DDR_READ__13 "); }
		 if(inpline[DQS0]=='L' && inpline[DQ-1]=='Z' && inpline[DQ-8]=='Z')
           { if(inpline[70+t]=='>')
		        fprintf(fout,"    (DDR_READ__03 ");
             else if(inpline[70+t]=='d')
			    fprintf(fout,"    (DDR_READ__13 "); }
........... (geht noch einige if-abfragen so weiter)

das ist nur ein ausschnitt. das sind insgesamt recht viele abfragen...
das ganze ist dann noch in einer while-schleife drin.

CStoll

Das Ding ist ja grauenhaft - behältst du da noch den Überblick, ob du innerhalb des zugewiesenen Speicherbereiches geblieben bist?

(btw, ist es Absicht, daß die beiden innersten if-else-Blöcke dieses Code-Ausschnitts identisch sind?

manu1984

ums ehrlich zu sagen: ich hab diese abfragen komplett aus einem alten programm übernommen. in wiefern da dieses segfault-problem aufgetreten ist weiss ich leider nicht.
da genau diese kombinationen überprüft werden müssen habe ich das ganze einfach so kopiert.

die beiden inneren if-else-blöcke sind nicht genau gleich. der if überprüft auf ">" und der else auf "d".
(oder meintest du etwas anderes?)

Fedaykin

das sieht ja so als als hätte ein assembler programmierer das geschrieben.

Die frage ist nun, wie groß ist inpline (wieviel speicher forderst du dafür an)
welchen wert hat:

DQS0
DQ
t

bzw wie groß kann das werden.... ich denke mal irgendwo (das ist doch sicherlich eine schleife) gehst du mal über die arraygröße hinaus.

CStoll

manu1984 schrieb:

ums ehrlich zu sagen: ich hab diese abfragen komplett aus einem alten programm übernommen. in wiefern da dieses segfault-problem aufgetreten ist weiss ich leider nicht.
da genau diese kombinationen überprüft werden müssen habe ich das ganze einfach so kopiert.

Und die angeforderte Speichermenge (und der Wert von DQS0 und DQ) sind auch immer noch identisch mit damals?

die beiden inneren if-else-blöcke sind nicht genau gleich. der if überprüft auf ">" und der else auf "d".
(oder meintest du etwas anderes?)

Ich meinte den Inhalt der beiden Blöcke "if(inpline[DQS0]=='H'...)" und "in(inpline[DQS0]=='L'...)" - abgesehen von einem Buchstaben sind die identisch.

manu1984

*g* ja assembler programmiere ich auch gelegentlich
die maschinensprache ist da doch wesentlich unkomplizierter

also: inpline[DQS0] ist genau 1 zeichen lang.

was die if-abfragen machen:
ich habe eine datei mit sehr vielen zeilen und in jeder zeile 90 zeichen.
jetzt will ich schauen:
wenn das zeichen an position 40 = H && position 50 == 1 ,... dann soll er eben z.b. DDR_READ schreiben.
allerdings habe ich für die inpline 150 zeichen reserviert, weil ich ja die gesamte zeile erstmal einlese.

CStoll

manu1984 schrieb:

also: inpline[DQS0] ist genau 1 zeichen lang.

Guter Witz (oder auf Deutsch: Diese Aussage hat einen Informationsgehalt von 0)

Viel interessanter ist: Wie lang ist das komplette Array 'inpline'? Und welche Werte haben die Indexvariablen DQS0, DQ, t?

(zu den if's - da lässt sich noch einige zusammenfassen (Tip: C kennt auch einen Operator || (OR))

manu1984

also für inpline hab ich 150 reserviert.
per #define MAXLENGTH 150
char inpline[MAXLENGTH]

DQS0 ist z.b. 42

na aber diese verzweigungen kann ich mit || nicht wirklich verknüpfen. hab schon versucht die inneren if-else blöcke mit switch-case zu ersetzen.
hat aber auch nicht funktioniert. (oder was wohl eher so war: ich war zu doof dafür *g*)

CStoll

Um nur mal den obigen Ausschnitt zu vereinfachen:

if(strcmp(inpline,"even")==0
{
  if((inpline[DQS0]=='H'||inpline[DQS0]=='L') && inpline[DQ-1]=='Z' && inpline[DQ-8]=='Z')
  {
    if(inpline[70+t]=='>')
      fprintf(fout,"    (DDR_READ__03 ");
    else if(inpline[70+t]=='d')
      fprintf(fout,"    (DDR_READ__13 ");
  }
  ...
}

Ansonsten könnten wir jetzt noch endlos weiter-theoretisieren. Aber dir ist vermutlich mehr geholfen, wenn du dieses Programm durch einen Debugger jagst und deine Aufmerksamkeit auf die verwendeten Index-Werte richtest.
(selbst wenn es im Debugger nicht zu einem SegFault kommt, siehst du vermutlich die Bereichsüberschreitungen "live")

manu1984

oh, ja richtig!!!! das habe ich übersehen... klaro, sowas kann ich dann doch zusammenfassen ...
aber damit hätte ich mir vielleicht von den 20 schleifen 3 gespart. das wird wohl das problem nicht lösen, oder?

ja debugger ist schlecht. da ich das ganze auf einer sunstation mache mit dem lausigsten compiler, den man sich vorstellen kann.
wenn ich die MAXLENGTH einfach mal auf 100 runtersetze, wäre mir damit schon geholfen?

CStoll

manu1984 schrieb:

ja debugger ist schlecht. da ich das ganze auf einer sunstation mache mit dem lausigsten compiler, den man sich vorstellen kann.

Da gibt es immer noch den Notfallplan - printf()-Debugging (auf Deutsch: du baust an strategisch günstigen Stellen printf()-Aufrufe ein, die den aktuellen Wert wichtiger Zähler auf dem Bildschirm ausgeben).

wenn ich die MAXLENGTH einfach mal auf 100 runtersetze, wäre mir damit schon geholfen?

Damit dürftest du das Problem eher verschlimmern - wenn du bei 150 Zeichen über die Arraygrenzen hinausschreibst, schaffst du es bei 100 Zeichen erst recht.

manu1984

na meine Zeilen sind ja nur um die 100 Zeichen lang.
Dann müssten ja z.b. 110 zeichen komplett ausreichen...
aber die frage ist eben ob das viel bringt?!

Fedaykin

DQS0 ist es also noch nicht, wo wird der wert von t bestimmt? Welche werte kann t annehmen? t sollte ja niemals größer als 79 werden die Frage ist halt, wird das in der schleife abgefangen?

manu1984

also t ist entweder 0 oder 1

irgendwie geht mir das echt nicht in kopf rein. wieso klappt das an dem einen pc wirklich immer! und bei dem anderen dauernd nicht.
bzw es klappt ja bei manchen dateien auch immer und bei anderen nie.