Re: Suche Debughilfe: child never returns from fork?

Peter Much wrote:
> Muss ich sagen, dass ich von 6.3 nicht übermäßig begeistert bin?
> (Ich bau seit vier Monaten Bugs raus. Aus *allem* - Ports, User,
> Kernel, Scripts, aus meinem Kopf;), ...)
> Das fällt aber unter P.P.; braucht nicht als Kritik verstanden zu
> werden. Ich weiss ehrlich gesagt nicht worans liegt - vielleicht werd
> ich einfach langsam alt...

Ich habe mit 6.3 bisher eigentlich gute Erfahrungen ge-
macht, obwohl ich auf den meisten Rechnern inzwischen
bereits auf FreeBSD 7 (-stable) geschwenkt bin.

> Ich nix wissen. Ich habs nicht geschrieben. Es heißt Bacula
> (in diesem Fall der Client), und ist konzeptionell die beste
> Backup-Strategie die mir in Freeware bislang untergekommen ist
> - in der Ausgestaltung muss halt noch ein Stück Arbeit reingesteckt
> werden.

Öhm ... Bacula mag von der Theorie her gut sein, aber
die praktische Umsetzung hat schon gewisse Haken.
Als ich es mir mal angesehen hatte, war der Quelltext
eher abschreckend. Ist zwar schon einige Zeit her,
aber mein Vertrauen in Bacula ist sehr, sehr dünn.

> Aber das find ich besser als andersrum... hat so die Qualität
> eines sendmail: man kann beinahe alles biegen, aber oft nicht
> ganz so wie man sichs vorstellt...

Der Sendmail-Quelltext ist um Größenordnungen besser.

> Z.B. wenn ich den Server (korrekt) mit SigTERM beenden will,
> dann geht er geht in eine Endlosschleife und beendet sich erst
> mit einem weiteren SigTERM. Ich hab in der Userbase gefragt wem
> es noch so geht, aber keiner von den (weitestgehend Pinguin-)Usern
> konnte es reproduzieren.

Tja, der Krempel ist einfach unportabel programmiert.
Ich vermute, der/die Autor(en) haben weder den C-Standard
noch irgendwelche guten UNIX-Programmierbücher (Stevens
o.ä.) jemals in den Finegrn gehabt. Das führt dann dazu,
dass die Programme jede Menge undefiniertes Zeugs machen,
was unter Linux zufällig funktioniert.

> Dann hab ich im Code gesucht und finde ein Konstrukt dieser Art:
> while(c = next(c)) free(c);

Da kräuseln sich jedem C-Programmierer die Zehennägel.
Ich kommentiere das lieber nicht weiter.

> Interessant sind allerdings zwei Fragen:
> 1. wieso macht sowas den Pinguinen nichts aus, und

Wie gesagt, reiner Zufall bzw. Glück. Wenn man einen
ungültigen Pointer verwendet und die erwarteten Daten
liegen dort zufällig noch (aufgrund OS-spezifischer
Umstände wie z.B. die jeweilige malloc-Implementation),
dann ist das Glück. Portabel ist was anderes.

> 2. wieso geht im FreeBSD dabei der Prozess in eine Endlosschleife?

Weil die Daten halt anders im Speicher liegen als unter
Linux. Wenn man portabel und standardkonform programmiert,
dann macht das nichts aus. Aber wenn man einen ungültigen
Pointer dereferenziert, ist das Verhalten undefiniert.
Und »undefiniert« beinhaltet alles mögliche: Es kann
zufällig korrekt funktionieren, es kann in eine Endlos-
schleife gehen, es kann abstürzen, es kann alle Dateien
in Deinem Home löschen, es kann obszöne E-Mails an alle
anderen User auf dem System schicken, oder sonstwas.

> Nächste interessante Frage: zur Fehlerbehandlung bei Null-Pointer-
> Referenzen wird folgender Code verwendet:
>
> if (type == M_ABORT) {
> char *p = 0;
> p[0] = 0; /* generate segmentation violation */
> }

Auweia. Aua. Das ist Aprilscherz-verdächtig. Dummerweise
ist der 1. April schon 'ne Weile vorbei.

Offenbar hat sich Bacula nicht verbessert, seit ich es mir
zuletzt angeschaut hatte.

> Und das scheint nun wiederum mit genau 37 verbogenen Signalhandlern
> zu tun zu haben die man da zu brauchen meint...
> Es scheint sich da so zu verhalten, wenn das Programm auf ein SigTERM
> hin beendet wird, und derweil die SEGV erfolgt, dass dann das
> Programm weder crasht noch beendet, sondern endlosschleift. Irgendwie
> nicht wirklich sinnvoll - da muss es doch brauchbarere Optionen
> geben...

Bei der Programmierung von Signal-Handlern gibt es ein paar
Grundregeln, an die man sich halten muss. Das kann man
nicht einfach mal so nach dem Muster »mal ausprobieren,
ob das so funktioniert« machen.

Ü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.

> Und immer noch die Frage: warum stört sowas die Pinguine nicht?

Die Software ist halt nicht portabel programmiert.

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
(On the statement print "42 monkeys" + "1 snake":)  By the way,
both perl and Python get this wrong.  Perl gives 43 and Python
gives "42 monkeys1 snake", when the answer is clearly "41 monkeys
and 1 fat snake".        -- Jim Fulton
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message