🚀 go-pugleaf

Kay Hayen (kay@edition.bonbit.org) wrote:
> Ich habe gerade ein C Projekt auf Borland C++ 4.0x portiert und aergere  
> mich jetzt tierisch.
>
> Was habe ich verbrochen, um in "faralloc" eine Exception 13 zu ernten? Das  
> gleiche passiert auch bei malloc/calloc/farcalloc und soll laut Hilfe das  
> Ueberschreiten eines Segmentes angeben. Das verstehe ich jedoch nicht,  
> weil IMHO alloc einfach 0L zurueckgeben muss, wenn ein Fehler auftritt.

Schmunzel :-)

Ich nehme schwer an, dass das nicht ein Fehler von BC++, sondern von Dir
ist. Eine Exception 13 (0x0D) ist eine allgemeine Schutzverletzung,
vermutlich ueberschreibst Du irgendwo in Deinem Programm Speicher der Dir
nicht gehoert. 

Ein Beispiel, wie Du sowas sehr elegant machen kannst ist z.B.:

        char* strdup (const char* S)
        {
            return strcpy (malloc (strlen (S + 1)), S);
        }

(Das ist mein Standard-Beispiel, wenn es darum geht, was fuer ueble Dinge
einem mit Pointern passieren koennen. Der richtige Code unterscheidet sich
nur in der Plazierung einer Klammer:

            return strcpy (malloc (strlen (S) + 1), S);

) Klammer zu.

Eine solche Schutzverletzung ist kein Aergernis, sondern eine der besten
Erfindungen seitdem T.A.Edison die erste Gluehbirne gebaut hat: Sie macht
Dich naemlich auf Fehler aufmerksam, die Du ansonsten nicht oder nur schwer
entdecken wuerdest.

Normalerweise hilft Dir Dein Debugger, den Fehler zu lokalisieren, weil er
naemlich das Programm an genau der Stelle anhaelt, an der der Fehler
auftritt. Im Falle von Fehlern in den Heap-Strukturen ist das aber meistens
mitten im Code der RTL. Es gibt Software-Pakete, die malloc/free durch
geaenderte Versionen ersetzen, wobei bei der Belegung/Freigabe bestimmte
Checks durchgefuehrt werden (eigentlich gehoert die Verwendung eines solchen
Paketes zur Pflichtuebung fuer jeden Programmierer).
Sowas kann man im uebrigen auch selber schreiben, wenn Du mehr wissen willst,
dann kannst Du Dich gerne nochmal per Mail bei mir melden.

Zusammenfassung: Geh mal davon aus, dass der Fehler in Deinem Code liegt.

Gruss


        Uz

-- 
Ullrich von Bassewitz                              uz@ibb.schwaben.com

uz@wuschel.ibb.schwaben.com (Ullrich von Bassewitz)  meinte am 11.01.96
im Brett /DE/COMP/LANG/C++
zum Thema "Re: Segment-Terror ?"


>Kay Hayen (kay@edition.bonbit.org) wrote:
>> Ich habe gerade ein C Projekt auf Borland C++ 4.0x portiert und aergere
>> mich jetzt tierisch.
>>
>> Was habe ich verbrochen, um in "faralloc" eine Exception 13 zu ernten? Das
>> gleiche passiert auch bei malloc/calloc/farcalloc und soll laut Hilfe das
>> Ueberschreiten eines Segmentes angeben. Das verstehe ich jedoch nicht,
>> weil IMHO alloc einfach 0L zurueckgeben muss, wenn ein Fehler auftritt.
>
>Schmunzel :-)

>Ich nehme schwer an, dass das nicht ein Fehler von BC++, sondern von Dir
>ist. Eine Exception 13 (0x0D) ist eine allgemeine Schutzverletzung,
>vermutlich ueberschreibst Du irgendwo in Deinem Programm Speicher der Dir
>nicht gehoert.

Nein.

[ Beispiel fuer falsche Pointerverwendung geloescht ]

Gutes Beispiel, aber mein fehlerhafter Aufruf steht allein in einer Zeile  
und bekommt nur einen integer uebergeben. Ein Programmierfehler scheidet  
aus.

>Eine solche Schutzverletzung ist kein Aergernis, sondern eine der besten
>Erfindungen seitdem T.A.Edison die erste Gluehbirne gebaut hat: Sie macht
>Dich naemlich auf Fehler aufmerksam, die Du ansonsten nicht oder nur schwer
>entdecken wuerdest.

Ja, z.B. darauf, dass die StdLib des BCC 4.0 buggy ist. Entschuldige, aber  
da aergere ich mich gewaltig. Auf die Speicherverwaltung muss sich ein  
Programmierer wenigstens verlassen koennen.

>Normalerweise hilft Dir Dein Debugger, den Fehler zu lokalisieren, weil er
>naemlich das Programm an genau der Stelle anhaelt, an der der Fehler
>auftritt.

Eben innerhalb von malloc()/faralloc()/calloc().

>Im Falle von Fehlern in den Heap-Strukturen ist das aber meistens
>mitten im Code der RTL. Es gibt Software-Pakete, die malloc/free durch
>geaenderte Versionen ersetzen, wobei bei der Belegung/Freigabe bestimmte
>Checks durchgefuehrt werden (eigentlich gehoert die Verwendung eines solchen
>Paketes zur Pflichtuebung fuer jeden Programmierer).

Es ist Sache des BCC eine fehlerfrei RTL mitzubringen.

>Sowas kann man im uebrigen auch selber schreiben, wenn Du mehr wissen
>willst, dann kannst Du Dich gerne nochmal per Mail bei mir melden.

Werde ich jetzt selbst machen muessen, siehe unten.

>Zusammenfassung: Geh mal davon aus, dass der Fehler in Deinem Code liegt.

Also nein. Der Fehler ist Windows! Dieses Pracht-BS haelt fuer die  
Speicheranforderungen nur schlappe 6000 Pointer ( ein halbes Segment ? )  
bereit. Danach ist Schluss und die allen "*alloc" Routinen des BCC 4.0  
gemeinsame lowlevel Routine merkt nicht, das die Segmentgrenze verletzt  
wird. Eigentlich muesste sie das und einen Fehler melden, aber dieser  
Check war dann wohl zuviel.

Ich werde also meine vielen kleinen Anforderungen von einer eigenen  
Speicherverwaltung zusammenfassen und selbst verwalten lassen, ausserdem  
werden noch darauf abgestimmte new/delete Operatoren dazukommen muessen.

Folge war jetzt erstmal, dass ich das Projekt nach Linux portiert habe,  
wozu ich zwei Tools geschrieben habe.

Das erste konvertiert die DOS Pfadangaben in #include Anweisungen ins  
Linuxformat. Ich hab halt immer gerne alles in getrennten Verzeichnissen  
und da musste ich dann Pfade wie "G:\Pest\inc\include.h" verwenden, die  
ich bei ca. 25 includes und 15 sources natuerlich nicht von Hand aendern  
wollte, zumal dann #ifdef faellig geworden waeren, fuer den Fall, das ich  
wieder zu DOS zurueckkehren will. So kann ich die gleichen unveraenderten  
sources mit einer zusaetzlichen Zwischenstufe im Makefile auch mit dem gcc  
uebersetzen, editiert werden die Originale.

Das zweite ersetzt die autodependancies des BCC. Es scant ein source und  
dessen includes und deren includes usw., ob es ein include findet, das  
neuer ist als dieser source, der es liest. Wenn ja wird ein touch  
losgelassen. Das minimiert die Compiles ein wenig, sonst muesste mensch  
entweder das makefile staendig anpassen, wenn neue Abhaengigkeiten  
entstehen oder im Zweifel zuviel uebersetzen.

Als naechstes steht ein mkmake auf dem Plan, es soll aus den sourcefiles  
selbst ein Makefile erstellen und warten. Sowas gibt es alles sicher  
schon, aber wer Interesse oder Anregungen hat kann sich ja mal melden, ich  
poste das gerne in dieses Brett, ist sehr kurz.

>Gruss
>
>        Uz

        Mensch liest sich, Kay


--
** *Kurze* Signaturen sind die besten **

>>>>> "Kay" == Kay Hayen <kay@edition.bonbit.org> writes:
    Kay> Das erste konvertiert die DOS Pfadangaben in #include
    Kay> Anweisungen ins Linuxformat. Ich hab halt immer gerne alles
    Kay> in getrennten Verzeichnissen und da musste ich dann Pfade wie
    Kay> "G:\Pest\inc\include.h" verwenden, die ich bei ca. 25
    Kay> includes und 15 sources natuerlich nicht von Hand aendern
    Kay> wollte, zumal dann #ifdef faellig geworden waeren, fuer den
    Kay> Fall, das ich wieder zu DOS zurueckkehren will. So kann ich
    Kay> die gleichen unveraenderten sources mit einer zusaetzlichen
    Kay> Zwischenstufe im Makefile auch mit dem gcc uebersetzen,
    Kay> editiert werden die Originale.

Wenn Du Dir die absoluten Pfade verkneifen wuerdest (unter UNIX
-I<inc-dir-base>, unter BCC kann man die Directories irgendwo im
Projekt einstellen) und die Backslashes durch Slashes ersetzt,
brauchst Du gar nichts zu machen.  DOS kann durchaus / im Pfadnamen,
nur der Kommandointerpreter besteht darauf, dass das Optionen werden
sollen.  Das letzte mal als ich BCC benutzt habe, ging das auch noch.

#include <inc/include.h>


    Kay> Das zweite ersetzt die autodependancies des BCC. Es scant ein
    Kay> source und dessen includes und deren includes usw., ob es ein
    Kay> include findet, das neuer ist als dieser source, der es
    Kay> liest. Wenn ja wird ein touch losgelassen. Das minimiert die
    Kay> Compiles ein wenig, sonst muesste mensch entweder das
    Kay> makefile staendig anpassen, wenn neue Abhaengigkeiten
    Kay> entstehen oder im Zweifel zuviel uebersetzen.

`gcc -M' macht das von ganz alleine, Borland hat die Autodependencies
schliesslich nicht erfunden sondern nur anders genannt.  Guck Dir mal
in einem GNU-Makefile an, wie `make depend' die Informationen vom
Compiler zusammenbaut.


--
Achim Gratz

--+<[ It's the small pleasures that make life so miserable. ]>+--

E-Mail: gratz@ite.inf.tu-dresden.de
Phone:  +49 351 4575 - 325

Kay Hayen (kay@edition.bonbit.org) wrote:
> Also nein. Der Fehler ist Windows! Dieses Pracht-BS haelt fuer die  
> Speicheranforderungen nur schlappe 6000 Pointer ( ein halbes Segment ? )  
> bereit. Danach ist Schluss und die allen "*alloc" Routinen des BCC 4.0  
> gemeinsame lowlevel Routine merkt nicht, das die Segmentgrenze verletzt  
> wird. Eigentlich muesste sie das und einen Fehler melden, aber dieser  
> Check war dann wohl zuviel.

BCC belegt immer groesserer Bloecke und teilt diese intern nochmal in
kleinere auf. D.h. Du kannst wesentlich mehr als diese feste Anzahl von
Bloecken belegen.

> Das zweite ersetzt die autodependancies des BCC. Es scant ein source und  
> dessen includes und deren includes usw., ob es ein include findet, das  
> neuer ist als dieser source, der es liest. Wenn ja wird ein touch  
> losgelassen. Das minimiert die Compiles ein wenig, sonst muesste mensch  
> entweder das makefile staendig anpassen, wenn neue Abhaengigkeiten  
> entstehen oder im Zweifel zuviel uebersetzen.

man gcc, Stichwort "-M" und "-MM". Das sieht z.B. so aus:

[...]
ifeq (.depend,$(wildcard .depend))
all:	your_main_target
include .depend
else
all:	depend
endif
[...]
depend dep:
	@echo "Creating dependency information"
	$(CC) -DLINUX -MM *.cc > .depend

Gruss


        Uz

-- 
Ullrich von Bassewitz                              uz@ibb.schwaben.com

kay@edition.bonbit.org (Kay Hayen) wrote:

>uz@wuschel.ibb.schwaben.com (Ullrich von Bassewitz)  meinte am 11.01.96
>im Brett /DE/COMP/LANG/C++
>zum Thema "Re: Segment-Terror ?"

>Gutes Beispiel, aber mein fehlerhafter Aufruf steht allein in einer Zeile  
>und bekommt nur einen integer uebergeben. Ein Programmierfehler scheidet  
>aus.

Das muss nichts bedeuten. Wenn du dir vorher schon irgendwo den heap
geschreddert hast, kann alles passieren. Ich hab es auch schon erlebt
das alloc einfach hängenblieb.

Inzwischen verwende ich für die Debug-Version meiner Windows-Programme
GlobalAlloc zum Speicher alloziieren und gucke beim freigeben, ob
meine dabei geschriebenen Randmarkierungen noch ok sind. GlobalAlloc
holt Protected-Mode-Blöcke von Windows (die evtl. etwas zu gross sind,
deshalb Randmarkierungen). Über ungültige Pointer lesen oder schreiben
gibt dann sofort! einen GPF.

Joachim

  
"... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden 
koennen."                       - Bertolt Brecht - Das Leben des Gallilei