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] stress.Mix problems -- should it prevent committing patches?
Date Tue, 09 Jan 2007 14:49:52 GMT
Evgueni Brevnov wrote:
> On 1/9/07, Gregory Shimansky <gshimansky@gmail.com> 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 <weldonwjw@gmail.com> wrote:
>> >>
>> >> On 1/8/07, Geir Magnusson Jr. <geir@pobox.com> wrote:
>> >> >
>> >> >
>> >> > On Jan 8, 2007, at 1:20 PM, Weldon Washburn wrote:
>> >> >
>> >> > > On 1/8/07, Rana Dasgupta <rdasgupt@gmail.com> wrote:
>> >> > >>
>> >> > >> On 1/7/07, Geir Magnusson Jr. <geir@pobox.com> 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


Mime
View raw message