harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm][win32] Kernel tests crashes on win32
Date Wed, 22 Nov 2006 01:08:52 GMT
On Wednesday 22 November 2006 03:01 Geir Magnusson Jr. wrote:
> Gregory Shimansky wrote:
> > Hello
> >
> > After new mode was chosen for kernel tests, they crash on win32. The
> > test which crashes is the same in all 3 modes: j.l.SystemExtensionTest.
> >
> > I've found 2 types of failures. Exception is thrown with two different
> > status. It is STATUS_OBJECT_TYPE_MISMATCH (0xC0000024) or
> This is actually validation that the mode is useful. :)

I never said it is not useful. I would even suggest that kernel and smoke 
tests were run in the same VM (we have too many test modes already, let's 
consolidate them).

Unfortunately JVMTI tests cannot be run in the same VM (unless there is a 
native launcher for tests which would create/destroy VM) because JVMTI 
arguments load different native libraries with different VM options for each 
test. Even linking all JVMTI agents into one library wouldn't be enough 
because enabled JVMTI changes too much in the created VM (JIT works 
differently for example), so it is better to run JVMTI tests separately.

> I've added that test to the exclusion lists for windows.

Yes I noticed. I am actually surprised that it has helped. It appears that 
just one test causes the crash. In my investigation I was quite sure that the 
problem appears because of GC or finalization, so the crash should be 
happening in the subsequent tests on GC. Maybe this test just triggers the 
problem... I'm still working on trying to figure out.

> We can now run complete so can start monitoring for regressions (as well
> as fix the breakage for the tests that are excluded...)

The reason why I didn't want to exclude gc.LOS was that is works just fine on 
windows 2003 server, hangs only on XP (threading in kernels seems to be quite 
different in them, there is also a known difference between windows 2003 
server and windows 2003 server SP1). But excluding on such platform selection 
was not possible and still isn't. So I hoped that the test would be rather 
fixed than excluded. However I agree that a test which fails for several 
months already shouldn't stand in the way and excluding it even for all types 
of windows is the right thing.

Let's not allow any regressions again. But introducing test failures even 
without changing the tests themself should not be done unannounced and 
undiscussed. I was about to revert a JIRA patch when I saw tests crash on 
windows with new mode.

> geir
> > First and more often happening one happens in apr_thread_mutex_lock when
> > executing EnterCriticalSection(&mutex->section). The section appears to
> > be wrong, the mutex pointer is sometimes bad too. But it could happen
> > because stack is hopelessly broken when the crash happens, so local
> > variable values may be just bad in debugger.
> >
> > To work around the broken stack in debugger I tried to use tracing, but
> > it only started to show the 2nd way to crash.
> >
> > The 2nd type of crash happens in finalization of Runtime$SubProcess
> > class. The handle passed to the close0 function is bogus. The long
> > pointer is Java on 32 bit has upper 32 bits filled with some garbage, so
> > it is obvious that this is not a valid 32-bit handle. Maybe it has
> > something to do with finalization.
> >
> > Is there a way to check for valid handle in windows? Something which
> > could be put into assert, to catch the problem before the actual call to
> > the function is done...


View raw message