NPE == SIGSEGV?
Bernd Eckenfels
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
Ingo R. Homann
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
Bernd Eckenfels
> 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.
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
Tor-Einar Jarnbjo
> 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
Ingo R. Homann
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
Bernd Eckenfels
> Segmentation Violations treten doch nur auf, wenn auf ungültige
> Speicherbereiche zugegriffen werden?
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
ernst.m...@gmail.com
Bernd Eckenfels schrieb:
> 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
Michael Klemm
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)
Daniel Fischer
> 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
Bernd Eckenfels
> Viel schlimmer - böse Admins die killall -SEGV java machen, auch. :P
Sehr spassig!! :)
Gruss
Bernd
Bernd Eckenfels
> Hotspot bemueht sich redlich, diese zu unterscheiden, je nachdem, ob
> der PC in generiertem Code oder ausserhalb liegt. Soweit ich ueberhaupt
> den Code verstehe.
Ah ja. Jepp, solange der Heap oder Stack nicht korrupt ist kann man es am PC
erkennen.
Gruss
Bernd
Daniel Fischer
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
Thilo-Alexander Ginkel
> 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