was mir grade beim debuggen aufgefallen ist, wenn ich die JVM strace dann
bekomme ich recht regelmäßig SIGSEGV in den Threads, und wenn man das
genauer nachschaut, so sind es NullPointerExceptions, die hier abgefangen
werden.
D.h. die Sun VM prüft den Zugriff bei Feld-Zugriffen auf Objekten nicht,
sondern läßt eine Null-Pointer Exception passieren und tut diese abfangen.
War mir bisher so noch nicht bewusst, was haltet Ihr davon? Oder is meine
Analyse hier falsch?
Gruss
Bernd
Klingt logisch, finde ich. So erspart sich die JVM den Overhead, auf
null-Pointer testen zu müssen, wenn das OS das ohnehin schon macht.
Ciao,
Ingo
Ja, mein Problem damit ist, dass Segemntation Violations die nicht durch
echte null-Zugriffe hervorgerufen werden eventuell an die Anwendungen als
NullPointerException reported werden. Ich denke mir die VM handelt
Segmentation Violations innerhalb des VM Codes anders als im JIT code, aber
trotzdem ist die Gefahr hoch, dass Memory Corruption nicht erkannt wird.
Ich bin bei den C Programmen immer sehr vorsichtig gewesen so was
abzufangen.
Gruss
Bernd
> Ja, mein Problem damit ist, dass Segemntation Violations die nicht durch
> echte null-Zugriffe hervorgerufen werden eventuell an die Anwendungen als
Segmentation Violations treten doch nur auf, wenn auf ungültige
Speicherbereiche zugegriffen werden? Da im Javaprozess sowieso über
andere Mechanismen dafür gesorgt wird, dass Objektreferenzen entweder
auf gültige Objekte zeigen oder eben null sind, bleiben so weit ich mir
vorstellen kann nur Null-Referenzen als mögliche Ursache für ein SIGSEGV
übrig.
Gruß, Tor
Tor-Einar Jarnbjo wrote:
> Segmentation Violations treten doch nur auf, wenn auf ungültige
> Speicherbereiche zugegriffen werden? Da im Javaprozess sowieso über
> andere Mechanismen dafür gesorgt wird, dass Objektreferenzen entweder
> auf gültige Objekte zeigen oder eben null sind, bleiben so weit ich mir
> vorstellen kann nur Null-Referenzen als mögliche Ursache für ein SIGSEGV
> übrig.
Es sei denn, es ist ein Bug in der JVM. Ich glaube, darauf wollte Bernd
hinaus (unterstelle ich jetzt mal).
Ciao,
Ingo
Eben, kommt sehr häufig vor wenn man Bitfehler, Pufferüberläufe oder
Stack-überschreiben hat.
> Da im Javaprozess sowieso über
> andere Mechanismen dafür gesorgt wird, dass Objektreferenzen entweder
> auf gültige Objekte zeigen oder eben null sind, bleiben so weit ich mir
> vorstellen kann nur Null-Referenzen als mögliche Ursache für ein SIGSEGV
> übrig.
Oder halt JVM Fehler, libc fehler, Hardware Fehler oder JNI Code der Amok läuft.
Gruss
Bernd
> Tor-Einar Jarnbjo <ne...@jarnbjo.de> wrote:
> > ... bleiben so weit ich mir
> > vorstellen kann nur Null-Referenzen als mögliche Ursache für ein SIGSEGV
> > übrig.
>
> Oder halt JVM Fehler, libc fehler, Hardware Fehler oder JNI Code der Amok läuft.
Hotspot bemueht sich redlich, diese zu unterscheiden, je nachdem, ob
der PC in generiertem Code oder ausserhalb liegt. Soweit ich ueberhaupt
den Code verstehe.
Siehe:
hotspot/src/share/vm/runtime/sharedRuntime.cpp
hotspot/src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
Matthias
Aber selbst dann ist es möglich, festzustellen aus welchen
Code-Bereichen (also JVM oder Nutzerprogramm) die Schutzverletzung kommt.
Wir haben das bei unserem Projekt ausgenutzt, um uns den Test auf
Objektverfügbarkeit zu sparen. Da konnten wir dann feststellen, dass
der Segfault von uns kam, dann war es ein Fehler. Wenn er aus den
Anwendung kam, dann war es ein Objektzugriff.
Viele Grüße
-michael
--
> Nenne mir ein Wort und ich erkläre Dir, daß es griechischen Ursprungs
> ist
Na dann: Semmelknödel und Wolpertinger
(Anastasios Tsitlakidis und Michael Rauscher in d.c.l.j)
> Ja, mein Problem damit ist, dass Segemntation Violations die nicht durch
> echte null-Zugriffe hervorgerufen werden eventuell an die Anwendungen
> als NullPointerException reported werden.
Viel schlimmer - böse Admins die killall -SEGV java machen, auch. :P
Gruß
Daniel
Sehr spassig!! :)
Gruss
Bernd
Ah ja. Jepp, solange der Heap oder Stack nicht korrupt ist kann man es am PC
erkennen.
Gruss
Bernd
Ich wusste doch, dass Du so einer bist :P Nein, Spass.
Eigentlich hab ich selbst nicht dran geglaubt, aber ich hab's eben nochmal
getestet:
fsc@chloris fsc> java test &
[1] 10845
fsc@chloris fsc> kill -SEGV 10845
fsc@chloris fsc> Exception in thread "main" java.lang.NullPointerException
at test.main(test.java:5)
[1]+ Exit 1 java test
Hihi. Eine NPE in while(true);...
Daniel
> Segmentation Violations treten doch nur auf, wenn auf ungültige
> Speicherbereiche zugegriffen werden? Da im Javaprozess sowieso über
> andere Mechanismen dafür gesorgt wird, dass Objektreferenzen entweder
> auf gültige Objekte zeigen oder eben null sind, bleiben so weit ich mir
> vorstellen kann nur Null-Referenzen als mögliche Ursache für ein SIGSEGV
> übrig.
Und Suns JVM-Implementierug ist fehlerfrei... Träum' weiter ;-)
Gruß,
Thilo