Re: Suche Debughilfe: child never returns from fork?

On Sun, May 25, 2008 at 01:31:00AM +0000, Peter Much wrote:
> <de-bsd-questions(at)de.freebsd.org, pmc(at)citylink.dinoex.sub.org> aka Oliver Fromme schrieb
> mit Datum Sun, 13 Apr 2008 14:26:33 +0200 (CEST) in m2n.de.fbsd.questions:
>
> |Peter Much wrote:
> | > Bernd Walter wrote:
> | > > [...]
> | > Ich hab dann die Suche aufgegeben und das Problem einfach auf die
> | > (ganz unsportliche) hau-ruck Methode beseitigt: sleep(1) im Parent
> | > nach dem fork(). Das hilft - aber das war mir eigentlich von
> | > vorneherein klar, dass es ein Timing-Issue ist - und da ich am
> | > Client nix drehen kann weil der gar nicht erst aus dem fork()
> | > rauskommt, muss es am Parent liegen.
> |
> |Ja, dass es ein Timing-Problem in der Software sein muss,
> |war anhand Deiner Beschreibung ziemlich klar.
>
>
> Aber ja doch. Wow, Leute, das war ja mal wieder so richtig eine
> Aktion mit Prädikat VOLL DANEBEN !!!

Kein Grund gleich rumzuschreiben.
Außerdem sind deine Argumente ohnehin haltlos.

> Dass es sich da um den bekannten und schon seit 4.Februar in HEAD
> korrigierten FreeBSD-defect "EN-08:01.libpthread" handeln muß, der
> sehr gut meiner Beschreibung entspricht, das hätte ja mal jemand
> hier sagen können!

Announced: 2008-04-17

Woher nimmst du die Erkennniss, das etwas in HEAD korigiert wurde?
Der report bezieht sich ausschließlich auf RELENG_6.

> Na, ich werd jedenfalls künftig noch weniger auf das geben, was
> sich selbst für kompetent erklärende Leute im Brustton der
> Überzeugung von sich geben, und noch mehr auf meine Intuition
> vertrauen.

Jetzt schau mal an, von wann dein Thread ist.
Sorry, dass das mit den Kristallkugeln keine zuverlässige Sache ist.
commitlog in RELENG_6 verfolge ich auch nicht mehr so oft, weil halt
alle meine Maschinen laufen und Sicherheitsprobleme bekannt gegeben
werden.

Mal abgesehen davon bleiben unsere Argumente, dass die Software unsauber
programmiert ist.
Nicht mal der "Hello World" Part ist richtig.
Bei so vielen Fehlern obliegt es der Wahrscheinlichkeit genau an der
Stelle nach dem Fehler zu suchen.
Wenn irgendwo ein Misthaufen liegt, dann vermutet natürlich jeder, dass
der Gestank von dort kommt und nicht irgendwo anders her.

Und um noch mal ein drauf zu setzen:
This affects any threaded
application that invokes fork(2), most frequently those that call
fork(2) before execve(2) or system(3) to run external programs.

Würde mich nicht wundern, wenn genau das, oder vergleichbares passiert.
fork(2) vor einem execve(2), bzw. system(3), was kein normal denkender
Programmierer macht, weil es absolut null Sinn macht.
Wenn fork(2) von Threaded Anwendungen allgemein derartige Probleme
gehabt hätte, dann wäre das schon viel früher aufgefallen.
Immerhin macht unter anderem Apache genau das auf unzähligen Webservern.
Eine sauber programmierte Software hat dieses Problem also offensichtlich
nicht.
Kurzum: Die Software ist trotz alledem nicht ganz Schuldlos.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message