|
From: Maynard J. <may...@us...> - 2013-08-13 19:51:26
|
Using an SVN checkout done today, I get the following error when running a test java app under Valgrind: [maynard@oc3431575272 myJavaStuff]$ valgrind --tool=none java ThreadLoop 1 ==18410== Nulgrind, the minimal Valgrind tool ==18410== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote. ==18410== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info ==18410== Command: java ThreadLoop 1 ==18410== --18410-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --18410-- si_code=1; Faulting address: 0x11; sp: 0x80277d490 valgrind: the 'impossible' happened: Killed by fatal signal ==18410== at 0x380BF6BB: deepCopyIRExpr (ir_defs.c:2130) ==18410== by 0x380BFB14: deepCopyIRExprVec (ir_defs.c:2093) ==18410== by 0x380BFB62: deepCopyIRDirty (ir_defs.c:2189) ==18410== by 0x380BFF30: deepCopyIRStmt (ir_defs.c:2267) ==18410== by 0x380BFFBF: deepCopyIRSB (ir_defs.c:2300) ==18410== by 0x380CA55E: do_iropt_BB (ir_opt.c:4586) ==18410== by 0x380B3839: LibVEX_Translate (main_main.c:725) ==18410== by 0x380137C0: vgPlain_translate (m_translate.c:1602) ==18410== by 0x38046DCA: handle_chain_me (scheduler.c:1028) ==18410== by 0x38048A87: vgPlain_scheduler (scheduler.c:1326) ==18410== by 0x38076809: run_a_thread_NORETURN (syswrap-linux.c:103) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==18410== at 0x3039729B69: __strrchr_sse42 (in /lib64/libc-2.12.so) ==18410== by 0x4062EE: GetApplicationHome (in /usr/lib/jvm/java-1.6.0-ibm-1.6.0.14.0.x86_64/jre/bin/java) ==18410== by 0x4060B4: GetJREPath (in /usr/lib/jvm/java-1.6.0-ibm-1.6.0.14.0.x86_64/jre/bin/java) ==18410== by 0x405DAD: CreateExecutionEnvironment (in /usr/lib/jvm/java-1.6.0-ibm-1.6.0.14.0.x86_64/jre/bin/java) ==18410== by 0x4022C0: main (in /usr/lib/jvm/java-1.6.0-ibm-1.6.0.14.0.x86_64/jre/bin/java) --------------------------------------- |
|
From: Florian K. <fl...@ei...> - 2013-08-13 20:27:52
|
On 08/13/2013 09:51 PM, Maynard Johnson wrote: > Using an SVN checkout done today, I get the following error when running a test java app under Valgrind: > > [maynard@oc3431575272 myJavaStuff]$ valgrind --tool=none java ThreadLoop 1 > ==18410== Nulgrind, the minimal Valgrind tool > ==18410== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote. > ==18410== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info > ==18410== Command: java ThreadLoop 1 > ==18410== > --18410-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting > --18410-- si_code=1; Faulting address: 0x11; sp: 0x80277d490 > > valgrind: the 'impossible' happened: > Killed by fatal signal > ==18410== at 0x380BF6BB: deepCopyIRExpr (ir_defs.c:2130) > ==18410== by 0x380BFB14: deepCopyIRExprVec (ir_defs.c:2093) I bet that e is IRExprP__BBPTR which is ((IRExpr*)17) which is 0x11, the faulting address. Looks as if deepCopyIRExprVec does not handle the special expressions introduced recently. There may be other places. I haven't checked. Unless you beat me to it I'll look at fixing it tomorrow. Florian |
|
From: Julian S. <js...@ac...> - 2013-08-14 08:31:51
|
On 08/13/2013 10:03 PM, Florian Krohm wrote: > I bet that e is IRExprP__BBPTR which is ((IRExpr*)17) which is 0x11, > the faulting address. Looks as if deepCopyIRExprVec does not handle the > special expressions introduced recently. I bet you are exactly right about that. Also shallowCopyIRExprVec has the same problem. deepCopyIRExprVec is only used by the IR loop unroller, which is relatively unlikely to be activated on code with dirty helper calls, which is why it didn't get detected until now. I just had the unpleasant realisation that adding IRExprP__* has had an undesired side effect: it is possible to put these constants at the leaf of an expression tree, and get something which is completely meaningless, eg IRExpr_Binop(Iop_Add64, IRExpr_RdTmp(t), IRExprP__BBPTR). Urr. In hindsight it would have been cleaner to have left IRExpr unchanged but instead changed the type of the IRExprVec components to be a type which is basically "all IRExpr*s, plus IRExprP__BBPTR, plus IRExpr__VECRET". Then it wouldn't be possible to construct nonsense trees using the new constants. J |
|
From: Florian K. <fl...@ei...> - 2013-08-14 12:30:58
|
On 08/14/2013 10:31 AM, Julian Seward wrote: > On 08/13/2013 10:03 PM, Florian Krohm wrote: > >> I bet that e is IRExprP__BBPTR which is ((IRExpr*)17) which is 0x11, >> the faulting address. Looks as if deepCopyIRExprVec does not handle the >> special expressions introduced recently. > > I bet you are exactly right about that. Also shallowCopyIRExprVec has the > same problem. Not really, as that function just copies the pointers of the vector elements. Nor does deepCopyIRExprVec, as I said earlier. The function that has the problem is deepCopyIRExpr. It needs if (UNLIKELY(is_IRExprP__VECRET_or_BBPTR(e))) return e; at the beginning. Certain utility functions for IRExpr need adjustment, too. ppIRExpr comes to mind and typeOfIRExpr. > I just had the unpleasant realisation that adding IRExprP__* has had an > undesired side effect: it is possible to put these constants at the leaf > of an expression tree, and get something which is completely meaningless, > eg IRExpr_Binop(Iop_Add64, IRExpr_RdTmp(t), IRExprP__BBPTR). Urr. True. And you can do similar nonsense with Iex_Binder expressions, btw. It might be better actually, to introduce new IRExpr node kinds for VECRET and BBPTR. Doing that makes it easier to find all the places that need adjustment. E.g. GCC has options to find unhandled enumerators in switch statements... And we would never have to worry about e->tag possibly segfaulting as long as e != 0. > In hindsight it would have been cleaner to have left IRExpr unchanged but > instead changed the type of the IRExprVec components to be a type which is > basically "all IRExpr*s, plus IRExprP__BBPTR, plus IRExpr__VECRET". Then > it wouldn't be possible to construct nonsense trees using the new constants. Yes. Florian |
|
From: Maynard J. <may...@us...> - 2013-08-14 12:51:39
|
On 08/13/2013 03:03 PM, Florian Krohm wrote: > On 08/13/2013 09:51 PM, Maynard Johnson wrote: >> Using an SVN checkout done today, I get the following error when running a test java app under Valgrind: Sorry, but I forgot to say yesterday that I was only seeing this error on my Intel Core 2 Duo laptop. The current valgrind from SVN trunk worked OK on my ppc64 box. I'm at a different work location today and using a Sandybridge laptop (Intel Core i7) -- and oddly, I cannot reproduce the error, using the same JVM. -Maynard >> >> [maynard@oc3431575272 myJavaStuff]$ valgrind --tool=none java ThreadLoop 1 >> ==18410== Nulgrind, the minimal Valgrind tool >> ==18410== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote. >> ==18410== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info >> ==18410== Command: java ThreadLoop 1 >> ==18410== >> --18410-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting >> --18410-- si_code=1; Faulting address: 0x11; sp: 0x80277d490 >> >> valgrind: the 'impossible' happened: >> Killed by fatal signal >> ==18410== at 0x380BF6BB: deepCopyIRExpr (ir_defs.c:2130) >> ==18410== by 0x380BFB14: deepCopyIRExprVec (ir_defs.c:2093) > > I bet that e is IRExprP__BBPTR which is ((IRExpr*)17) which is 0x11, > the faulting address. Looks as if deepCopyIRExprVec does not handle the > special expressions introduced recently. There may be other places. I > haven't checked. Unless you beat me to it I'll look at fixing it tomorrow. > > Florian > > |
|
From: Julian S. <js...@ac...> - 2013-08-16 14:55:41
|
Maynard, Florian landed a change last night -- r13498/r2742 -- which should fix this. Pls yell if it's still broken. J On 08/14/2013 02:51 PM, Maynard Johnson wrote: > On 08/13/2013 03:03 PM, Florian Krohm wrote: >> On 08/13/2013 09:51 PM, Maynard Johnson wrote: >>> Using an SVN checkout done today, I get the following error when running a test java app under Valgrind: > Sorry, but I forgot to say yesterday that I was only seeing this error on my Intel Core 2 Duo laptop. The current valgrind from SVN trunk worked OK on my ppc64 box. > > I'm at a different work location today and using a Sandybridge laptop (Intel Core i7) -- and oddly, I cannot reproduce the error, using the same JVM. > > -Maynard >>> >>> [maynard@oc3431575272 myJavaStuff]$ valgrind --tool=none java ThreadLoop 1 >>> ==18410== Nulgrind, the minimal Valgrind tool >>> ==18410== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote. >>> ==18410== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info >>> ==18410== Command: java ThreadLoop 1 >>> ==18410== >>> --18410-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting >>> --18410-- si_code=1; Faulting address: 0x11; sp: 0x80277d490 >>> >>> valgrind: the 'impossible' happened: >>> Killed by fatal signal >>> ==18410== at 0x380BF6BB: deepCopyIRExpr (ir_defs.c:2130) >>> ==18410== by 0x380BFB14: deepCopyIRExprVec (ir_defs.c:2093) >> >> I bet that e is IRExprP__BBPTR which is ((IRExpr*)17) which is 0x11, >> the faulting address. Looks as if deepCopyIRExprVec does not handle the >> special expressions introduced recently. There may be other places. I >> haven't checked. Unless you beat me to it I'll look at fixing it tomorrow. >> >> Florian >> >> > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Maynard J. <may...@us...> - 2013-08-16 15:46:23
|
On 08/16/2013 09:55 AM, Julian Seward wrote: > > Maynard, > > Florian landed a change last night -- r13498/r2742 -- which should fix this. > Pls yell if it's still broken. OK, thanks. I'll be out for a couple weeks as of this afternoon, and so will verify the fix when I return. -Maynard > > J > > On 08/14/2013 02:51 PM, Maynard Johnson wrote: >> On 08/13/2013 03:03 PM, Florian Krohm wrote: >>> On 08/13/2013 09:51 PM, Maynard Johnson wrote: >>>> Using an SVN checkout done today, I get the following error when running a test java app under Valgrind: >> Sorry, but I forgot to say yesterday that I was only seeing this error on my Intel Core 2 Duo laptop. The current valgrind from SVN trunk worked OK on my ppc64 box. >> >> I'm at a different work location today and using a Sandybridge laptop (Intel Core i7) -- and oddly, I cannot reproduce the error, using the same JVM. >> >> -Maynard >>>> >>>> [maynard@oc3431575272 myJavaStuff]$ valgrind --tool=none java ThreadLoop 1 >>>> ==18410== Nulgrind, the minimal Valgrind tool >>>> ==18410== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote. >>>> ==18410== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info >>>> ==18410== Command: java ThreadLoop 1 >>>> ==18410== >>>> --18410-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting >>>> --18410-- si_code=1; Faulting address: 0x11; sp: 0x80277d490 >>>> >>>> valgrind: the 'impossible' happened: >>>> Killed by fatal signal >>>> ==18410== at 0x380BF6BB: deepCopyIRExpr (ir_defs.c:2130) >>>> ==18410== by 0x380BFB14: deepCopyIRExprVec (ir_defs.c:2093) >>> >>> I bet that e is IRExprP__BBPTR which is ((IRExpr*)17) which is 0x11, >>> the faulting address. Looks as if deepCopyIRExprVec does not handle the >>> special expressions introduced recently. There may be other places. I >>> haven't checked. Unless you beat me to it I'll look at fixing it tomorrow. >>> >>> Florian >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Get 100% visibility into Java/.NET code with AppDynamics Lite! >> It's a free troubleshooting tool designed for production. >> Get down to code-level detail for bottlenecks, with <2% overhead. >> Download for free and get started troubleshooting in minutes. >> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk >> _______________________________________________ >> Valgrind-developers mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers >> > |
|
From: Maynard J. <may...@us...> - 2013-09-03 20:44:04
|
On 08/16/2013 10:45 AM, Maynard Johnson wrote: > On 08/16/2013 09:55 AM, Julian Seward wrote: >> >> Maynard, >> >> Florian landed a change last night -- r13498/r2742 -- which should fix this. >> Pls yell if it's still broken. > OK, thanks. I'll be out for a couple weeks as of this afternoon, and so will verify the fix when I return. I did 'svn up' on my valgrind directory and re-tested. I get a different error now (below) -- so far, only on my Intel Core 2 Duo/RHEL 6.4 system, not on my POWER7/RHEL 6.4 box. Is there some debug data I can collect? ----------------------------------------------------------- [maynard@oc3431575272 myJavaStuff]$ valgrind --tool=none java ThreadLoop 1 ==10580== Nulgrind, the minimal Valgrind tool ==10580== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote. ==10580== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info ==10580== Command: java ThreadLoop 1 ==10580== BBPTR vex: the `impossible' happened: deltaIRExpr vex storage: T total 42014720 bytes allocated vex storage: P total 640 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). ==10580== at 0x38086447: report_and_quit (m_libcassert.c:260) ==10580== by 0x380864AE: panic (m_libcassert.c:350) ==10580== by 0x38086508: vgPlain_core_panic_at (m_libcassert.c:355) ==10580== by 0x3808651A: vgPlain_core_panic (m_libcassert.c:360) ==10580== by 0x38015FC2: failure_exit (m_translate.c:731) ==10580== by 0x380B5BE8: vpanic (main_util.c:226) ==10580== by 0x380C1A5F: deltaIRExpr (ir_opt.c:4386) ==10580== by 0x380CAA0E: do_iropt_BB (ir_opt.c:4461) ==10580== by 0x380B3A29: LibVEX_Translate (main_main.c:725) ==10580== by 0x380137C0: vgPlain_translate (m_translate.c:1602) ==10580== by 0x38046E0A: handle_chain_me (scheduler.c:1028) ==10580== by 0x38048C77: vgPlain_scheduler (scheduler.c:1326) ==10580== by 0x380769F9: run_a_thread_NORETURN (syswrap-linux.c:103) -------------------------------------------------------- -Maynard > > -Maynard >> >> J >> >> On 08/14/2013 02:51 PM, Maynard Johnson wrote: >>> On 08/13/2013 03:03 PM, Florian Krohm wrote: >>>> On 08/13/2013 09:51 PM, Maynard Johnson wrote: >>>>> Using an SVN checkout done today, I get the following error when running a test java app under Valgrind: >>> Sorry, but I forgot to say yesterday that I was only seeing this error on my Intel Core 2 Duo laptop. The current valgrind from SVN trunk worked OK on my ppc64 box. >>> >>> I'm at a different work location today and using a Sandybridge laptop (Intel Core i7) -- and oddly, I cannot reproduce the error, using the same JVM. >>> >>> -Maynard >>>>> >>>>> [maynard@oc3431575272 myJavaStuff]$ valgrind --tool=none java ThreadLoop 1 >>>>> ==18410== Nulgrind, the minimal Valgrind tool >>>>> ==18410== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote. >>>>> ==18410== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info >>>>> ==18410== Command: java ThreadLoop 1 >>>>> ==18410== >>>>> --18410-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting >>>>> --18410-- si_code=1; Faulting address: 0x11; sp: 0x80277d490 >>>>> >>>>> valgrind: the 'impossible' happened: >>>>> Killed by fatal signal >>>>> ==18410== at 0x380BF6BB: deepCopyIRExpr (ir_defs.c:2130) >>>>> ==18410== by 0x380BFB14: deepCopyIRExprVec (ir_defs.c:2093) >>>> >>>> I bet that e is IRExprP__BBPTR which is ((IRExpr*)17) which is 0x11, >>>> the faulting address. Looks as if deepCopyIRExprVec does not handle the >>>> special expressions introduced recently. There may be other places. I >>>> haven't checked. Unless you beat me to it I'll look at fixing it tomorrow. >>>> >>>> Florian >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Get 100% visibility into Java/.NET code with AppDynamics Lite! >>> It's a free troubleshooting tool designed for production. >>> Get down to code-level detail for bottlenecks, with <2% overhead. >>> Download for free and get started troubleshooting in minutes. >>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Valgrind-developers mailing list >>> Val...@li... >>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers >>> >> > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Florian K. <fl...@ei...> - 2013-09-03 21:48:23
|
On 09/03/2013 10:43 PM, Maynard Johnson wrote: > On 08/16/2013 10:45 AM, Maynard Johnson wrote: >> On 08/16/2013 09:55 AM, Julian Seward wrote: >>> >>> Maynard, >>> >>> Florian landed a change last night -- r13498/r2742 -- which should fix this. >>> Pls yell if it's still broken. >> OK, thanks. I'll be out for a couple weeks as of this afternoon, and so will verify the fix when I return. > I did 'svn up' on my valgrind directory and re-tested. I get a different error now (below) -- so far, only on my Intel Core 2 Duo/RHEL 6.4 system, not on my POWER7/RHEL 6.4 box. Is there some debug data I can collect? > > ----------------------------------------------------------- > > [maynard@oc3431575272 myJavaStuff]$ valgrind --tool=none java ThreadLoop 1 > ==10580== Nulgrind, the minimal Valgrind tool > ==10580== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote. > ==10580== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info > ==10580== Command: java ThreadLoop 1 > ==10580== > > BBPTR > > vex: the `impossible' happened: > deltaIRExpr I checked in a fix for that. Try again. Florian |
|
From: Maynard J. <may...@us...> - 2013-09-04 12:33:51
|
On 09/03/2013 04:48 PM, Florian Krohm wrote: > On 09/03/2013 10:43 PM, Maynard Johnson wrote: >> On 08/16/2013 10:45 AM, Maynard Johnson wrote: >>> On 08/16/2013 09:55 AM, Julian Seward wrote: >>>> >>>> Maynard, >>>> >>>> Florian landed a change last night -- r13498/r2742 -- which should fix this. >>>> Pls yell if it's still broken. >>> OK, thanks. I'll be out for a couple weeks as of this afternoon, and so will verify the fix when I return. >> I did 'svn up' on my valgrind directory and re-tested. I get a different error now (below) -- so far, only on my Intel Core 2 Duo/RHEL 6.4 system, not on my POWER7/RHEL 6.4 box. Is there some debug data I can collect? >> >> ----------------------------------------------------------- >> >> [maynard@oc3431575272 myJavaStuff]$ valgrind --tool=none java ThreadLoop 1 >> ==10580== Nulgrind, the minimal Valgrind tool >> ==10580== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote. >> ==10580== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info >> ==10580== Command: java ThreadLoop 1 >> ==10580== >> >> BBPTR >> >> vex: the `impossible' happened: >> deltaIRExpr > > I checked in a fix for that. Try again. Works fine now. Thanks! :-) -Maynard > > Florian > |
|
From: Philippe W. <phi...@sk...> - 2013-09-04 14:59:56
|
On Wed, 2013-09-04 at 07:33 -0500, Maynard Johnson wrote: > > I checked in a fix for that. Try again. > Works fine now. Thanks! :-) Nice work, effectively. (from a previous mail:) > maynard@oc3431575272 myJavaStuff]$ valgrind --tool=none java ThreadLoop 1 Note that on Intel, valgrind-ing JIT code (such as Java JVM, or firefox executing Java scripts, or ...), you must pass --smc-check=all-non-file (or --smc-check=all) (this option is not needed on systems such as ppc64, MIPS, ...). Probably lucky this time and/or ThreadLoop is small :). Philippe |
|
From: Philippe W. <phi...@sk...> - 2013-08-13 20:29:35
|
On Tue, 2013-08-13 at 14:51 -0500, Maynard Johnson wrote:
> Using an SVN checkout done today, I get the following error when running a test java app under Valgrind:
>
> [maynard@oc3431575272 myJavaStuff]$ valgrind --tool=none java ThreadLoop 1
Missing --smc-check argument ?
--smc-check=none|stack|all|all-non-file [stack]
|