Hallo,

Ich hatte gehofft, dass sich dieser Thread beendet ist, weil meine Loesung (siehe email) gluecklicherweise funktioniert, wobei ich mir deren Unsauberkeit bewuszt bin.

Aber um Heikos email zu beantworten...

Ist SIGBUS die Entsprechung zu SIGSEV beim SunOS? Denn ich kenne eigentlich nur SIGSEV bei malloc- und anderen Speicherproblemen.

signal(5) sagt unter anderem:

The signals currently defined by <signal.h> are as follows: Name Value Default Event SIGBUS 10 Core Bus Error SIGSEGV 11 Core Segmentation Fault

Hat eventuell noch jemand eine Kopie des gemallocten Speichers? (Obwohl dann natürlich das Problem nicht beim malloc auftauchen sollte, sondern anderswo.)

Ich wuszte, dasz in der rekursiven Aufrufshierarchy befindliche Funktionen Pointer auf bereits geloeschte Datenbereiche halten. (Haette meine Flag-basierte Loesung nicht funktioniert, haette ich als naechstes probiert, den Pointerinhalt der "Elternfunktion" zu loeschen, ala: (schemenhaft reproduziert)

struct S { int foo; };

void proc(struct S *sp, struct S **spp) { if (<Bedingung>) { free(sp); *spp = NULL; } /* ... */ }

void fnRec(struct S *sp, struct S **spp) { if (Bedingung) return; /* ... */ proc(sp, spp); if (!sp) { sp = (struct S *) malloc(sizeof(struct S)); spp = &spp; } fnRec(sp, spp); /* ... */ }

Es gibt bestimmt noch weitere, bessere? Alternativen. Sei's drum, Flags scheinen zu funktionieren. (Noch, deshalb will ich lieber aufhoeren.)

Vielleicht auch einfach nur weiche Hardware?

Nun ja, eine Sun ULTRAsparc 5, 300MHz, 128 MB RAM, 512 MB swap. Weich?

Es ist ja auch (MMN) ausdrücklich verboten, den selben Pointer mehrmals zu free()en.

Korrekt. Aber der Fakt, dasz mein Prog immer in malloc() abstuerzte, ist schon seltsam.

MfG Matthias. --- E-Mail: mf14@inf.tu-dresden.de