You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Nathan Beyer <nd...@apache.org> on 2007/03/27 23:18:52 UTC
[drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
I'm getting consistent failures of the following tests on Ubuntu
7.04-dev running on Quad Xeon P3 hardware. I saw some other threads on
the mailing list about failures on a dual CPU machine, are these the
same failures.
Is there anyway to get some more information about these failures?
Stack trace? dumps?
-Nathan
Breakpoint1 failed on Client mode JIT (default)
SingleStep1 failed on Client mode JIT (default)
VMInit1 failed on Client mode JIT (default)
Breakpoint1 failed on interpreter
SingleStep1 failed on interpreter
VMInit1 failed on interpreter
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Nathan Beyer <nd...@apache.org>.
On 4/1/07, Tim Ellison <t....@gmail.com> wrote:
> Nathan Beyer wrote:
> > I'm building the classlib on the same machine and the classlib tests
> > at least execute with the IBM VM.
> >
> > Is there anything I can look for in the compile log to verify the build?
>
> Not sure what you mean by 'verify' the build, but you should be able to
> see the -march=pentium3 option in the portlib build log.
I'm just looking for some obvious markers in the build output that
might point to some environment issue I have. I have seen the
"-march=pentium3" options, but I'll verify it just to be sure.
-Nathan
>
> Regards,
> Tim
>
>
> > On 3/31/07, Tim Ellison <t....@gmail.com> wrote:
> >> Gregory Shimansky wrote:
> >> > The function code is jsig_primary_sigaction is not DRLVM specific. It
> >> > actually comes from classlib portlib. Could it be that Harmony build
> >> > that you are using was compiled with P4 specific optimizations? Looking
> >> > at the function code I don't see any assembly, so it should be gcc
> >> which
> >> > generated such code.
> >>
> >> The sig library picks up the default rules file for classlib on x86
> >> Linux, which has -march=pentium3
> >>
> >> Regards,
> >> Tim
> >>
> >>
> >
>
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon
P3
Posted by Tim Ellison <t....@gmail.com>.
Nathan Beyer wrote:
> I'm building the classlib on the same machine and the classlib tests
> at least execute with the IBM VM.
>
> Is there anything I can look for in the compile log to verify the build?
Not sure what you mean by 'verify' the build, but you should be able to
see the -march=pentium3 option in the portlib build log.
Regards,
Tim
> On 3/31/07, Tim Ellison <t....@gmail.com> wrote:
>> Gregory Shimansky wrote:
>> > The function code is jsig_primary_sigaction is not DRLVM specific. It
>> > actually comes from classlib portlib. Could it be that Harmony build
>> > that you are using was compiled with P4 specific optimizations? Looking
>> > at the function code I don't see any assembly, so it should be gcc
>> which
>> > generated such code.
>>
>> The sig library picks up the default rules file for classlib on x86
>> Linux, which has -march=pentium3
>>
>> Regards,
>> Tim
>>
>>
>
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Nathan Beyer <nd...@apache.org>.
I'm building the classlib on the same machine and the classlib tests
at least execute with the IBM VM.
Is there anything I can look for in the compile log to verify the build?
-Nathan
On 3/31/07, Tim Ellison <t....@gmail.com> wrote:
> Gregory Shimansky wrote:
> > The function code is jsig_primary_sigaction is not DRLVM specific. It
> > actually comes from classlib portlib. Could it be that Harmony build
> > that you are using was compiled with P4 specific optimizations? Looking
> > at the function code I don't see any assembly, so it should be gcc which
> > generated such code.
>
> The sig library picks up the default rules file for classlib on x86
> Linux, which has -march=pentium3
>
> Regards,
> Tim
>
>
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Rana Dasgupta <rd...@gmail.com>.
My bad. Please ignore this statement.
On 4/2/07, Rana Dasgupta <rd...@gmail.com> wrote:
> Mikhail,
> Nathan is hitting an "mfence", is this available on PIII?
>
> Rana
>
>
> On 4/2/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > On 4/1/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > >
> > > On 3/31/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > Nathan Beyer wrote:
> > > > > On 3/30/07, Nathan Beyer <nd...@apache.org> wrote:
> > > > > Okay, I'm trying that out now. Can the JIT be a little smarter and not
> > > > >use instructions that aren't available? We certainly can't limit
> > > > > available platforms to P4 or newer.
> > > >
> > > > I hope JIT gurus can answer this. I know that JIT can use x87 stack
> > > > instead of SSE for floating point, but other P4 specific instructions
> > > > may still be present in the code. I know at least one place in DRLVM
> > > > where mfence, sfence and lfence are used explicitly in inline assembly.
> > > >
> > > We have had these discussions before when discussing JIT plans etc. We
> > > did discuss that the floating point operations generated by jitrino,
> > > as contributed, uses sse2 and that porting to the x87 stack was a TBD.
> >
> >
> > With http://issues.apache.org/jira/browse/HARMONY-3246 commited JIT (
> > Jitrino.OPT only) is able to use x87 instructions. I know no other JIT
> > limitations and think that Jitrino is P3 ready (at least -Xem:opt mode)
> >
> >
> > For those who have P3 hardware: please tell us about any problems you have
> > with JIT. I just do not have such an old environment in reach.
> >
> > --
> > Mikhail Fursov
> >
>
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Rana Dasgupta <rd...@gmail.com>.
Mikhail,
Nathan is hitting an "mfence", is this available on PIII?
Rana
On 4/2/07, Mikhail Fursov <mi...@gmail.com> wrote:
> On 4/1/07, Rana Dasgupta <rd...@gmail.com> wrote:
> >
> > On 3/31/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > Nathan Beyer wrote:
> > > > On 3/30/07, Nathan Beyer <nd...@apache.org> wrote:
> > > > Okay, I'm trying that out now. Can the JIT be a little smarter and not
> > > >use instructions that aren't available? We certainly can't limit
> > > > available platforms to P4 or newer.
> > >
> > > I hope JIT gurus can answer this. I know that JIT can use x87 stack
> > > instead of SSE for floating point, but other P4 specific instructions
> > > may still be present in the code. I know at least one place in DRLVM
> > > where mfence, sfence and lfence are used explicitly in inline assembly.
> > >
> > We have had these discussions before when discussing JIT plans etc. We
> > did discuss that the floating point operations generated by jitrino,
> > as contributed, uses sse2 and that porting to the x87 stack was a TBD.
>
>
> With http://issues.apache.org/jira/browse/HARMONY-3246 commited JIT (
> Jitrino.OPT only) is able to use x87 instructions. I know no other JIT
> limitations and think that Jitrino is P3 ready (at least -Xem:opt mode)
>
>
> For those who have P3 hardware: please tell us about any problems you have
> with JIT. I just do not have such an old environment in reach.
>
> --
> Mikhail Fursov
>
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Alexey Varlamov <al...@gmail.com>.
2007/4/2, Pavel Ozhdikhin <pa...@gmail.com>:
> On 4/2/07, Mikhail Fursov <mi...@gmail.com> wrote:
> >
> > On 4/1/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > >
> > > On 3/31/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > Nathan Beyer wrote:
> > > > > On 3/30/07, Nathan Beyer <nd...@apache.org> wrote:
> > > > > Okay, I'm trying that out now. Can the JIT be a little smarter and
> > not
> > > > >use instructions that aren't available? We certainly can't limit
> > > > > available platforms to P4 or newer.
> > > >
> > > > I hope JIT gurus can answer this. I know that JIT can use x87 stack
> > > > instead of SSE for floating point, but other P4 specific instructions
> > > > may still be present in the code. I know at least one place in DRLVM
> > > > where mfence, sfence and lfence are used explicitly in inline
> > assembly.
> > > >
> > > We have had these discussions before when discussing JIT plans etc. We
> > > did discuss that the floating point operations generated by jitrino,
> > > as contributed, uses sse2 and that porting to the x87 stack was a TBD.
> >
> >
> > With http://issues.apache.org/jira/browse/HARMONY-3246 commited JIT (
> > Jitrino.OPT only) is able to use x87 instructions. I know no other JIT
> > limitations and think that Jitrino is P3 ready (at least -Xem:opt mode)
>
>
> A small clarification - the patch is not committed so you should apply it
> manually before checking.
Well, some further clarification might be needed: there is no runtime
detection of CPU model (yet?), one needs to supply '-Xem:p5'
command-line argument to DRLVM to switch to corresponding JIT
configuration.
>
> Thanks,
> Pavel
>
>
> For those who have P3 hardware: please tell us about any problems you have
> > with JIT. I just do not have such an old environment in reach.
> >
> > --
> > Mikhail Fursov
> >
>
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
On 4/2/07, Mikhail Fursov <mi...@gmail.com> wrote:
>
> On 4/1/07, Rana Dasgupta <rd...@gmail.com> wrote:
> >
> > On 3/31/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > Nathan Beyer wrote:
> > > > On 3/30/07, Nathan Beyer <nd...@apache.org> wrote:
> > > > Okay, I'm trying that out now. Can the JIT be a little smarter and
> not
> > > >use instructions that aren't available? We certainly can't limit
> > > > available platforms to P4 or newer.
> > >
> > > I hope JIT gurus can answer this. I know that JIT can use x87 stack
> > > instead of SSE for floating point, but other P4 specific instructions
> > > may still be present in the code. I know at least one place in DRLVM
> > > where mfence, sfence and lfence are used explicitly in inline
> assembly.
> > >
> > We have had these discussions before when discussing JIT plans etc. We
> > did discuss that the floating point operations generated by jitrino,
> > as contributed, uses sse2 and that porting to the x87 stack was a TBD.
>
>
> With http://issues.apache.org/jira/browse/HARMONY-3246 commited JIT (
> Jitrino.OPT only) is able to use x87 instructions. I know no other JIT
> limitations and think that Jitrino is P3 ready (at least -Xem:opt mode)
A small clarification - the patch is not committed so you should apply it
manually before checking.
Thanks,
Pavel
For those who have P3 hardware: please tell us about any problems you have
> with JIT. I just do not have such an old environment in reach.
>
> --
> Mikhail Fursov
>
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Mikhail Fursov <mi...@gmail.com>.
On 4/1/07, Rana Dasgupta <rd...@gmail.com> wrote:
>
> On 3/31/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > Nathan Beyer wrote:
> > > On 3/30/07, Nathan Beyer <nd...@apache.org> wrote:
> > > Okay, I'm trying that out now. Can the JIT be a little smarter and not
> > >use instructions that aren't available? We certainly can't limit
> > > available platforms to P4 or newer.
> >
> > I hope JIT gurus can answer this. I know that JIT can use x87 stack
> > instead of SSE for floating point, but other P4 specific instructions
> > may still be present in the code. I know at least one place in DRLVM
> > where mfence, sfence and lfence are used explicitly in inline assembly.
> >
> We have had these discussions before when discussing JIT plans etc. We
> did discuss that the floating point operations generated by jitrino,
> as contributed, uses sse2 and that porting to the x87 stack was a TBD.
With http://issues.apache.org/jira/browse/HARMONY-3246 commited JIT (
Jitrino.OPT only) is able to use x87 instructions. I know no other JIT
limitations and think that Jitrino is P3 ready (at least -Xem:opt mode)
For those who have P3 hardware: please tell us about any problems you have
with JIT. I just do not have such an old environment in reach.
--
Mikhail Fursov
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Nathan Beyer <nd...@apache.org>.
On 3/31/07, Rana Dasgupta <rd...@gmail.com> wrote:
> On 3/31/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > Nathan Beyer wrote:
> > > On 3/30/07, Nathan Beyer <nd...@apache.org> wrote:
> > > Okay, I'm trying that out now. Can the JIT be a little smarter and not
> > >use instructions that aren't available? We certainly can't limit
> > > available platforms to P4 or newer.
> >
> > I hope JIT gurus can answer this. I know that JIT can use x87 stack
> > instead of SSE for floating point, but other P4 specific instructions
> > may still be present in the code. I know at least one place in DRLVM
> > where mfence, sfence and lfence are used explicitly in inline assembly.
> >
> We have had these discussions before when discussing JIT plans etc. We
> did discuss that the floating point operations generated by jitrino,
> as contributed, uses sse2 and that porting to the x87 stack was a TBD.
>
> We also stated in these discussions that the "minimum machine model"
> was a P4, which implies that it was an assumption that P4 instructions
> were available and P4 specific optimization patterns could be used. I
> am sure that these discussions are there in the archives.
>
> Nathan, would it be at all possible for you to move to a P4 machine? I
> am not aware of any JIT plan to be P3 compatible, maybe Pavel or
> Mikhail Fursov can comment.
No, I can't just move to a P4 machine. I think a more appropriate
question would be "can our intended consumers just upgrade?"
I realize there's probably more "interest" in 64-bit platforms, since
they're a bit newer and sexier, but honestly I think Harmony will have
many more consumers on older devices.
-Nathan
>
> Thanks,
> Rana
>
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Rana Dasgupta <rd...@gmail.com>.
On 3/31/07, Gregory Shimansky <gs...@gmail.com> wrote:
> Nathan Beyer wrote:
> > On 3/30/07, Nathan Beyer <nd...@apache.org> wrote:
> > Okay, I'm trying that out now. Can the JIT be a little smarter and not
> >use instructions that aren't available? We certainly can't limit
> > available platforms to P4 or newer.
>
> I hope JIT gurus can answer this. I know that JIT can use x87 stack
> instead of SSE for floating point, but other P4 specific instructions
> may still be present in the code. I know at least one place in DRLVM
> where mfence, sfence and lfence are used explicitly in inline assembly.
>
We have had these discussions before when discussing JIT plans etc. We
did discuss that the floating point operations generated by jitrino,
as contributed, uses sse2 and that porting to the x87 stack was a TBD.
We also stated in these discussions that the "minimum machine model"
was a P4, which implies that it was an assumption that P4 instructions
were available and P4 specific optimization patterns could be used. I
am sure that these discussions are there in the archives.
Nathan, would it be at all possible for you to move to a P4 machine? I
am not aware of any JIT plan to be P3 compatible, maybe Pavel or
Mikhail Fursov can comment.
Thanks,
Rana
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon
P3
Posted by Tim Ellison <t....@gmail.com>.
Gregory Shimansky wrote:
> The function code is jsig_primary_sigaction is not DRLVM specific. It
> actually comes from classlib portlib. Could it be that Harmony build
> that you are using was compiled with P4 specific optimizations? Looking
> at the function code I don't see any assembly, so it should be gcc which
> generated such code.
The sig library picks up the default rules file for classlib on x86
Linux, which has -march=pentium3
Regards,
Tim
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon
P3
Posted by Gregory Shimansky <gs...@gmail.com>.
Nathan Beyer wrote:
> I ran the smoke tests and they failed horribly. From what I can tell,
> every test failed.
>
> I ran the GDB examines after running my HelloWorld class, here's the
> output.
>
> (gdb) x/1i $eip
> 0xb7b4f2ab: mfence
> (gdb) x/1i $eip+1
> 0xb7b4f2ac: scas %es:(%edi),%al
> (gdb)
Ok so this is mfence which is not SSE2 instruction, but is definitely P4
specific [1].
> I ran it a second time while still in GDB a little more information was
> shown.
The function code is jsig_primary_sigaction is not DRLVM specific. It
actually comes from classlib portlib. Could it be that Harmony build
that you are using was compiled with P4 specific optimizations? Looking
at the function code I don't see any assembly, so it should be gcc which
generated such code.
> Program received signal SIGILL, Illegal instruction.
> Cannot remove breakpoints because program is no longer writable.
> It might be running in another process.
> Further execution is probably impossible.
> 0xb7bca2ab in jsig_primary_sigaction (sig=142459008, act=0x1,
> oact=0xbfe67f28) at hysigunix.c:303
> 303 if (primaryPreviouslyInstalled &&
> (gdb) x/1i $eip
> 0xb7bca2ab <jsig_primary_sigaction+413>: mfence
> (gdb) x/1i $eip+1
> 0xb7bca2ac <jsig_primary_sigaction+414>: scas %es:(%edi),%al
> (gdb)
>
> -Nathan
>
> On 3/30/07, Nathan Beyer <nd...@apache.org> wrote:
>> Okay, I'm trying that out now. Can the JIT be a little smarter and not
>> use instructions that aren't available? We certainly can't limit
>> available platforms to P4 or newer.
I hope JIT gurus can answer this. I know that JIT can use x87 stack
instead of SSE for floating point, but other P4 specific instructions
may still be present in the code. I know at least one place in DRLVM
where mfence, sfence and lfence are used explicitly in inline assembly.
[1] http://en.wikipedia.org/wiki/X86_instruction_listings
>> -Nathan
>>
>> On 3/30/07, Gregory Shimansky <gs...@gmail.com> wrote:
>> > Ok I think I know what's going on. DRLVM JIT generates SSE2
>> instructions,
>> > and according to the subject, you are using P3. SSE2 is not
>> available on P3
>> > and will generate SIGILL on it. So it is most likely not related to
>> JVMTI
>> > implementation. To prove this you can try to run "build.sh
>> smoke.test" which
>> > should execute pure Java without any JVMTI.
>> >
>> > If you could please do
>> >
>> > x/1i $eip $eip+1
>> >
>> > in gdb to disassemble the failing address to see what instruction
>> caused
>> > SIGILL.
>> >
>> > 2007/3/30, Nathan Beyer <nd...@apache.org>:
>> > >
>> > > I might have to take that back. I tried running a simple class and it
>> > > bombed out with "Illegal instruction". Here's what I got from GDB
>> run,
>> > > below. Note, I'm still pretty green when it comes to Linux
>> development
>> > > tools, so I may sound like an idiot right now.
>> > >
>> > > nathan@pants
>> > > :~/harmony/drlvm-trunk/build/lnx_ia32_gcc_debug/deploy/jdk/jre/bin$
>> > > gdb --args ./java -cp ~/workspace/helloworld/bin/ HelloWorld
>> > > GNU gdb 6.6-debian
>> > > Copyright (C) 2006 Free Software Foundation, Inc.
>> > > GDB is free software, covered by the GNU General Public License,
>> and you
>> > > are
>> > > welcome to change it and/or distribute copies of it under certain
>> > > conditions.
>> > > Type "show copying" to see the conditions.
>> > > There is absolutely no warranty for GDB. Type "show warranty" for
>> > > details.
>> > > This GDB was configured as "i486-linux-gnu"...
>> > > Using host libthread_db library
>> "/lib/tls/i686/cmov/libthread_db.so.1".
>> > > (gdb) run
>> > > Starting program:
>> > >
>> > >
>> /home/nathan/harmony/drlvm-trunk/build/lnx_ia32_gcc_debug/deploy/jdk/jre/bin/java
>>
>> > > -cp /home/nathan/workspace/helloworld/bin/ HelloWorld
>> > > [Thread debugging using libthread_db enabled]
>> > > [New Thread -1214162256 (LWP 13833)]
>> > > [New Thread -1215321200 (LWP 13836)]
>> > > [New process 13833]
>> > > [New LWP 13833]
>> > >
>> > > Program received signal SIGILL, Illegal instruction.
>> > > Cannot remove breakpoints because program is no longer writable.
>> > > It might be running in another process.
>> > > Further execution is probably impossible.
>> > > 0xb7b0c2ab in ?? () from /lib/tls/i686/cmov/libc.so.6
>> > > (gdb)
>> > >
>> > >
>> > > On 3/29/07, Nathan Beyer <nd...@apache.org> wrote:
>> > > > I am not seeing that. Can you run the "./java -version"
>> successfully?
>> > > >
>> > > > I tried running "gdb ./java" and it loaded me into GDB just fine.
>> > > >
>> > > > -Nathan
>> > > >
>> > > > On 3/29/07, Rana Dasgupta <rd...@gmail.com> wrote:
>> > > > > The jvmti tests are among the first to run. Is it a problem
>> with jvmti
>> > > > > failures or is drlvm currently broken on linux? I seem to get a
>> > > segmentation
>> > > > > violation running just the drlvm java executable on both 32
>> and 64 bit
>> > > RHEL
>> > > > > Linux.
>> > > > >
>> > > > > gdb java
>> > > > >
>> > > > > I think shows an invalid pointer in hymem_free_memory()
>> > > > >
>> > > > > Is anyone else seeing this?
>> > > > >
>> > > > >
>> > > > >
>> > > > > On 3/29/07, Nathan Beyer <ndbeyer@apache.org > wrote:
>> > > > > >
>> > > > > > On 3/29/07, Gregory Shimansky < gshimansky@gmail.com> wrote:
>> > > > > > > Nathan Beyer wrote:
>> > > > > > > > On 3/28/07, Gregory Shimansky <gs...@gmail.com> wrote:
>> > > > > > > >> Nathan Beyer wrote:
>> > > > > > > >> > I'm getting consistent failures of the following
>> tests on
>> > > Ubuntu
>> > > > > > > >> > 7.04-dev running on Quad Xeon P3 hardware. I saw some
>> other
>> > > threads
>> > > > > > on
>> > > > > > > >> > the mailing list about failures on a dual CPU
>> machine, are
>> > > these
>> > > > > > the
>> > > > > > > >> > same failures.
>> > > > > > > >> >
>> > > > > > > >> > Is there anyway to get some more information about these
>> > > failures?
>> > > > > > > >> > Stack trace? dumps?
>> > > > > > > >> >
>> > > > > > > >> > -Nathan
>> > > > > > > >> >
>> > > > > > > >> > Breakpoint1 failed on Client mode JIT (default)
>> > > > > > > >> > SingleStep1 failed on Client mode JIT (default)
>> > > > > > > >> > VMInit1 failed on Client mode JIT (default)
>> > > > > > > >> > Breakpoint1 failed on interpreter
>> > > > > > > >> > SingleStep1 failed on interpreter
>> > > > > > > >> > VMInit1 failed on interpreter
>> > > > > > > >>
>> > > > > > > >> The tests produce a report in
>> > > > > > > >> lnx_ia32_gcc_debug/semis/jvmti.tests/reports which you
>> can try
>> > > to
>> > > > > > > >> analyze. There should be the output why the tests
>> failed. The
>> > > tests
>> > > > > > > >> you've mentioned are single threaded and shouldn't
>> depend on
>> > > the
>> > > > > > number
>> > > > > > > >> of CPUs.
>> > > > > > > >
>> > > > > > > > I'm seeing three folders under
>> > > > > > > > "build/lnx_ia32_gcc_debug/semis/jvmti.tests/reports/"
>> and "int",
>> > > "jit"
>> > > > > > > > and "opt" folder. All of them are empty.
>> > > > > > >
>> > > > > > > Try this command line to run the test in command line.
>> Tests have
>> > > to be
>> > > > > > > compiled before running it
>> > > > > > >
>> > > > > > > ./lnx_ia32_gcc_debug/deploy/jdk/jre/bin/java -cp
>> > > > > > >
>> make/tmp/junit.jar:./lnx_ia32_gcc_debug/semis/jvmti.tests/classes
>> > > > > > >
>> > > > > >
>> > >
>> -agentpath:./lnx_ia32_gcc_debug/semis/jvmti.tests/native/Breakpoint1/libBreakpoint1.so
>>
>> > > > > > > junit.textui.TestRunner Breakpoint1.Breakpoint1
>> > > > > > >
>> > > > > > > --
>> > > > > > > Gregory
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > > > I tried that and this is what is output to the console (the
>> report
>> > > > > > folders are still empty).
>> > > > > >
>> > > > > > DEBUG: Getting JVMTI enviroment...
>> > > > > > DEBUG: done!
>> > > > > > DEBUG: Setting capabilities...
>> > > > > > DEBUG: done!
>> > > > > > DEBUG: Setting events...
>> > > > > > DEBUG: done!
>> > > > > > Illegal instruction
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Gregory
>> >
>>
>
--
Gregory
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Nathan Beyer <nd...@apache.org>.
I ran the smoke tests and they failed horribly. From what I can tell,
every test failed.
I ran the GDB examines after running my HelloWorld class, here's the output.
(gdb) x/1i $eip
0xb7b4f2ab: mfence
(gdb) x/1i $eip+1
0xb7b4f2ac: scas %es:(%edi),%al
(gdb)
I ran it a second time while still in GDB a little more information was shown.
Program received signal SIGILL, Illegal instruction.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0xb7bca2ab in jsig_primary_sigaction (sig=142459008, act=0x1,
oact=0xbfe67f28) at hysigunix.c:303
303 if (primaryPreviouslyInstalled &&
(gdb) x/1i $eip
0xb7bca2ab <jsig_primary_sigaction+413>: mfence
(gdb) x/1i $eip+1
0xb7bca2ac <jsig_primary_sigaction+414>: scas %es:(%edi),%al
(gdb)
-Nathan
On 3/30/07, Nathan Beyer <nd...@apache.org> wrote:
> Okay, I'm trying that out now. Can the JIT be a little smarter and not
> use instructions that aren't available? We certainly can't limit
> available platforms to P4 or newer.
>
> -Nathan
>
> On 3/30/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > Ok I think I know what's going on. DRLVM JIT generates SSE2 instructions,
> > and according to the subject, you are using P3. SSE2 is not available on P3
> > and will generate SIGILL on it. So it is most likely not related to JVMTI
> > implementation. To prove this you can try to run "build.sh smoke.test" which
> > should execute pure Java without any JVMTI.
> >
> > If you could please do
> >
> > x/1i $eip $eip+1
> >
> > in gdb to disassemble the failing address to see what instruction caused
> > SIGILL.
> >
> > 2007/3/30, Nathan Beyer <nd...@apache.org>:
> > >
> > > I might have to take that back. I tried running a simple class and it
> > > bombed out with "Illegal instruction". Here's what I got from GDB run,
> > > below. Note, I'm still pretty green when it comes to Linux development
> > > tools, so I may sound like an idiot right now.
> > >
> > > nathan@pants
> > > :~/harmony/drlvm-trunk/build/lnx_ia32_gcc_debug/deploy/jdk/jre/bin$
> > > gdb --args ./java -cp ~/workspace/helloworld/bin/ HelloWorld
> > > GNU gdb 6.6-debian
> > > Copyright (C) 2006 Free Software Foundation, Inc.
> > > GDB is free software, covered by the GNU General Public License, and you
> > > are
> > > welcome to change it and/or distribute copies of it under certain
> > > conditions.
> > > Type "show copying" to see the conditions.
> > > There is absolutely no warranty for GDB. Type "show warranty" for
> > > details.
> > > This GDB was configured as "i486-linux-gnu"...
> > > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
> > > (gdb) run
> > > Starting program:
> > >
> > > /home/nathan/harmony/drlvm-trunk/build/lnx_ia32_gcc_debug/deploy/jdk/jre/bin/java
> > > -cp /home/nathan/workspace/helloworld/bin/ HelloWorld
> > > [Thread debugging using libthread_db enabled]
> > > [New Thread -1214162256 (LWP 13833)]
> > > [New Thread -1215321200 (LWP 13836)]
> > > [New process 13833]
> > > [New LWP 13833]
> > >
> > > Program received signal SIGILL, Illegal instruction.
> > > Cannot remove breakpoints because program is no longer writable.
> > > It might be running in another process.
> > > Further execution is probably impossible.
> > > 0xb7b0c2ab in ?? () from /lib/tls/i686/cmov/libc.so.6
> > > (gdb)
> > >
> > >
> > > On 3/29/07, Nathan Beyer <nd...@apache.org> wrote:
> > > > I am not seeing that. Can you run the "./java -version" successfully?
> > > >
> > > > I tried running "gdb ./java" and it loaded me into GDB just fine.
> > > >
> > > > -Nathan
> > > >
> > > > On 3/29/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > The jvmti tests are among the first to run. Is it a problem with jvmti
> > > > > failures or is drlvm currently broken on linux? I seem to get a
> > > segmentation
> > > > > violation running just the drlvm java executable on both 32 and 64 bit
> > > RHEL
> > > > > Linux.
> > > > >
> > > > > gdb java
> > > > >
> > > > > I think shows an invalid pointer in hymem_free_memory()
> > > > >
> > > > > Is anyone else seeing this?
> > > > >
> > > > >
> > > > >
> > > > > On 3/29/07, Nathan Beyer <ndbeyer@apache.org > wrote:
> > > > > >
> > > > > > On 3/29/07, Gregory Shimansky < gshimansky@gmail.com> wrote:
> > > > > > > Nathan Beyer wrote:
> > > > > > > > On 3/28/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > > > > >> Nathan Beyer wrote:
> > > > > > > >> > I'm getting consistent failures of the following tests on
> > > Ubuntu
> > > > > > > >> > 7.04-dev running on Quad Xeon P3 hardware. I saw some other
> > > threads
> > > > > > on
> > > > > > > >> > the mailing list about failures on a dual CPU machine, are
> > > these
> > > > > > the
> > > > > > > >> > same failures.
> > > > > > > >> >
> > > > > > > >> > Is there anyway to get some more information about these
> > > failures?
> > > > > > > >> > Stack trace? dumps?
> > > > > > > >> >
> > > > > > > >> > -Nathan
> > > > > > > >> >
> > > > > > > >> > Breakpoint1 failed on Client mode JIT (default)
> > > > > > > >> > SingleStep1 failed on Client mode JIT (default)
> > > > > > > >> > VMInit1 failed on Client mode JIT (default)
> > > > > > > >> > Breakpoint1 failed on interpreter
> > > > > > > >> > SingleStep1 failed on interpreter
> > > > > > > >> > VMInit1 failed on interpreter
> > > > > > > >>
> > > > > > > >> The tests produce a report in
> > > > > > > >> lnx_ia32_gcc_debug/semis/jvmti.tests/reports which you can try
> > > to
> > > > > > > >> analyze. There should be the output why the tests failed. The
> > > tests
> > > > > > > >> you've mentioned are single threaded and shouldn't depend on
> > > the
> > > > > > number
> > > > > > > >> of CPUs.
> > > > > > > >
> > > > > > > > I'm seeing three folders under
> > > > > > > > "build/lnx_ia32_gcc_debug/semis/jvmti.tests/reports/" and "int",
> > > "jit"
> > > > > > > > and "opt" folder. All of them are empty.
> > > > > > >
> > > > > > > Try this command line to run the test in command line. Tests have
> > > to be
> > > > > > > compiled before running it
> > > > > > >
> > > > > > > ./lnx_ia32_gcc_debug/deploy/jdk/jre/bin/java -cp
> > > > > > > make/tmp/junit.jar:./lnx_ia32_gcc_debug/semis/jvmti.tests/classes
> > > > > > >
> > > > > >
> > > -agentpath:./lnx_ia32_gcc_debug/semis/jvmti.tests/native/Breakpoint1/libBreakpoint1.so
> > > > > > > junit.textui.TestRunner Breakpoint1.Breakpoint1
> > > > > > >
> > > > > > > --
> > > > > > > Gregory
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > I tried that and this is what is output to the console (the report
> > > > > > folders are still empty).
> > > > > >
> > > > > > DEBUG: Getting JVMTI enviroment...
> > > > > > DEBUG: done!
> > > > > > DEBUG: Setting capabilities...
> > > > > > DEBUG: done!
> > > > > > DEBUG: Setting events...
> > > > > > DEBUG: done!
> > > > > > Illegal instruction
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Gregory
> >
>
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Nathan Beyer <nd...@apache.org>.
Okay, I'm trying that out now. Can the JIT be a little smarter and not
use instructions that aren't available? We certainly can't limit
available platforms to P4 or newer.
-Nathan
On 3/30/07, Gregory Shimansky <gs...@gmail.com> wrote:
> Ok I think I know what's going on. DRLVM JIT generates SSE2 instructions,
> and according to the subject, you are using P3. SSE2 is not available on P3
> and will generate SIGILL on it. So it is most likely not related to JVMTI
> implementation. To prove this you can try to run "build.sh smoke.test" which
> should execute pure Java without any JVMTI.
>
> If you could please do
>
> x/1i $eip $eip+1
>
> in gdb to disassemble the failing address to see what instruction caused
> SIGILL.
>
> 2007/3/30, Nathan Beyer <nd...@apache.org>:
> >
> > I might have to take that back. I tried running a simple class and it
> > bombed out with "Illegal instruction". Here's what I got from GDB run,
> > below. Note, I'm still pretty green when it comes to Linux development
> > tools, so I may sound like an idiot right now.
> >
> > nathan@pants
> > :~/harmony/drlvm-trunk/build/lnx_ia32_gcc_debug/deploy/jdk/jre/bin$
> > gdb --args ./java -cp ~/workspace/helloworld/bin/ HelloWorld
> > GNU gdb 6.6-debian
> > Copyright (C) 2006 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you
> > are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB. Type "show warranty" for
> > details.
> > This GDB was configured as "i486-linux-gnu"...
> > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
> > (gdb) run
> > Starting program:
> >
> > /home/nathan/harmony/drlvm-trunk/build/lnx_ia32_gcc_debug/deploy/jdk/jre/bin/java
> > -cp /home/nathan/workspace/helloworld/bin/ HelloWorld
> > [Thread debugging using libthread_db enabled]
> > [New Thread -1214162256 (LWP 13833)]
> > [New Thread -1215321200 (LWP 13836)]
> > [New process 13833]
> > [New LWP 13833]
> >
> > Program received signal SIGILL, Illegal instruction.
> > Cannot remove breakpoints because program is no longer writable.
> > It might be running in another process.
> > Further execution is probably impossible.
> > 0xb7b0c2ab in ?? () from /lib/tls/i686/cmov/libc.so.6
> > (gdb)
> >
> >
> > On 3/29/07, Nathan Beyer <nd...@apache.org> wrote:
> > > I am not seeing that. Can you run the "./java -version" successfully?
> > >
> > > I tried running "gdb ./java" and it loaded me into GDB just fine.
> > >
> > > -Nathan
> > >
> > > On 3/29/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > The jvmti tests are among the first to run. Is it a problem with jvmti
> > > > failures or is drlvm currently broken on linux? I seem to get a
> > segmentation
> > > > violation running just the drlvm java executable on both 32 and 64 bit
> > RHEL
> > > > Linux.
> > > >
> > > > gdb java
> > > >
> > > > I think shows an invalid pointer in hymem_free_memory()
> > > >
> > > > Is anyone else seeing this?
> > > >
> > > >
> > > >
> > > > On 3/29/07, Nathan Beyer <ndbeyer@apache.org > wrote:
> > > > >
> > > > > On 3/29/07, Gregory Shimansky < gshimansky@gmail.com> wrote:
> > > > > > Nathan Beyer wrote:
> > > > > > > On 3/28/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > > > >> Nathan Beyer wrote:
> > > > > > >> > I'm getting consistent failures of the following tests on
> > Ubuntu
> > > > > > >> > 7.04-dev running on Quad Xeon P3 hardware. I saw some other
> > threads
> > > > > on
> > > > > > >> > the mailing list about failures on a dual CPU machine, are
> > these
> > > > > the
> > > > > > >> > same failures.
> > > > > > >> >
> > > > > > >> > Is there anyway to get some more information about these
> > failures?
> > > > > > >> > Stack trace? dumps?
> > > > > > >> >
> > > > > > >> > -Nathan
> > > > > > >> >
> > > > > > >> > Breakpoint1 failed on Client mode JIT (default)
> > > > > > >> > SingleStep1 failed on Client mode JIT (default)
> > > > > > >> > VMInit1 failed on Client mode JIT (default)
> > > > > > >> > Breakpoint1 failed on interpreter
> > > > > > >> > SingleStep1 failed on interpreter
> > > > > > >> > VMInit1 failed on interpreter
> > > > > > >>
> > > > > > >> The tests produce a report in
> > > > > > >> lnx_ia32_gcc_debug/semis/jvmti.tests/reports which you can try
> > to
> > > > > > >> analyze. There should be the output why the tests failed. The
> > tests
> > > > > > >> you've mentioned are single threaded and shouldn't depend on
> > the
> > > > > number
> > > > > > >> of CPUs.
> > > > > > >
> > > > > > > I'm seeing three folders under
> > > > > > > "build/lnx_ia32_gcc_debug/semis/jvmti.tests/reports/" and "int",
> > "jit"
> > > > > > > and "opt" folder. All of them are empty.
> > > > > >
> > > > > > Try this command line to run the test in command line. Tests have
> > to be
> > > > > > compiled before running it
> > > > > >
> > > > > > ./lnx_ia32_gcc_debug/deploy/jdk/jre/bin/java -cp
> > > > > > make/tmp/junit.jar:./lnx_ia32_gcc_debug/semis/jvmti.tests/classes
> > > > > >
> > > > >
> > -agentpath:./lnx_ia32_gcc_debug/semis/jvmti.tests/native/Breakpoint1/libBreakpoint1.so
> > > > > > junit.textui.TestRunner Breakpoint1.Breakpoint1
> > > > > >
> > > > > > --
> > > > > > Gregory
> > > > > >
> > > > > >
> > > > >
> > > > > I tried that and this is what is output to the console (the report
> > > > > folders are still empty).
> > > > >
> > > > > DEBUG: Getting JVMTI enviroment...
> > > > > DEBUG: done!
> > > > > DEBUG: Setting capabilities...
> > > > > DEBUG: done!
> > > > > DEBUG: Setting events...
> > > > > DEBUG: done!
> > > > > Illegal instruction
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Gregory
>
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Gregory Shimansky <gs...@gmail.com>.
Ok I think I know what's going on. DRLVM JIT generates SSE2 instructions,
and according to the subject, you are using P3. SSE2 is not available on P3
and will generate SIGILL on it. So it is most likely not related to JVMTI
implementation. To prove this you can try to run "build.sh smoke.test" which
should execute pure Java without any JVMTI.
If you could please do
x/1i $eip $eip+1
in gdb to disassemble the failing address to see what instruction caused
SIGILL.
2007/3/30, Nathan Beyer <nd...@apache.org>:
>
> I might have to take that back. I tried running a simple class and it
> bombed out with "Illegal instruction". Here's what I got from GDB run,
> below. Note, I'm still pretty green when it comes to Linux development
> tools, so I may sound like an idiot right now.
>
> nathan@pants
> :~/harmony/drlvm-trunk/build/lnx_ia32_gcc_debug/deploy/jdk/jre/bin$
> gdb --args ./java -cp ~/workspace/helloworld/bin/ HelloWorld
> GNU gdb 6.6-debian
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> This GDB was configured as "i486-linux-gnu"...
> Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
> (gdb) run
> Starting program:
>
> /home/nathan/harmony/drlvm-trunk/build/lnx_ia32_gcc_debug/deploy/jdk/jre/bin/java
> -cp /home/nathan/workspace/helloworld/bin/ HelloWorld
> [Thread debugging using libthread_db enabled]
> [New Thread -1214162256 (LWP 13833)]
> [New Thread -1215321200 (LWP 13836)]
> [New process 13833]
> [New LWP 13833]
>
> Program received signal SIGILL, Illegal instruction.
> Cannot remove breakpoints because program is no longer writable.
> It might be running in another process.
> Further execution is probably impossible.
> 0xb7b0c2ab in ?? () from /lib/tls/i686/cmov/libc.so.6
> (gdb)
>
>
> On 3/29/07, Nathan Beyer <nd...@apache.org> wrote:
> > I am not seeing that. Can you run the "./java -version" successfully?
> >
> > I tried running "gdb ./java" and it loaded me into GDB just fine.
> >
> > -Nathan
> >
> > On 3/29/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > The jvmti tests are among the first to run. Is it a problem with jvmti
> > > failures or is drlvm currently broken on linux? I seem to get a
> segmentation
> > > violation running just the drlvm java executable on both 32 and 64 bit
> RHEL
> > > Linux.
> > >
> > > gdb java
> > >
> > > I think shows an invalid pointer in hymem_free_memory()
> > >
> > > Is anyone else seeing this?
> > >
> > >
> > >
> > > On 3/29/07, Nathan Beyer <ndbeyer@apache.org > wrote:
> > > >
> > > > On 3/29/07, Gregory Shimansky < gshimansky@gmail.com> wrote:
> > > > > Nathan Beyer wrote:
> > > > > > On 3/28/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > > >> Nathan Beyer wrote:
> > > > > >> > I'm getting consistent failures of the following tests on
> Ubuntu
> > > > > >> > 7.04-dev running on Quad Xeon P3 hardware. I saw some other
> threads
> > > > on
> > > > > >> > the mailing list about failures on a dual CPU machine, are
> these
> > > > the
> > > > > >> > same failures.
> > > > > >> >
> > > > > >> > Is there anyway to get some more information about these
> failures?
> > > > > >> > Stack trace? dumps?
> > > > > >> >
> > > > > >> > -Nathan
> > > > > >> >
> > > > > >> > Breakpoint1 failed on Client mode JIT (default)
> > > > > >> > SingleStep1 failed on Client mode JIT (default)
> > > > > >> > VMInit1 failed on Client mode JIT (default)
> > > > > >> > Breakpoint1 failed on interpreter
> > > > > >> > SingleStep1 failed on interpreter
> > > > > >> > VMInit1 failed on interpreter
> > > > > >>
> > > > > >> The tests produce a report in
> > > > > >> lnx_ia32_gcc_debug/semis/jvmti.tests/reports which you can try
> to
> > > > > >> analyze. There should be the output why the tests failed. The
> tests
> > > > > >> you've mentioned are single threaded and shouldn't depend on
> the
> > > > number
> > > > > >> of CPUs.
> > > > > >
> > > > > > I'm seeing three folders under
> > > > > > "build/lnx_ia32_gcc_debug/semis/jvmti.tests/reports/" and "int",
> "jit"
> > > > > > and "opt" folder. All of them are empty.
> > > > >
> > > > > Try this command line to run the test in command line. Tests have
> to be
> > > > > compiled before running it
> > > > >
> > > > > ./lnx_ia32_gcc_debug/deploy/jdk/jre/bin/java -cp
> > > > > make/tmp/junit.jar:./lnx_ia32_gcc_debug/semis/jvmti.tests/classes
> > > > >
> > > >
> -agentpath:./lnx_ia32_gcc_debug/semis/jvmti.tests/native/Breakpoint1/libBreakpoint1.so
> > > > > junit.textui.TestRunner Breakpoint1.Breakpoint1
> > > > >
> > > > > --
> > > > > Gregory
> > > > >
> > > > >
> > > >
> > > > I tried that and this is what is output to the console (the report
> > > > folders are still empty).
> > > >
> > > > DEBUG: Getting JVMTI enviroment...
> > > > DEBUG: done!
> > > > DEBUG: Setting capabilities...
> > > > DEBUG: done!
> > > > DEBUG: Setting events...
> > > > DEBUG: done!
> > > > Illegal instruction
> > > >
> > >
> >
>
--
Gregory
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Nathan Beyer <nd...@apache.org>.
I might have to take that back. I tried running a simple class and it
bombed out with "Illegal instruction". Here's what I got from GDB run,
below. Note, I'm still pretty green when it comes to Linux development
tools, so I may sound like an idiot right now.
nathan@pants:~/harmony/drlvm-trunk/build/lnx_ia32_gcc_debug/deploy/jdk/jre/bin$
gdb --args ./java -cp ~/workspace/helloworld/bin/ HelloWorld
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run
Starting program:
/home/nathan/harmony/drlvm-trunk/build/lnx_ia32_gcc_debug/deploy/jdk/jre/bin/java
-cp /home/nathan/workspace/helloworld/bin/ HelloWorld
[Thread debugging using libthread_db enabled]
[New Thread -1214162256 (LWP 13833)]
[New Thread -1215321200 (LWP 13836)]
[New process 13833]
[New LWP 13833]
Program received signal SIGILL, Illegal instruction.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0xb7b0c2ab in ?? () from /lib/tls/i686/cmov/libc.so.6
(gdb)
On 3/29/07, Nathan Beyer <nd...@apache.org> wrote:
> I am not seeing that. Can you run the "./java -version" successfully?
>
> I tried running "gdb ./java" and it loaded me into GDB just fine.
>
> -Nathan
>
> On 3/29/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > The jvmti tests are among the first to run. Is it a problem with jvmti
> > failures or is drlvm currently broken on linux? I seem to get a segmentation
> > violation running just the drlvm java executable on both 32 and 64 bit RHEL
> > Linux.
> >
> > gdb java
> >
> > I think shows an invalid pointer in hymem_free_memory()
> >
> > Is anyone else seeing this?
> >
> >
> >
> > On 3/29/07, Nathan Beyer <ndbeyer@apache.org > wrote:
> > >
> > > On 3/29/07, Gregory Shimansky < gshimansky@gmail.com> wrote:
> > > > Nathan Beyer wrote:
> > > > > On 3/28/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > >> Nathan Beyer wrote:
> > > > >> > I'm getting consistent failures of the following tests on Ubuntu
> > > > >> > 7.04-dev running on Quad Xeon P3 hardware. I saw some other threads
> > > on
> > > > >> > the mailing list about failures on a dual CPU machine, are these
> > > the
> > > > >> > same failures.
> > > > >> >
> > > > >> > Is there anyway to get some more information about these failures?
> > > > >> > Stack trace? dumps?
> > > > >> >
> > > > >> > -Nathan
> > > > >> >
> > > > >> > Breakpoint1 failed on Client mode JIT (default)
> > > > >> > SingleStep1 failed on Client mode JIT (default)
> > > > >> > VMInit1 failed on Client mode JIT (default)
> > > > >> > Breakpoint1 failed on interpreter
> > > > >> > SingleStep1 failed on interpreter
> > > > >> > VMInit1 failed on interpreter
> > > > >>
> > > > >> The tests produce a report in
> > > > >> lnx_ia32_gcc_debug/semis/jvmti.tests/reports which you can try to
> > > > >> analyze. There should be the output why the tests failed. The tests
> > > > >> you've mentioned are single threaded and shouldn't depend on the
> > > number
> > > > >> of CPUs.
> > > > >
> > > > > I'm seeing three folders under
> > > > > "build/lnx_ia32_gcc_debug/semis/jvmti.tests/reports/" and "int", "jit"
> > > > > and "opt" folder. All of them are empty.
> > > >
> > > > Try this command line to run the test in command line. Tests have to be
> > > > compiled before running it
> > > >
> > > > ./lnx_ia32_gcc_debug/deploy/jdk/jre/bin/java -cp
> > > > make/tmp/junit.jar:./lnx_ia32_gcc_debug/semis/jvmti.tests/classes
> > > >
> > > -agentpath:./lnx_ia32_gcc_debug/semis/jvmti.tests/native/Breakpoint1/libBreakpoint1.so
> > > > junit.textui.TestRunner Breakpoint1.Breakpoint1
> > > >
> > > > --
> > > > Gregory
> > > >
> > > >
> > >
> > > I tried that and this is what is output to the console (the report
> > > folders are still empty).
> > >
> > > DEBUG: Getting JVMTI enviroment...
> > > DEBUG: done!
> > > DEBUG: Setting capabilities...
> > > DEBUG: done!
> > > DEBUG: Setting events...
> > > DEBUG: done!
> > > Illegal instruction
> > >
> >
>
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Rana Dasgupta <rd...@gmail.com>.
just running "gdb java" produces below...
(gdb) run
Starting program:
/home/rana/Harmonystuff/trunk/working_vm/build/lnx_em64t_gcc_debug/deploy/jdk/jre/bin/java
[Thread debugging using libthread_db enabled]
[New Thread 182905755584 (LWP 24318)]
[New Thread 1084229984 (LWP 24321)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182905755584 (LWP 24318)]
0x00000036cb2691a5 in free () from /lib64/tls/libc.so.6
(gdb) bt
#0 0x00000036cb2691a5 in free () from /lib64/tls/libc.so.6
#1 0x0000002a95f34633 in hymem_free_memory (portLibrary=0x7fbfffee20,
memoryPointer=0x535500006e65) at hymem.c:112
#2 0x0000002a95f34d4a in hynls_set_catalog (portLibrary=0x7fbfffee20,
paths=0x520e20, nPaths=2, baseName=0x2a95f44bb6 "harmony",
extension=0x2a95f44bab "properties") at ../shared/hynls.c:345
#3 0x0000002a95f37806 in initNLSCatalog (portLib=0x7fbfffee20)
at ../shared/hyport.c:616
#4 0x0000002a95f36f25 in hyport_init_library (portLibrary=0x7fbfffee20,
version=0x7fbfffee10, size=1848) at ../shared/hyport.c:58
#5 0x0000000000403dc8 in main (argc=1, argv=0x7fbffff638, envp=0x7fbffff648)
at ../shared/cmain.c:131
On 3/29/07, Rana Dasgupta <rd...@gmail.com> wrote:
>
> No I get the segmentation fault even when running "./java -version" with a clean classlib + drlvm build from today's trunk. Of course, I also get the jvmti failure but I think that this maybe because it's the first test we hit in "build test".
>
> I'll try to paste the gdb stack trace, but gmail is somehow thwarting my paste attempts :-)
>
>
>
>
>
> On 3/29/07, Nathan Beyer <ndbeyer@apache.org > wrote:
> > I am not seeing that. Can you run the "./java -version" successfully?
> >
> > I tried running "gdb ./java" and it loaded me into GDB just fine.
> >
> > -Nathan
> >
> > On 3/29/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > The jvmti tests are among the first to run. Is it a problem with jvmti
> > > failures or is drlvm currently broken on linux? I seem to get a segmentation
> > > violation running just the drlvm java executable on both 32 and 64 bit RHEL
> > > Linux.
> > >
> > > gdb java
> > >
> > > I think shows an invalid pointer in hymem_free_memory()
> > >
> > > Is anyone else seeing this?
> > >
> > >
> > >
> > > On 3/29/07, Nathan Beyer < ndbeyer@apache.org > wrote:
> > > >
> > > > On 3/29/07, Gregory Shimansky < gshimansky@gmail.com > wrote:
> > > > > Nathan Beyer wrote:
> > > > > > On 3/28/07, Gregory Shimansky <gshimansky@gmail.com > wrote:
> > > > > >> Nathan Beyer wrote:
> > > > > >> > I'm getting consistent failures of the following tests on Ubuntu
> > > > > >> > 7.04-dev running on Quad Xeon P3 hardware. I saw some other threads
> > > > on
> > > > > >> > the mailing list about failures on a dual CPU machine, are these
> > > > the
> > > > > >> > same failures.
> > > > > >> >
> > > > > >> > Is there anyway to get some more information about these failures?
> > > > > >> > Stack trace? dumps?
> > > > > >> >
> > > > > >> > -Nathan
> > > > > >> >
> > > > > >> > Breakpoint1 failed on Client mode JIT (default)
> > > > > >> > SingleStep1 failed on Client mode JIT (default)
> > > > > >> > VMInit1 failed on Client mode JIT (default)
> > > > > >> > Breakpoint1 failed on interpreter
> > > > > >> > SingleStep1 failed on interpreter
> > > > > >> > VMInit1 failed on interpreter
> > > > > >>
> > > > > >> The tests produce a report in
> > > > > >> lnx_ia32_gcc_debug/semis/jvmti.tests/reports which you can try to
> > > > > >> analyze. There should be the output why the tests failed. The tests
> > > > > >> you've mentioned are single threaded and shouldn't depend on the
> > > > number
> > > > > >> of CPUs.
> > > > > >
> > > > > > I'm seeing three folders under
> > > > > > "build/lnx_ia32_gcc_debug/semis/jvmti.tests/reports/" and "int", "jit"
> > > > > > and "opt" folder. All of them are empty.
> > > > >
> > > > > Try this command line to run the test in command line. Tests have to be
> > > > > compiled before running it
> > > > >
> > > > > ./lnx_ia32_gcc_debug/deploy/jdk/jre/bin/java -cp
> > > > > make/tmp/junit.jar:./lnx_ia32_gcc_debug/semis/jvmti.tests/classes
> > > > >
> > > > -agentpath:./lnx_ia32_gcc_debug/semis/jvmti.tests/native/Breakpoint1/libBreakpoint1.so
> > > > > junit.textui.TestRunner Breakpoint1.Breakpoint1
> > > > >
> > > > > --
> > > > > Gregory
> > > > >
> > > > >
> > > >
> > > > I tried that and this is what is output to the console (the report
> > > > folders are still empty).
> > > >
> > > > DEBUG: Getting JVMTI enviroment...
> > > > DEBUG: done!
> > > > DEBUG: Setting capabilities...
> > > > DEBUG: done!
> > > > DEBUG: Setting events...
> > > > DEBUG: done!
> > > > Illegal instruction
> > > >
> > >
> >
>
>
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Rana Dasgupta <rd...@gmail.com>.
No I get the segmentation fault even when running "./java -version" with a
clean classlib + drlvm build from today's trunk. Of course, I also get the
jvmti failure but I think that this maybe because it's the first test we hit
in "build test".
I'll try to paste the gdb stack trace, but gmail is somehow thwarting my
paste attempts :-)
On 3/29/07, Nathan Beyer <nd...@apache.org> wrote:
>
> I am not seeing that. Can you run the "./java -version" successfully?
>
> I tried running "gdb ./java" and it loaded me into GDB just fine.
>
> -Nathan
>
> On 3/29/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > The jvmti tests are among the first to run. Is it a problem with jvmti
> > failures or is drlvm currently broken on linux? I seem to get a
> segmentation
> > violation running just the drlvm java executable on both 32 and 64 bit
> RHEL
> > Linux.
> >
> > gdb java
> >
> > I think shows an invalid pointer in hymem_free_memory()
> >
> > Is anyone else seeing this?
> >
> >
> >
> > On 3/29/07, Nathan Beyer <ndbeyer@apache.org > wrote:
> > >
> > > On 3/29/07, Gregory Shimansky < gshimansky@gmail.com> wrote:
> > > > Nathan Beyer wrote:
> > > > > On 3/28/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > >> Nathan Beyer wrote:
> > > > >> > I'm getting consistent failures of the following tests on
> Ubuntu
> > > > >> > 7.04-dev running on Quad Xeon P3 hardware. I saw some other
> threads
> > > on
> > > > >> > the mailing list about failures on a dual CPU machine, are
> these
> > > the
> > > > >> > same failures.
> > > > >> >
> > > > >> > Is there anyway to get some more information about these
> failures?
> > > > >> > Stack trace? dumps?
> > > > >> >
> > > > >> > -Nathan
> > > > >> >
> > > > >> > Breakpoint1 failed on Client mode JIT (default)
> > > > >> > SingleStep1 failed on Client mode JIT (default)
> > > > >> > VMInit1 failed on Client mode JIT (default)
> > > > >> > Breakpoint1 failed on interpreter
> > > > >> > SingleStep1 failed on interpreter
> > > > >> > VMInit1 failed on interpreter
> > > > >>
> > > > >> The tests produce a report in
> > > > >> lnx_ia32_gcc_debug/semis/jvmti.tests/reports which you can try to
>
> > > > >> analyze. There should be the output why the tests failed. The
> tests
> > > > >> you've mentioned are single threaded and shouldn't depend on the
> > > number
> > > > >> of CPUs.
> > > > >
> > > > > I'm seeing three folders under
> > > > > "build/lnx_ia32_gcc_debug/semis/jvmti.tests/reports/" and "int",
> "jit"
> > > > > and "opt" folder. All of them are empty.
> > > >
> > > > Try this command line to run the test in command line. Tests have to
> be
> > > > compiled before running it
> > > >
> > > > ./lnx_ia32_gcc_debug/deploy/jdk/jre/bin/java -cp
> > > > make/tmp/junit.jar:./lnx_ia32_gcc_debug/semis/jvmti.tests/classes
> > > >
> > >
> -agentpath:./lnx_ia32_gcc_debug/semis/jvmti.tests/native/Breakpoint1/libBreakpoint1.so
> > > > junit.textui.TestRunner Breakpoint1.Breakpoint1
> > > >
> > > > --
> > > > Gregory
> > > >
> > > >
> > >
> > > I tried that and this is what is output to the console (the report
> > > folders are still empty).
> > >
> > > DEBUG: Getting JVMTI enviroment...
> > > DEBUG: done!
> > > DEBUG: Setting capabilities...
> > > DEBUG: done!
> > > DEBUG: Setting events...
> > > DEBUG: done!
> > > Illegal instruction
> > >
> >
>
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Nathan Beyer <nd...@apache.org>.
I am not seeing that. Can you run the "./java -version" successfully?
I tried running "gdb ./java" and it loaded me into GDB just fine.
-Nathan
On 3/29/07, Rana Dasgupta <rd...@gmail.com> wrote:
> The jvmti tests are among the first to run. Is it a problem with jvmti
> failures or is drlvm currently broken on linux? I seem to get a segmentation
> violation running just the drlvm java executable on both 32 and 64 bit RHEL
> Linux.
>
> gdb java
>
> I think shows an invalid pointer in hymem_free_memory()
>
> Is anyone else seeing this?
>
>
>
> On 3/29/07, Nathan Beyer <ndbeyer@apache.org > wrote:
> >
> > On 3/29/07, Gregory Shimansky < gshimansky@gmail.com> wrote:
> > > Nathan Beyer wrote:
> > > > On 3/28/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > >> Nathan Beyer wrote:
> > > >> > I'm getting consistent failures of the following tests on Ubuntu
> > > >> > 7.04-dev running on Quad Xeon P3 hardware. I saw some other threads
> > on
> > > >> > the mailing list about failures on a dual CPU machine, are these
> > the
> > > >> > same failures.
> > > >> >
> > > >> > Is there anyway to get some more information about these failures?
> > > >> > Stack trace? dumps?
> > > >> >
> > > >> > -Nathan
> > > >> >
> > > >> > Breakpoint1 failed on Client mode JIT (default)
> > > >> > SingleStep1 failed on Client mode JIT (default)
> > > >> > VMInit1 failed on Client mode JIT (default)
> > > >> > Breakpoint1 failed on interpreter
> > > >> > SingleStep1 failed on interpreter
> > > >> > VMInit1 failed on interpreter
> > > >>
> > > >> The tests produce a report in
> > > >> lnx_ia32_gcc_debug/semis/jvmti.tests/reports which you can try to
> > > >> analyze. There should be the output why the tests failed. The tests
> > > >> you've mentioned are single threaded and shouldn't depend on the
> > number
> > > >> of CPUs.
> > > >
> > > > I'm seeing three folders under
> > > > "build/lnx_ia32_gcc_debug/semis/jvmti.tests/reports/" and "int", "jit"
> > > > and "opt" folder. All of them are empty.
> > >
> > > Try this command line to run the test in command line. Tests have to be
> > > compiled before running it
> > >
> > > ./lnx_ia32_gcc_debug/deploy/jdk/jre/bin/java -cp
> > > make/tmp/junit.jar:./lnx_ia32_gcc_debug/semis/jvmti.tests/classes
> > >
> > -agentpath:./lnx_ia32_gcc_debug/semis/jvmti.tests/native/Breakpoint1/libBreakpoint1.so
> > > junit.textui.TestRunner Breakpoint1.Breakpoint1
> > >
> > > --
> > > Gregory
> > >
> > >
> >
> > I tried that and this is what is output to the console (the report
> > folders are still empty).
> >
> > DEBUG: Getting JVMTI enviroment...
> > DEBUG: done!
> > DEBUG: Setting capabilities...
> > DEBUG: done!
> > DEBUG: Setting events...
> > DEBUG: done!
> > Illegal instruction
> >
>
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Rana Dasgupta <rd...@gmail.com>.
The jvmti tests are among the first to run. Is it a problem with jvmti
failures or is drlvm currently broken on linux? I seem to get a segmentation
violation running just the drlvm java executable on both 32 and 64 bit RHEL
Linux.
gdb java
I think shows an invalid pointer in hymem_free_memory()
Is anyone else seeing this?
On 3/29/07, Nathan Beyer <ndbeyer@apache.org > wrote:
>
> On 3/29/07, Gregory Shimansky < gshimansky@gmail.com> wrote:
> > Nathan Beyer wrote:
> > > On 3/28/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > >> Nathan Beyer wrote:
> > >> > I'm getting consistent failures of the following tests on Ubuntu
> > >> > 7.04-dev running on Quad Xeon P3 hardware. I saw some other threads
> on
> > >> > the mailing list about failures on a dual CPU machine, are these
> the
> > >> > same failures.
> > >> >
> > >> > Is there anyway to get some more information about these failures?
> > >> > Stack trace? dumps?
> > >> >
> > >> > -Nathan
> > >> >
> > >> > Breakpoint1 failed on Client mode JIT (default)
> > >> > SingleStep1 failed on Client mode JIT (default)
> > >> > VMInit1 failed on Client mode JIT (default)
> > >> > Breakpoint1 failed on interpreter
> > >> > SingleStep1 failed on interpreter
> > >> > VMInit1 failed on interpreter
> > >>
> > >> The tests produce a report in
> > >> lnx_ia32_gcc_debug/semis/jvmti.tests/reports which you can try to
> > >> analyze. There should be the output why the tests failed. The tests
> > >> you've mentioned are single threaded and shouldn't depend on the
> number
> > >> of CPUs.
> > >
> > > I'm seeing three folders under
> > > "build/lnx_ia32_gcc_debug/semis/jvmti.tests/reports/" and "int", "jit"
> > > and "opt" folder. All of them are empty.
> >
> > Try this command line to run the test in command line. Tests have to be
> > compiled before running it
> >
> > ./lnx_ia32_gcc_debug/deploy/jdk/jre/bin/java -cp
> > make/tmp/junit.jar:./lnx_ia32_gcc_debug/semis/jvmti.tests/classes
> >
> -agentpath:./lnx_ia32_gcc_debug/semis/jvmti.tests/native/Breakpoint1/libBreakpoint1.so
> > junit.textui.TestRunner Breakpoint1.Breakpoint1
> >
> > --
> > Gregory
> >
> >
>
> I tried that and this is what is output to the console (the report
> folders are still empty).
>
> DEBUG: Getting JVMTI enviroment...
> DEBUG: done!
> DEBUG: Setting capabilities...
> DEBUG: done!
> DEBUG: Setting events...
> DEBUG: done!
> Illegal instruction
>
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Nathan Beyer <nd...@apache.org>.
On 3/29/07, Gregory Shimansky <gs...@gmail.com> wrote:
> Nathan Beyer wrote:
> > On 3/28/07, Gregory Shimansky <gs...@gmail.com> wrote:
> >> Nathan Beyer wrote:
> >> > I'm getting consistent failures of the following tests on Ubuntu
> >> > 7.04-dev running on Quad Xeon P3 hardware. I saw some other threads on
> >> > the mailing list about failures on a dual CPU machine, are these the
> >> > same failures.
> >> >
> >> > Is there anyway to get some more information about these failures?
> >> > Stack trace? dumps?
> >> >
> >> > -Nathan
> >> >
> >> > Breakpoint1 failed on Client mode JIT (default)
> >> > SingleStep1 failed on Client mode JIT (default)
> >> > VMInit1 failed on Client mode JIT (default)
> >> > Breakpoint1 failed on interpreter
> >> > SingleStep1 failed on interpreter
> >> > VMInit1 failed on interpreter
> >>
> >> The tests produce a report in
> >> lnx_ia32_gcc_debug/semis/jvmti.tests/reports which you can try to
> >> analyze. There should be the output why the tests failed. The tests
> >> you've mentioned are single threaded and shouldn't depend on the number
> >> of CPUs.
> >
> > I'm seeing three folders under
> > "build/lnx_ia32_gcc_debug/semis/jvmti.tests/reports/" and "int", "jit"
> > and "opt" folder. All of them are empty.
>
> Try this command line to run the test in command line. Tests have to be
> compiled before running it
>
> ./lnx_ia32_gcc_debug/deploy/jdk/jre/bin/java -cp
> make/tmp/junit.jar:./lnx_ia32_gcc_debug/semis/jvmti.tests/classes
> -agentpath:./lnx_ia32_gcc_debug/semis/jvmti.tests/native/Breakpoint1/libBreakpoint1.so
> junit.textui.TestRunner Breakpoint1.Breakpoint1
>
> --
> Gregory
>
>
I tried that and this is what is output to the console (the report
folders are still empty).
DEBUG: Getting JVMTI enviroment...
DEBUG: done!
DEBUG: Setting capabilities...
DEBUG: done!
DEBUG: Setting events...
DEBUG: done!
Illegal instruction
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon
P3
Posted by Gregory Shimansky <gs...@gmail.com>.
Nathan Beyer wrote:
> On 3/28/07, Gregory Shimansky <gs...@gmail.com> wrote:
>> Nathan Beyer wrote:
>> > I'm getting consistent failures of the following tests on Ubuntu
>> > 7.04-dev running on Quad Xeon P3 hardware. I saw some other threads on
>> > the mailing list about failures on a dual CPU machine, are these the
>> > same failures.
>> >
>> > Is there anyway to get some more information about these failures?
>> > Stack trace? dumps?
>> >
>> > -Nathan
>> >
>> > Breakpoint1 failed on Client mode JIT (default)
>> > SingleStep1 failed on Client mode JIT (default)
>> > VMInit1 failed on Client mode JIT (default)
>> > Breakpoint1 failed on interpreter
>> > SingleStep1 failed on interpreter
>> > VMInit1 failed on interpreter
>>
>> The tests produce a report in
>> lnx_ia32_gcc_debug/semis/jvmti.tests/reports which you can try to
>> analyze. There should be the output why the tests failed. The tests
>> you've mentioned are single threaded and shouldn't depend on the number
>> of CPUs.
>
> I'm seeing three folders under
> "build/lnx_ia32_gcc_debug/semis/jvmti.tests/reports/" and "int", "jit"
> and "opt" folder. All of them are empty.
Try this command line to run the test in command line. Tests have to be
compiled before running it
./lnx_ia32_gcc_debug/deploy/jdk/jre/bin/java -cp
make/tmp/junit.jar:./lnx_ia32_gcc_debug/semis/jvmti.tests/classes
-agentpath:./lnx_ia32_gcc_debug/semis/jvmti.tests/native/Breakpoint1/libBreakpoint1.so
junit.textui.TestRunner Breakpoint1.Breakpoint1
--
Gregory
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon P3
Posted by Nathan Beyer <nd...@apache.org>.
On 3/28/07, Gregory Shimansky <gs...@gmail.com> wrote:
> Nathan Beyer wrote:
> > I'm getting consistent failures of the following tests on Ubuntu
> > 7.04-dev running on Quad Xeon P3 hardware. I saw some other threads on
> > the mailing list about failures on a dual CPU machine, are these the
> > same failures.
> >
> > Is there anyway to get some more information about these failures?
> > Stack trace? dumps?
> >
> > -Nathan
> >
> > Breakpoint1 failed on Client mode JIT (default)
> > SingleStep1 failed on Client mode JIT (default)
> > VMInit1 failed on Client mode JIT (default)
> > Breakpoint1 failed on interpreter
> > SingleStep1 failed on interpreter
> > VMInit1 failed on interpreter
>
> The tests produce a report in
> lnx_ia32_gcc_debug/semis/jvmti.tests/reports which you can try to
> analyze. There should be the output why the tests failed. The tests
> you've mentioned are single threaded and shouldn't depend on the number
> of CPUs.
I'm seeing three folders under
"build/lnx_ia32_gcc_debug/semis/jvmti.tests/reports/" and "int", "jit"
and "opt" folder. All of them are empty.
Any suggestions?
>
> --
> Gregory
>
>
Re: [drlvm] tests failing on linux (Ubuntu 7.04-dev) with Quad Xeon
P3
Posted by Gregory Shimansky <gs...@gmail.com>.
Nathan Beyer wrote:
> I'm getting consistent failures of the following tests on Ubuntu
> 7.04-dev running on Quad Xeon P3 hardware. I saw some other threads on
> the mailing list about failures on a dual CPU machine, are these the
> same failures.
>
> Is there anyway to get some more information about these failures?
> Stack trace? dumps?
>
> -Nathan
>
> Breakpoint1 failed on Client mode JIT (default)
> SingleStep1 failed on Client mode JIT (default)
> VMInit1 failed on Client mode JIT (default)
> Breakpoint1 failed on interpreter
> SingleStep1 failed on interpreter
> VMInit1 failed on interpreter
The tests produce a report in
lnx_ia32_gcc_debug/semis/jvmti.tests/reports which you can try to
analyze. There should be the output why the tests failed. The tests
you've mentioned are single threaded and shouldn't depend on the number
of CPUs.
--
Gregory