Nochmal im richtigen Forum: Speicherzugriffsfehler auf 64-Bit Architektur

Wutz

cout << "triangulation.point " << triangulation.point << endl;

Sieht so aus, als wenn du immer noch nicht im richtigen Forum bist und die Möchtegern-OOPler besser passen würden, aber da du malloc benutzt, sei dir verziehen

Dass dein Code dringend eine Aufräumorgie nötig hat, um z.B. solche wie die geschilderten Probleme besser analysieren zu können, dürfte auch dir als Nichtinformatiker klar sein? (zu lange Funktion, zuviele for, zuviele Variablen...)

long_buf = (long *)buffer;
  nctri_read_tri_pkt_bdry(cdfid, points_bdry_var, long_buf, 0, npoints);

Hier wird mit dem fraglichen Speicherbereich was gemacht, auch schreibend?

double_buf = (double *)buffer;
  nctri_read_tri_pkt_x_or_y_c(cdfid, points_xc_var, double_buf, 0, npoints);

Hier wird mit demgleichen armen Speicherbereich nochmal was gemacht, dieser aber komplett anders interpretiert als zuvor. Müsste hier schon knallen, wenn sizeof(long)!=sizeof(double).

three_long_buf = (long (*)[3])buffer;
  nctri_read_tri_pts_or_nbs(cdfid, tri_points_var, three_long_buf, 0,
                            ntriangles);

Zum 3.Mal wird der Speicherbereich anders interpretiert, das auch noch mit einem häßlichen Cast und hier knallt es dann ja wohl auch:

tri->pnt[j] = pt_ptr[three_long_buf[i][j]]; /*Hier tritt der Speicherzugriffsfehler auf.*/

Der Fehler dürfte sein, dass du den alles entscheidenden buffer zuwenig Speicherraum zuweist in

bsize = 3 * triangulation.ntriangles * (int)sizeof(long);

Versuche es mal mit

bsize = 3 * triangulation.ntriangles * (int)sizeof(*long);

da auf 32-Bit Systemen meistens sizeof(long)==sizeof(*long) ist, bei 64-Bit jedoch nicht, dürfte hier schon mal nach rein visuellem Test, ohne den Compiler/Debugger zu bemühen, der (ein?) Fehler liegen.

Zur Erinnerung vielleicht noch mal, gemäß ANSI C gilt:
sizeof(*double)==sizeof(*float)==sizeof(*long)==sizeof(*int)==sizeof(*short)==sizeof(*char)==sizeof(*void)==sizeof(size_t)==sizeof(ptrdiff_t)
sowie
1==sizeof(char)<=sizeof(short)<=sizeof(int)<=sizeof(long)

Elina

Hallo, danke fuer deine ausfuehrliche Antwort, im C++ Forum wollten wurde ich hierher geschickt

Leider weiss ich nicht, was da im Code genau passiert, und vor allem warum, sonst könnte ich da mal aufräumen. So trau ich mich da nicht ran.

Die nctri_...funktionen ueberschreiben tatsächlich den Speicher. Wie genau weiss ich nicht, da ich keinen Zugriff auf die Funktionen habe.

Müsste hier schon knallen, wenn sizeof(long)!=sizeof(double).

Hm, bei 32-Bit gilt doch sizeof(long)==sizeof(double)?

bsize = 3 * triangulation.ntriangles * (int)sizeof(*long);

Das hab ich jetzt versucht, und bekomm eine Fehlermeldung. Ich verstehe ehrlich gesagt nicht wozu man das machen soll?

abc.w

@Elina: Ich würde den Code vielleicht wie folgt debuggen: In deinem Code-Ausschnitt

for(i = 0, tri = triangulation.triangle; i < ntriangles; i++, tri = tri->succ) 
    for(j = 0; j < 3; j++){ 

      tri->pnt[j] = pt_ptr[three_long_buf[i][j]]; /*Hier tritt der Speicherzugriffsfehler auf.*/ 
    }

gibt es 3 Zeiger (weil ntriangles ist scheinbar 3): three_long_buf[0], three_long_buf[1], three_long_buf[2]. Diese müssen gültig sein (ungleich NULL, "sinnvolle" Adressen). Wenn nicht, dann im Code davor schauen, warum nicht...

Diese Zeiger werden in den Schleifen noch dereferenziert: three_long_buf[0][0], three_long_buf[0][1], three_long_buf[0][2], three_long_buf[1][0], three_long_buf[1][1], three_long_buf[1][2], three_long_buf[2][0], three_long_buf[2][1], three_long_buf[2][2]. Was immer da dereferenziert wird, es muss einen Wertebereich [0...3] haben, weil es gibt nur pt_ptr[0], pt_ptr[1], pt_ptr[2] und pt_ptr[3] (weil npoints ist scheinbar 4). Ist three_long_buf[i][j] kleiner 0 (es kann kleiner 0 sein, weil Datentyp long) oder größer 3 - das ist falsch, d.h. davor im Code schauen, warum...

Wenn die ganzen Zeiger und Wertdebereiche ok sind, dann stimmt irgendwas mit dem tri-Zeiger nicht und folglich mit dem tri->succ...

Viel Glück beim Debuggen

Wutz schrieb:

Zur Erinnerung vielleicht noch mal, gemäß ANSI C gilt:
sizeof(*double)==sizeof(*float)==sizeof(*long)==sizeof(*int)==sizeof(*short)==sizeof(*char)==sizeof(*void)==sizeof(size_t)==sizeof(ptrdiff_t)

kann doch fast nicht sein oder etwa doch

Elina schrieb:

Hm, bei 32-Bit gilt doch sizeof(long)==sizeof(double)?

nee das kann man so nicht sagen oder?

und da ich jetzt zu faul bin um das rauszusuchen

5.2.4.2

ich dachte immer sizeof(*int) == sizeof(int)

Elina schrieb:

bsize = 3 * triangulation.ntriangles * (int)sizeof(*long);

Das hab ich jetzt versucht, und bekomm eine Fehlermeldung. Ich verstehe ehrlich gesagt nicht wozu man das machen soll?

ist ja auch logisch bei so nem prallen beispiel... also

int x = 11;
int *px = &x;
sizeof(*px) == sizeof(int)

double x = 11;
double *px = &x;
sizeof(*px) == sizeof(double)

so sollte das stimmen, bin auch schon etwas eingerostet

btw. wenn mein counter zu hoch ist, dann müßte der von Wutz negativ sein :p

Wutz

Elina schrieb:

Hm, bei 32-Bit gilt doch sizeof(long)==sizeof(double)?

ANSI C sagt nichts über den Größenvergleich zwischen Gleitkomma- und Nichtgleitkommazahlen aus.
Wenn du dich nicht an den Code rantraust, bist du denkbar ungeeignet für die Aufgabe, ihn zu korrigieren/portieren.

no_code

Wutz schrieb:

Wenn du dich nicht an den Code rantraust, bist du denkbar ungeeignet für die Aufgabe, ihn zu korrigieren/portieren.

wohoo, meldet sich da jemand freiwillig zum portieren/debuggen

edit: btw. soweit ich weiß werden frauen da mangelware in diesem forum bevorzugt behandelt...