Kann Unterprogramm nicht aufrufen

[br_klaus]

Hallo,
beim Kompilieren beginnt plötzlich der Compiler zu streiken. Und zwar, sobald ich einer bestimmten Stelle eine beliebige Prozedur aufrufen will. Allein der Versuch, eine Prozedur aufzurufen (selbst wenn in der gar nichts passiert), gibt die Fehlermeldung "Exception-Klasse: SIGSEGV". Was soll ich damit anfangen? Und wie kann ich das verhindern? Es scheint wohl mit dem Heap zusammenzuhängen, daß ich da an seine Grenzen stoße.
Ich habe einfach die Voreinstellungen übernommen. Was könnte ich ändern, damit es keine Fehlermeldung mehr gibt?
Herzlichen Dank

[Antrepolit]

Da müsstest du schon Quellcode posten...

[Christian]

meine Glaskugel sagt dein Object existiert nicht

[br_klaus]

Da müsstest du schon Quellcode posten...

Das wird nicht viel bringen.
Erstens ist der viel zu groß, zweitens ist es ja ein allgemeines Problem.
Erst begann es bei einer Unterprozedur. Dann habe ich die "aufgelöst", indem ich deren ProgrammCode direkt in den Quellcode geschrieben habe (damit war dann kein Aufruf mehr nötig), das hat der Compiler akzeptiert, dafür kam der Fehler jetzt eine Etage früher, wo zuvor noch nie eine Fehlermeldung kam.

Das Programm sieht einfach so aus

Code: Alles auswählen

  procedure check; begin end;
  procedure GetRec(beg,idx,maxlg:integer);
   begin
     ..Zuweisungen...
     Check;  // Hier Fehlermeldung: Projekt ... hat .. >>Exception-Klasse: SIGSEGV<< ausgelöst in ... Zeile ...
    Proc1;
    Proc2;
     ...weitere Prozeduraufrufe...
  end;
 

Das Komische ist ja, daß ich, auch wenn ich die in GetRec folgenden Prozeduren (Check, Proc1, Proc2) vertausche, die Fehlermeldung immer an der ersten Stelle auftritt, sobald ich versuche, eine der Prozeduren (es kann auch eine beliebige aus einer Unit sein) (hier: Check) aufzurufen. Mit F7 gelange ich erst gar nicht zum Prozedurbeginn, da kommt schon vorher die Errormeldung.

Was bedeutet denn die Exception-Klasse SIGSEGV? Kann man sich dazu die Informationen irgendwie anzeigen lassen? Und wie kann man die verhindern?

[theo]

Ohne Code kann man nichts sagen.

SIGSEGV ist ein Speicherzugriffsverletzung. Typischerweise wenn man auf eine Objektvariable zugreift, wo das Objekt nicht "Created" ist.
Auf die "Absturzzeile" würde ich nicht viel geben, so wie du das beschreibst.
Schau den Code nochmal ganz durch in diesem Sinne.

[Christian]

Sind das in deinem Programm WIRKLICH nicht objektorientierte Funktionen ? Oder sind die teil eines Objektes ?

[br_klaus]

Ohne Code kann man nichts sagen.

SIGSEGV ist ein Speicherzugriffsverletzung. Typischerweise wenn man auf eine Objektvariable zugreift, wo das Objekt nicht "Created" ist.
Auf die "Absturzzeile" würde ich nicht viel geben, so wie du das beschreibst.
Schau den Code nochmal ganz durch in diesem Sinne.

Aber dann verstehe ich nicht so ganz, warum die Fehlermeldung schon geschieht, alleine wenn ich F7 drücke. Da greife ich doch noch auf gar keine Objektvariable zu (Ja, es handelt sich um ein Object.). Oder muß der Compiler da schon die dann folgenden Aufrufe vor-"einkalkulieren"?
Und bei der Prozedur Check, auf was soll denn da "zugegriffen" werden? Das ist doch nur eine Dummy-Prozedur. Und trotzdem erscheint die Speicherzugriffsverletzung. Darum dachte ich ja, daß es vielleicht mit dem Heap (oder sonstigem Speicherplatz) zusammenhängt, der alleine für den Aufruf schon reserviert werden müßte.
Zumindest wäre damit erklärbar, warum dasselbe Programm nach "Auflösung" des Prozeduraufrufs (durch direktes Schreiben des ProzedurCodes in den Quellcode, da wo der Aufruf stattfinden sollte) auf einmal ohne diese Zugriffsverletzung reibungslos kompiliert wird.

[theo]

Das ist fischen im Trüben.

Wenn du keinen aufs Wesentliche reduzierten Code anhängst, mit dem man das Problem nachvollziehen kann, fällt mir dazu nichts mehr ein.

[Christian]

Da greife ich doch noch auf gar keine Objektvariable zu (Ja, es handelt sich um ein Object.).

Dann gibts ja den Fehler auch nicht, warum fragst du dann und verschwendest du UNSERE Zeit ?
Es gibt schlichtweg keine andere Erklärung. Wenn du den Fehler unfähig bist selbst zu finden wirst du deinen ach so wertvollen Code schon zeigen müssen. Oder hör auf zu posten.

[carli]

Hallo,
beim Kompilieren beginnt plötzlich der Compiler zu streiken. Und zwar, sobald ich einer bestimmten Stelle eine beliebige Prozedur aufrufen will. Allein der Versuch, eine Prozedur aufzurufen (selbst wenn in der gar nichts passiert), gibt die Fehlermeldung "Exception-Klasse: SIGSEGV". Was soll ich damit anfangen? Und wie kann ich das verhindern? Es scheint wohl mit dem Heap zusammenzuhängen, daß ich da an seine Grenzen stoße.
Ich habe einfach die Voreinstellungen übernommen. Was könnte ich ändern, damit es keine Fehlermeldung mehr gibt?
Herzlichen Dank

Nenn' uns doch mal die Fehlermeldung des Compilers. Oder crasht der Compiler bei dem Code?

[br_klaus]

Die Fehlermeldung ist ganz einfach:

Projekt comp hat Exception-Klasse >>External: SIGSEGV<< ausgelöst in Datei 'tarn', in Zeile nn.

comp.lpr ist mein Projektname (nibbleweises (De)Komprimieren einer beliebigen Datei), gebraucht die Units tarn (selbst erstellt) und KOL. Zeile nn ist die Zeile, wo ich eine andere Prozedur aufrufen will.

Wenn ich Zeit habe, will ich versuchen, den auf das Wesentliche reduzierten Code zu posten.
Vielleicht ergibt sich auch aus dem Verfolgen des Assembler-Codes ein Hinweis. Mal sehen.

[br_klaus]

Beim Disassembler habe ich gesehen, daß der Fehler dann auftritt, sobald der CALL-Befehl getätigt werden soll (einen Schritt hinein). D.h. es ist wohl kein Platz mehr im Speicher da, um die Rücksprungadresse zu speichern.
Gibt es da nicht einen Kompilerschalter {$M} um Speicher zu reservieren? Wie kann ich feststellen, was die vorgegebenen Größen sind?

[Christian]

Erzähl mal bitte was da Speicher brauchen soll beim call Befehl.
Hat die aufgerufene Funktion Parameter ?
kopier bitte mal die Funktionsdeklaration und zwar die aus der implementation section.

[br_klaus]

Erzähl mal bitte was da Speicher brauchen soll beim call Befehl.
Hat die aufgerufene Funktion Parameter ?
kopier bitte mal die Funktionsdeklaration und zwar die aus der implementation section.

Lieber Christian,
die Funktion hat keine Parameter. Und es geschieht ja auch nichts als daß eine globale Variable (stop: boolean) auf ihren Wert abgefragt wird.

Aber soviel ich weiß wird (im Assembler) doch immer beim CALL-Aufruf die Rücksprungadresse intern gespeichert, um dann bei RET wieder zurückspringen und den nächsten Befehl ausführen zu können.

Wenn ich zB folgende Programmstruktur habe:

Code: Alles auswählen

 
//procedure check;
Check:
    mov eax,eax
    ret
....
....
<hier aktueller IP>...
   call check  // kann nicht ausgeführt werden. 
   cmp eax,3
 

dann muß der Compiler doch wissen, zu welcher Adresse er beim Abschluß von Check (RET-Befehl) hinspringen muß, um dann den nächsten Befehl (CMP EAX, 3) ausführen zu können. Also muß zuerst die aktuelle Adresse gespeichert werden, oder?
Aber schon beim Speichern dieser Adresse streikt ja der Compiler und gibt die Fehlermeldung (Exception-Klasse external: SIGSEGV) aus. Das ist doch das Problem.

[Patito]

Vielleicht ist ja einfach nur dein Stack übergelaufen.
Sowas kommt z.B. vor, wenn eine Rekursion aus dem Ruder läuft. (Endlos-Rekursion)

Falls der Stack nur ein wenig zu klein ist könnte man die Stackgröße etwas hochsetzen.
Ich vermeide es aber lieber prinzipiell größere Speichermengen vom Stack zu holen und hole mir alles
was irgendwie Platz braucht immer vom Heap.