Evgueni Brevnov wrote:
On 1/9/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Elena Semukhina wrote:
> It was me who removed stress.Mix from the exclude lists together
with some
> more tests because all they passed for me even when running many
times on
> Windows 2003, SUSE9 linux ia32, and SUSE9 linux em64t. It was at the
end of
> November.
>
> CC started failing intermittently on stress.Mix (SUSE9, em64t) on
December,
> 18 and was excluded for that platform (HARMONY-2772).
>
> stress.Mix still passes for me now on SUSE9 linux ia32 and em64t
(both are
> 2xXeon x64 machines) while megaSpawn crashes with Segmentation fault on
> em64t and hangs on ia32 after printing a lot of messages like the
> following:
> java.lang.OutOfMemoryError: Failed to create new thread
I've just reproduced 3 different failures of MegaSpawn on windows 2003
server (P4 with HT). It may crash somewhere in calling APR because of a
NULL pointer access, it may crash on assertion that STD_MALLOC (which is
actually a define for malloc) returns non-NULL, and it hangs on shutdown.
Gregory,
It is unlikely stress.Mix hangs on shutdown stage because this test
doesn't create daemon threads which are targets of shutdown procedure.
I also observed a deadlock of stress.Mix and the problem was connected
with mixing OS & VM native locks. I guess it is something similar with
the problem when exception handler is called under OS native lock.
This could be so. The reason why I assumed that it was at shutdown stage
is because of of the threads performed DestroyJavaVM call, another
thread did some console output. So the dead lock is likely to be between
native and java locks. BTW I didn't try to analyze stress.Mix, I was
running stress.MegaSpawn from HARMONY-2803.
So it seems windows has the same problems that are present on Linux.
> Thanks,
> Elena
>
> On 1/9/07, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>>
>> On 1/8/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> > On Jan 8, 2007, at 1:20 PM, Weldon Washburn wrote:
>> >
>> > > On 1/8/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>> > >>
>> > >> On 1/7/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>> > >> >
>> > >> > >What is in the backlog?
>> > >> >
>> > >> > >I was testing on em64t dual core, and it failed there too.
>> > >>
>> > >>
>> > >> Which one failed in 64 bit mode? The basic stress.Mix or Weldon's
>> > >> MegaSpawn?
>> > >> And did it hang, or run out of memory? Running out of memory on
>> > >> these 64
>> > >> bit
>> > >> systems is not easy even under the conditions of this test.
>> > >>
>> > >> >I think we broke something basic. By just ignoring it and
>> > >> continuing
>> > >> > >with commits that are related, it seems like we're going going
>> > >> to get
>> > >> > >in deeper trouble...
>> > >>
>> > >>
>> > >> I am a little confused too. The stress.Mix test can randomly land
>> > >> up doing
>> > >> unbounded thread creation( as in Weldon's repro case )...and I
>> > >> would think
>> > >> that it is not unreasonable to fail in such a case. The RI fails
>> > >> too. But
>> > >> I
>> > >> don't understand how it never failed before.
>> > >>
>> > >>
>> > > I attempted to determine if there ever was an old svn revision
that
>> > > would
>> > > pass stress.Mix test on my rhel 2-way SMP box. Unfortunately the
>> > > unified
>> > > classlib/vm build changed the how one gets an old revision from
the
>> > > repository. I don't know if its worth trying to resurect an
old svn
>> > > revision. I am hoping someone will confirm if stress.Mix ever ran
>> > > successfully on 2-way and 4-way boxes. This seems way easier than
>> > > trying to
>> > > reconstruct old build.xml files.
>> >
>> > Huh?
>> >
>> > Why do you think you need to reconstruct anything?
>>
>>
>> Its a moot point. Naveen got the answers for us already.
>>
>> geir
>> >
>> >
>>
>>
>> --
>> Weldon Washburn
>> Intel Enterprise Solutions Software Division
>>
>>
>
>
--
Gregory
--
Gregory
