WLT: lvrouted op stadhuis nodes

Lodewijk Voge lodewijk at cope.xs4all.nl
Mon Apr 4 00:20:36 UTC 2005


hallo,

na de verkeerde wie-is-er-geassocieerd-code gefixed te hebben, het 
enige stuk code dat significant anders is dan voor de 5.0 nodes, bleek 
dat de daemon na een tijdje core dumpt, vooral op stadhuis3.

ik heb er wat aan zitten debuggen, en het is nogal bizar. ik heb wat 
gefixed, en hij houdt het nu al een half uur uit op stadhuis3 (een stuk 
meer dan eerst), maar als het dat inderdaad is is het heel vreemd dat 
dat nu pas problemen geeft.

na wat moeite kreeg ik een goeie coredump te pakken (voor posterity: 
start met -f vanuit /tmp, dan doet 'ie geen daemon() call en komt de 
coredump ook in /tmp terecht). de backtrace liet zien dat het in de 
boom-uitpak code zat. dat is het hart van het hele programma. het is 
ook zo geschreven dat het voorzichtig is de gegeven buffer niet te 
buiten te gaan. de enige manier dat dat kan coredumpen is als de 
pointers die het krijgt, van ocaml of van zichzelf (het is recursief), 
niet goed zijn.

na wat prutsen met gelogde packets, valgrind en al dat meer blijkt de C 
code zelf goed te zijn, zoals ik verwachtte. dat ocaml verkeerde 
pointers geeft is daarmee het meest waarschijnlijk, maar nog altijd 
vrij onwaarschijnlijk op zich. de ocaml runtime doet zo vreselijk veel 
pointer gegoochel dat een corrupte ocaml heap veel eerder in ocaml code 
voor problemen zou zorgen dan in C code.

maar toen ging er vaag lampje branden en wat lezen bevestigd het: een 
garbage collection cycle kan een memory compaction cycle bevatten. 
allocatie van ocaml data structuren in C code kan een garbage 
collection cycle triggeren. de buffer waar de code op werkt kan 
verplaatst worden terwijl het er mee bezig is, en daar had ik niet op 
gerekend. nu draait er een versie die eerst die buffer kopieert naar de 
C heap, dan kan ocaml compacten wat het wil zonder problemen.

nu is het bizarre dus dat dit er vanaf het begin zo in zit. ik heb geen 
idee waarom het juist nu en alleen op die nodes de kop op steekt. 5.0 
vs 5.4-PRERELEASE lijkt me onwaarschijnlijk, dit gaat over het interne 
geheugen management van ocaml. de nieuwe ocaml versie met het 
geheugenlek eruit ook, de daemons op de rest van het netwerk zijn daar 
ook mee gecompiled. er is vzikz niets bijzonders aan de configuratie op 
stadhuis3. mysterie, dus.

Lodewijk






More information about the Techniek mailing list