new operator in VC++ 5.0 produziert Schutzverletzung in Kernel

Programmieren - alles kontrollieren 4.941 Themen, 20.715 Beiträge

new operator in VC++ 5.0 produziert Schutzverletzung in Kernel

(Anonym) am 12.03.2001, 00:00 / 5 Antworten / Baumansicht

wenn ich mit new ein Feld (Größe ~3600) Einträge (a 32 Byte) beantrage geht das beim ersten mal gut. Später brauche ich ein zweites Feld(~7100 Einträge a 32 Byte). Compile, Link, Build alles kein Problem. Bei der Ausführung bricht er jedoch, genau bei der Speicherreservierung ab. Der Aufruf-Stack ist von new über malloc bis in die KERNEL vorgedrungen und dann geht nix mehr.
"Unhandled Exception in ... (KERNEL32.DLL) 0x0000005 Access Violation"

int i = 3600;
Point* t;
t = new Point[i];
...
i = 7100;
Point* g;
g = new Point[i]; // hier passierts

Speicher hab ich noch genug (mit GlobalMemoryStatus getestet)
kann mir jemand helfen? Welche gründe kann eine Access Violation haben?

Danke fürs lesen,
Dreamforger

thomas woelfer

(Anonym) „new operator in VC++ 5.0 produziert Schutzverletzung in Kernel“

13.03.2001, 00:00 Optionen

dein code (der gepostete) ist sowiet ok. kannst du das ganze in ein kleines uebersetzbares programm giessen das auch diesen fehler aufweist? falls ja: hier posten, dann kann man mehr sagen.

WM_GOODLUCK
thomas woelfer

Dreamforger

thomas woelfer „dein code der gepostete ist sowiet ok. kannst du das ganze in ein kleines...“

13.03.2001, 00:00 Optionen

Ich habs versucht, "dummerweise" funktioniert's in kleineren Projekten. Und den ganzen Code hier zu posten ist übertrieben.

Vieleicht liegt das Problem auch in Nicht dokumentierten eigenschaften von new.

Ich benutze new
- in einer Win32 Anwendendung (int WINAPI WinMain....)
ohne Nachrichten schleife (App läuft nur einmal durch)
- um ein Feld von Klassen zu erzeugen (t)
- um ein Feld von D3DVERTEX Strukturen zu erzeugen (g)

die Daten aus t werden in g umgespeichert, (by Value nicht by Name)
und t wird freigeben.

Jenachdem in welcher Reihenfolge die (unabhängigen) Code - Blöcke stehen

- versagt D3DVERTEX* g= new D3DVERTEX[7100];
- versagt der Zugriff auf g[>7000]
- versagt delete[] g;

liegt das an besonderen Eigenschaften von D3DVERTEX? offiziel wird der operator new nicht bezüglich D3DVERTEX geändert (Dx7 SDK). Die structure sollte also wie alle anderen auch Instantiierbar sein, oder.

Dreamforger

TranslateMessage();
PostMessage( woelfer, WM_THANX, dw_MAX, dw_MAX);

thomas woelfer

Dreamforger „ Ich habs versucht, dummerweise funktioniert s in kleineren Projekten. Und den...“

13.03.2001, 00:00 Optionen

was mich irritiert ist das du eine gp fault bekommst... beim drueber nachdenken faellt mir dazu ein: vermutlich nimmst du nicht das debug build sondern eine release build zum testen. wuerde als erstes mal empfehlen ein debug build herzunehmen --- vermute das du dann bereits vor dem gp eine assertion failure bekommst (die debug variante der speicherbibliothek ist ganz gut): das sollte mehr sinnvolle hinweise auf den grund des problems geben.

ich vermute das du beim kopieren der daten den block einfach zerstoerst... aber das sollte bei der debug variante schnell rauskommen.

WM_HOPETHISHELPS
thomas woelfer

Dreamforger

thomas woelfer „was mich irritiert ist das du eine gp fault bekommst... beim drueber nachdenken...“

13.03.2001, 00:00 Optionen

Ich habe mein Problem zwar noch nicht lösen können, weis aber in der Zwischenzeit wenigstens wo warscheinlich der Wurm war.

In den Feldern sind zeilenweise linearisierte Felder abgespeichert, in denen ich mittels Interpolation aus Stützwerten Ebenen mache.
Ich habe bloß ca 5% des nicht veralgemeinerbaren Randverhaltens übersehen. (Das wiederum habe ich mit Massenhaft assert( )'s rausgefunden)

Offensichtlich habe ich, nachdem meine Lin-fkt das Feld verlassen hat, irgendwelche wichtigen Daten zerschossen.

Jetzt brauch ich erstmal 'ne Mütze Schlaf! (01:40). G'nacht

Dreamforger

P.S ich habe immer zwischen DEBUG und RELEASE modus rumgeschaltet und bin wohl im letzteren hängen geblieben...

Dreamforger

thomas woelfer „was mich irritiert ist das du eine gp fault bekommst... beim drueber nachdenken...“

15.03.2001, 00:00 Optionen

Ok der Fehler ist jetzt behoben. Der Fehler war im "Allee-Problem" - ich hab den "Baum" am Ende der Strasse vergessen ;-)

Ich finds dennoch erstaunlich war für extreme Fehler man dadurch bekommen kann....

Danke nochmal für den Beistand

Dreamforger

WM_QUIT