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(a)inf.tu-dresden.de