J'ai un peu peur, tu n'as pas compilé avec -lc_r comme option j'éspère ? Bien "-pthread" comme cela doit être fait (voir FAQs, mans et livres de sorcellerie).
>> vi, vi -pthread et -lc_r ;)
Les threads natifs comme tu les appellent sont ceux accessible à travers cette interface que sont les pthreads, donc j'ai du mal à suivre ton histoire de pthread /= threads natifs.
> j'ai repris le terme employé je ne sais plus
> ou, quand je dis thread natifs, je ne parles
> plus des gnu pth.
Si tu me parles de GNU pth là je comprends un peu mieux.
> heh
Lier directement un programme avec libc_r (c-à-d sans l'option "-pthread" pour le linker) est très gruik, et surtout risque fortement de déconner grave ... (cf. archives des ml open)
J'avoue que je ne vois pas comment compiler avec "-pthread" peut changer quelque chose sur des services qui n'utilisent pas les pthreads au départ. Je parle uniquement de ce qui fait partie de la base (sendmail, ftpd (donc inetd) et ssh dans les noms que tu as cités).
> j'ai pas ete voir les sources, je pense pas
> avoir le niveau (d'ailleurs non seulement je
> pense pas, mais en plus je suis SUR de ne pas
> l'avoir) pour aller voir pourquoi tel service
> merde quand il est compilé de telle ou telle
> facon. Marrant que tu parles d'inetd, j'ai pas
> essayé du tout inetd, tout tournait en
> standalone (du moins chez moi).
Bon, voyons ce que tu as posté sur misc@open
marc.theaimsgroup.com/?l=openbsd-misc&am
Sinon, après avoir lu ce que tu as posté ...
Tu utilisais un apache compilé à la main, curieux ...
> je suis pas un grand fan des ports ;)
Tu t'es fait éconduire car tu ne fournissait pas de détails ...
> tu doit pas lire le bon, le thread etait assez
> long, j'ai même fournit l'executable qui
> permettait de tester si la machine subissait
> le crash ou non.
>
> j'ai fait pas mal de post sur les mailing d'
> open, cherche encore ;)
Quand tu as recompilé tout pour que ça marche désormais, qu'as-tu recompilé ? Juste la libc_r, ou le noyau aussi ou tout ?
> j'ai d'abord recompilé libc_r, pis apres je me
> suis appercut que cette lib etait utilisée par
> pas mal d'autres libs, alors je me suis dit qu'
> il fallait recompiler toutes les libs, j'ai
> fait un gros make build. Mais comme j'ai lu a
> un moment KERNEL_PTHREAD lors d'une compilation
> j'en ai déduit que le kernel devait influencer
> donc... la totale.
Ça ressemblait plus à une panne hard ou un driver buggé mais bon ...
D'autres gens ont eu un problème, un bon vieux "mb_map full", cf FAQ OpenBSD pour régler ça, et ça ne fait même pas tomber la machine, juste la rendre indisponible une demi-minute).
> nan rien a voir, ca ca se corrige en optimisant
> le kernel ca. Meme en ayant optimisé à fond le
> kernel, on peut toujours crasher Open.
Perso je n'ai le problème sur aucune de mes deux machines (une en -current (x86, carte réseau "vr"), l'autre 2.9-stable (sparc, carte réseau "le")).
[^] # Re: Remote DoS
Posté par Gilles Chehade . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 1.
>> vi, vi -pthread et -lc_r ;)
Les threads natifs comme tu les appellent sont ceux accessible à travers cette interface que sont les pthreads, donc j'ai du mal à suivre ton histoire de pthread /= threads natifs.
> j'ai repris le terme employé je ne sais plus
> ou, quand je dis thread natifs, je ne parles
> plus des gnu pth.
Si tu me parles de GNU pth là je comprends un peu mieux.
> heh
Lier directement un programme avec libc_r (c-à-d sans l'option "-pthread" pour le linker) est très gruik, et surtout risque fortement de déconner grave ... (cf. archives des ml open)
J'avoue que je ne vois pas comment compiler avec "-pthread" peut changer quelque chose sur des services qui n'utilisent pas les pthreads au départ. Je parle uniquement de ce qui fait partie de la base (sendmail, ftpd (donc inetd) et ssh dans les noms que tu as cités).
> j'ai pas ete voir les sources, je pense pas
> avoir le niveau (d'ailleurs non seulement je
> pense pas, mais en plus je suis SUR de ne pas
> l'avoir) pour aller voir pourquoi tel service
> merde quand il est compilé de telle ou telle
> facon. Marrant que tu parles d'inetd, j'ai pas
> essayé du tout inetd, tout tournait en
> standalone (du moins chez moi).
Bon, voyons ce que tu as posté sur misc@open
marc.theaimsgroup.com/?l=openbsd-misc&am
Sinon, après avoir lu ce que tu as posté ...
Tu utilisais un apache compilé à la main, curieux ...
> je suis pas un grand fan des ports ;)
Tu t'es fait éconduire car tu ne fournissait pas de détails ...
> tu doit pas lire le bon, le thread etait assez
> long, j'ai même fournit l'executable qui
> permettait de tester si la machine subissait
> le crash ou non.
>
> j'ai fait pas mal de post sur les mailing d'
> open, cherche encore ;)
Quand tu as recompilé tout pour que ça marche désormais, qu'as-tu recompilé ? Juste la libc_r, ou le noyau aussi ou tout ?
> j'ai d'abord recompilé libc_r, pis apres je me
> suis appercut que cette lib etait utilisée par
> pas mal d'autres libs, alors je me suis dit qu'
> il fallait recompiler toutes les libs, j'ai
> fait un gros make build. Mais comme j'ai lu a
> un moment KERNEL_PTHREAD lors d'une compilation
> j'en ai déduit que le kernel devait influencer
> donc... la totale.
Ça ressemblait plus à une panne hard ou un driver buggé mais bon ...
D'autres gens ont eu un problème, un bon vieux "mb_map full", cf FAQ OpenBSD pour régler ça, et ça ne fait même pas tomber la machine, juste la rendre indisponible une demi-minute).
> nan rien a voir, ca ca se corrige en optimisant
> le kernel ca. Meme en ayant optimisé à fond le
> kernel, on peut toujours crasher Open.
Perso je n'ai le problème sur aucune de mes deux machines (une en -current (x86, carte réseau "vr"), l'autre 2.9-stable (sparc, carte réseau "le")).
> on a été environ une 50aines à tester, 80% des
> personnes qui tournaient sous Open on subit le
> crash, que ce soit sur des i386, des sparcs,
> des alphas.
Tu devrais envoyer un vrai bug report chez open.
> c'est fait depuis un moment déjà, mais c'est
> plus la peine d'en faire un vu que ca a été
> apparemment corrigé dans -current.