[kaffe] assertion failed, !INTS_DISABLED()

[Kevin D. Kissell]

I submit that whoever is maintaining that module should
seriously consider replacing the assert with an explicit test
that cannot be wished away by disabling asserts, and at
the very least change the diagnostic message to something
more meaningful.  That would certainly have saved at least
two of us a bit of wasted time and puzzlement.

            Regards,

            Kevin K.

----- Original Message ----- 
From: "Godmar Back" <gback at cs.utah.edu>
To: "Kevin D. Kissell" <kevink at mips.com>
Cc: "Greg Wooledge" <greg at wooledge.org>; <kaffe at kaffe.org>
Sent: Thursday, September 12, 2002 10:16 PM
Subject: Re: [kaffe] assertion failed, !INTS_DISABLED()


> 
> This assertion failure basically means that you've segfaulted,
> for whatever reason.
> 
> Since Kaffe implements NullPointerExceptions in hardware, a segfault
> (specifically, a SIGSEGV signal) is normally converted into a NPE.
> This, however, makes only sense when the reason for the SIGSEGV
> was that a (Java) null reference was accessed, or attempted to.
> 
> If the reason for the SIGSEGV was anything else, then kaffe crashed
> (in a way it shouldn't.)  We do not detect reliably when the former
> and when the latter case occurs: however, what we do know is that the
> former case cannot occur in sections of code in which interrupts
> are disabled.
> 
> Hence the assertion: if we get a SIGSEGV while interrupts are disabled,
> we do not turn it into a NPE, but recognize we have a real crash on
> our hands and abort for post-mortem inspection instead.
> 
> Somebody should look into one of the new-fangled reporting systems
> that, when enabled, automatically send a bug report to someone (whom?)
> with the crash data.  IE has had one for years.  Mozilla has one,
> too (which I personally don't use, because mozilla crashes so often...),
> so maybe there's some free or open source software out there(?)
> 
> - Godmar
> 
> > 
> > Oddly enough, I used to get that error on the MIPS port
> > as a result of a screwed-up stack frame definition.  In my
> > case, it didn't take long for it to turn up - it happened on
> > a large number of the regression tests.
> > 
> > In the context of x86, I think this observation just serves
> > to underscore what Godmar was saying - that this assert
> > failure seems to be easily triggered by memory (particularly
> > stack frame) corruption problems that have nothing to do
> > with the jthreads "interrupt" machinery.
> > 
> >             Kevin K.
> > 
> > _______________________________________________
> > kaffe mailing list
> > kaffe at kaffe.org
> > http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
> > 
> 
> 
> _______________________________________________
> kaffe mailing list
> kaffe at kaffe.org
> http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
>