Re: Suche Debughilfe: child never returns from fork?

Bernd Walter wrote:
> Peter Much wrote:
> > Hm? Ich dachte, man darf das an sich schon so machen, solange man
> > sicherstellen kann, dass zwischen dem free() und dem "next" kein
> > alloc() passiert? (Was natürlich dann wieder solche Sachen wie
> > sighandler ernstlich in frage stellt...)
>
> Nein - der free könnte ja z.B. dadurch eine komplette Speicherseite
> freigeräumt haben und hat den physikalischen Speicher dann brav an
> den Kernel zurück gegeben.
> Der nächste Zugriff wäre dann ein logischerweise ein segfault.

Ganz genau. Es hängt halt von der jeweiligen malloc-
Implementation ab, ob es (zufällig) geht oder nicht.
Dass es auf einem bestimmten OS (z.B. Linux) verlässlich
geht, heißt noch lange nicht, dass es überall geht.

Wenn ein Speicherbereich freigegeben wurde, dann ist
jeder Pointer, der noch darauf zeigt, ungültig, und
jeder Zugriff darauf ist illegal. Punkt.

> > | Übrigens bin ich der Meinung, dass Signal-Handler für SIG-
> > | SEGV in mindestens 90% der Fälle vollkommen überflüssig
> > | und sogar eher schädlich sind.
> >
> > Sehe ich eigentlich auch so. Werde wahrscheinlich dazu übergehen
> > diese Dinger wegzulassen.
>
> Besser ist das.
> Du brauchst im Regelfall höchsten ein paar Handler.
> Der klassische Bedarf ist für SIGCHLD und SIGPIPE.

Genau. Je nach Tool werden gelegentlich noch SIGHUP und
SIGINFO sinnvoll belegt. (Ich wünschte sogar, mehr Pro-
gramme würden SIGINFO verwenden.)

Nur um mal konkrete Beispiele für Fehler bei Signal-
Handlern zu nennen, die man leider immer wieder in
irgendwelchen Programmen sieht:

int signal_received = 0;
void sig_handler(int s)
{
        signal_received = 1;
}

oder:

void sig_handler(int s)
{
        printf("Got some signal!\n");
}

oder:

void sig_handler(int s)
{
        kill(some_pid, SIGUSR1);
}

Wer nicht weiß, was in jedem der genannten Fälle der
Fehler ist, möge bitte keine Programme mit Signal-
Handlern schreiben, ohne vorher ein gutes Buch zu
lesen. :-)

Das Gemeine bei solchen Fehlern ist, dass sie häufig
unbemerkt bleiben, weil es tausendmal funktioniert.
Nur beim 1001. Mal kommt das Signal im »falschen«
Augenblick und produziert subtile Probleme. Häufig
hängt es von winzigen Timing-Differenzen ab, so dass
es z.B. auf dem Rechner des Entwicklers nie passiert,
aber auf einem anderen (schnelleren oder langsameren)
Rechner dafür umso häufiger. Oder es tritt nur auf
SMP-System auf, aber nie auf UP-Systemen, oder umge-
kehrt. Solche Dinge sind _sehr_ schwer zu debuggen.
Daher muss man gerade bei der Programmierung von
Signal-Handlern besonders aufmerksam sein.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
I suggested holding a "Python Object Oriented Programming Seminar",
but the acronym was unpopular.
        -- Joseph Strout
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message