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
> > STATUS_INVALID_HANDLE (0xC0000008).
>
> 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...
--
Gregory
--
Gregory
|