tlibimp hängt in virtueller Maschine von Jenkins

[Andreas Tscharner]

Hallo Welt,

Wir haben unser Build System neu aufgesetzt. Dabei haben wir die
Build-Maschinen virtualisiert. Als CI System kommt Jenkins zum Einsatz

Nun haben wir das Problem, dass manchmal(!) der tlibimp.exe hängen
bleibt. Leider konnten wir kein Muster erkennen; es gibt Feature
Branches, da läuft alles problemlos durch, dann gibt es welche, die
immer hängen (wenigstens immer am gleichen Ort) und dann gibt es noch
solche, die mal hängen und mal nicht.

Auch konnten wir das Problem keiner virtuellen Maschine zuordnen (wäre
auch komisch, schliesslich sind alle von ein und derselben Maschine
geklont worden).

Lokal, d.h. auf jedem Rechner der Entwickler (direkt auf Blech)
funktioniert das immer.

System:
Host: Debian Linux testing, 64 GB RAM, die VMs sind auf einem SSD RAID,
das restliche System auf einer "normalen" HDD
Hypervisor: Libvirt (mit entsprechendem Plugin für Jenkins), qemu lässt
die virtuellen Maschinen rennen
Virtuelle Maschinen: Win7, 4GB RAM, 80 GB Festplatte
Delphi: XE2
Jenkins: 1.628, 4 lokale Slots (um Tests zu starten) und 8 "Knoten",
sprich 8 VMs mit je einem Slot (verhindert Probleme, die mit der
Registrierung von Komponenten auftreten könnte).

Beim Output kann ich nichts erkennen, da der Build einfach stehen
bleibt; in der Ereignisanzeige von Windows erkenne ich auch nichts. Dass
es tlibimp ist, weiss ich, weil das der aktuelle Aufruf ist, und im
TaskManager auch immer eine Instanz hängt.

Hat jemand ähnliche oder gleiche Probleme erfahren? Wo kann ich
ansetzen, um das Problem einzugrenzen?

Freundliche Grüsse
WENZEL Metromec AG
Andreas Tscharner

[Sven Lanoster]

Post by Andreas Tscharner
Hat jemand ähnliche oder gleiche Probleme erfahren? Wo kann ich
ansetzen, um das Problem einzugrenzen?

Wenn ich wetten müsste, würde ich auf einen defekten RAM-Riegel setzen.
Vielleicht nicht defekt, sondern nur alt, so dass er das Timing im
SPD-Chip (bei bestimmten Zugriffsmustern) nicht mehr schafft.

Ist ECC-RAM im Host?
Besteht die Möglichkeit übers Wochenende einen MemTest laufen zu lassen?

Gruß,
Sven.

[Andreas Tscharner]

On 05.11.2015 20:06, Sven Lanoster wrote:

[snip]

Post by Sven Lanoster
Wenn ich wetten müsste, würde ich auf einen defekten RAM-Riegel setzen.
Vielleicht nicht defekt, sondern nur alt, so dass er das Timing im
SPD-Chip (bei bestimmten Zugriffsmustern) nicht mehr schafft.

Hmm...
Wir haben die Kiste mit 64GB bestückt, und ich glaube, wir musste neue
Riegel nehmen, dass wir soviel reingekriegt haben...
Dagegen spricht auch, dass es innerhalb des Builds immer an der gleichen
Stelle passiert, und wir haben mehr als nur einen tlibimp Aufruf...

Post by Sven Lanoster
Ist ECC-RAM im Host?
Besteht die Möglichkeit übers Wochenende einen MemTest laufen zu lassen?

Ja, ich denke, das wäre möglich. Ich kläre das mal mit dem Sysadmin ab.
Ob es ECC RAM ist, kann ich so auf die Schnelle nicht sagen.

Freundliche Grüsse
WENZEL Metromec AG
Andreas Tscharner

[Andreas Tscharner]

On 05.11.2015 16:27, Andreas Tscharner wrote:

[snip]

Post by Andreas Tscharner
Nun haben wir das Problem, dass manchmal(!) der tlibimp.exe hängen
bleibt. Leider konnten wir kein Muster erkennen; es gibt Feature
Branches, da läuft alles problemlos durch, dann gibt es welche, die
immer hängen (wenigstens immer am gleichen Ort) und dann gibt es noch
solche, die mal hängen und mal nicht.

Wir konnten das Problem weiter eingrenzen. Es liegt offenbar daran, dass
tlibimp.exe das TLB File registrieren will, und dort gibt es eine
Abhängigkeit zu einer noch nicht generierten DLL. Dies wird durch einen
Dialog angezeigt, welcher auf dem Build-Server natürlich nie angezeigt
wird und sich durch das "Hängen" bemerkbar macht.

Freundliche Grüsse
WENZEL Metromec AG
Andreas Tscharner