Re: 32Bit Jail in einer 64Bit Umgebung

Michael Gusek wrote:
> Oliver Fromme wrote:
> > Michael Gusek wrote:
> > > [...] Richtig wäre java -version. Diese Aufgabe scheint für
> > > java so schwer zu sein, dass der Prozess dauerhaft auf 100% geht.
> >
> > Das kann sonstwelche Ursachen haben; das muss keineswegs
> > mit der 32bit-Umgebung zusammenhängen. Man müsste das
> > natürlich näher untersuchen; für eine Ferndiagnose sind
> > die vorhandenen Informationen zu dürftig. strace ist
> > im Falle von Java nicht unbedingt hilfreich, aber wie
> > gesagt, in solchen Fällen sind Ferndiagnosen schwierig.
> > Das muss man schon vor Ort debuggen.
>
> Wie müsste man denn Vorgehen, um Informationen zu
> bekommen, die hier hilfreich sind ?

Das kann man nicht so ohne weiteres sagen, weil jeder
Schritt vom Ergebnis des vorhergehenden abhängt.

Ein strace des hängenden Prozesses wäre zumindest schonmal
ein einfacher Versuch. Vielleicht versucht er ja irgend-
einen Syscall (z.B. Öffnen eines Devices oder einer Datei),
der schiefgeht (not found, permission denied o.ä.), aber
der Fehler wird nicht korrekt behandelt, so dass es immer
wieder versucht wird. Solche Fälle hatte ich schon. Das
sieht man dann im strace, und man kann das Problem beheben
(Verzeichnis anlegen, Permissions ändern usw.).

Im Worst-case siehst Du im strace gar nichts. Dann ist der
Prozess einfach in einer Endlosschleife, in der er keine
Syscalls macht, und strace hilft Dir nicht mehr weiter.
Evtl. kann man versuchen, herauszufinden, was er unmittel-
bar davor als letztes tut, z.B. ob er eine bestimmte Datei
öffnet, deren Inhalt vielleicht aufgrund eines Bugs das
Verhalten hervorrufen könnte.

Du könntest auch versuchen, den Debug-Level hochzusetzen.
Vielleicht bringt das etwas zu Tage, vielleicht auch nicht.

Falls Du eine Vergleichsumgebung hast (z.B. auf einem
32bit-System), die ansonsten identisch ist und unter der
das Problem nicht auftritt, könntest Du ein differentielles
Trace versuchen. D.h. in beiden Umgebungen unter gleichen
Bedingungen stracen, dann aus der Ausgabe jeweils irrele-
vante Informationen (z.B. Timestamps, Speicheradressen)
wegfiltern, und den Rest mit diff(1) vergleichen. Mögli-
cherweise findet man auf diese Weise den entscheidenden
Unterschied, der zu dem Fehlverhalten führt.

Übrigens -- fällt mir gerade ein ... Ist vielleicht eine
banale Sache, aber die einfachsten Dinge übersieht man ja
manchmal ... Hast Du daran gedacht, in dem chroot ein
DEVFS auf /dev zu mounten? Ohne das wird es nicht gehen
(und so einiges andere auch nicht). Ich könnte mir gut
vorstellen, dass Java so Dinge wie /dev/null, /dev/tty
und ein paar andere brauchen könnte ...

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
"To this day, many C programmers believe that 'strong typing'
just means pounding extra hard on the keyboard."
        -- Peter van der Linden
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message