* [patch] Fix oddity in personality routine @ 2009-11-13 17:49 Eric Botcazou 2009-11-13 17:57 ` Andrew Haley 2009-11-13 19:18 ` Jack Howarth 0 siblings, 2 replies; 61+ messages in thread From: Eric Botcazou @ 2009-11-13 17:49 UTC (permalink / raw) To: java [-- Attachment #1: Type: text/plain, Size: 887 bytes --] Hi, r128098 has introduced an oddity in the personality routine: int ip_before_insn = 0; [...] // Parse the LSDA header. p = parse_lsda_header (context, language_specific_data, &info); #ifdef HAVE_GETIPINFO ip = _Unwind_GetIPInfo (context, &ip_before_insn); #else ip = _Unwind_GetIP (context) - 1; #endif if (! ip_before_insn) --ip; So, if !HAVE_GETIPINFO, the IP is decremented by 2! It used to be 1 and both libstdc++-v3/libsupc++/eh_personality.cc and ada/raise-gcc.c have the expected version: #ifdef _GLIBCXX_HAVE_GETIPINFO ip = _Unwind_GetIPInfo (context, &ip_before_insn); #else ip = _Unwind_GetIP (context); #endif if (! ip_before_insn) --ip; Hence the attached patch, that I don't plan to test though. OK anyway? 2009-11-13 Eric Botcazou <ebotcazou@adacore.com> * exception.cc (PERSONALITY_FUNCTION): Fix oversight. -- Eric Botcazou [-- Attachment #2: p.diff --] [-- Type: text/x-diff, Size: 408 bytes --] Index: exception.cc =================================================================== --- exception.cc (revision 154059) +++ exception.cc (working copy) @@ -328,7 +328,7 @@ PERSONALITY_FUNCTION (int version, #ifdef HAVE_GETIPINFO ip = _Unwind_GetIPInfo (context, &ip_before_insn); #else - ip = _Unwind_GetIP (context) - 1; + ip = _Unwind_GetIP (context); #endif if (! ip_before_insn) --ip; ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-13 17:49 [patch] Fix oddity in personality routine Eric Botcazou @ 2009-11-13 17:57 ` Andrew Haley 2009-11-13 18:36 ` Jack Howarth 2009-11-13 19:18 ` Jack Howarth 1 sibling, 1 reply; 61+ messages in thread From: Andrew Haley @ 2009-11-13 17:57 UTC (permalink / raw) To: Eric Botcazou; +Cc: java Eric Botcazou wrote: > Hi, > > r128098 has introduced an oddity in the personality routine: > > int ip_before_insn = 0; > [...] > > // Parse the LSDA header. > p = parse_lsda_header (context, language_specific_data, &info); > #ifdef HAVE_GETIPINFO > ip = _Unwind_GetIPInfo (context, &ip_before_insn); > #else > ip = _Unwind_GetIP (context) - 1; > #endif > if (! ip_before_insn) > --ip; > > So, if !HAVE_GETIPINFO, the IP is decremented by 2! It used to be 1 and both > libstdc++-v3/libsupc++/eh_personality.cc and ada/raise-gcc.c have the expected > version: > > #ifdef _GLIBCXX_HAVE_GETIPINFO > ip = _Unwind_GetIPInfo (context, &ip_before_insn); > #else > ip = _Unwind_GetIP (context); > #endif > if (! ip_before_insn) > --ip; > > Hence the attached patch, that I don't plan to test though. OK anyway? > > > 2009-11-13 Eric Botcazou <ebotcazou@adacore.com> > > * exception.cc (PERSONALITY_FUNCTION): Fix oversight. > Yes, I think that's right. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-13 17:57 ` Andrew Haley @ 2009-11-13 18:36 ` Jack Howarth 2009-11-13 18:39 ` Andrew Haley 0 siblings, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-11-13 18:36 UTC (permalink / raw) To: Andrew Haley; +Cc: Eric Botcazou, java On Fri, Nov 13, 2009 at 05:57:03PM +0000, Andrew Haley wrote: > Eric Botcazou wrote: > > Hi, > > > > r128098 has introduced an oddity in the personality routine: > > > > int ip_before_insn = 0; > > [...] > > > > // Parse the LSDA header. > > p = parse_lsda_header (context, language_specific_data, &info); > > #ifdef HAVE_GETIPINFO > > ip = _Unwind_GetIPInfo (context, &ip_before_insn); > > #else > > ip = _Unwind_GetIP (context) - 1; > > #endif > > if (! ip_before_insn) > > --ip; > > > > So, if !HAVE_GETIPINFO, the IP is decremented by 2! It used to be 1 and both > > libstdc++-v3/libsupc++/eh_personality.cc and ada/raise-gcc.c have the expected > > version: > > > > #ifdef _GLIBCXX_HAVE_GETIPINFO > > ip = _Unwind_GetIPInfo (context, &ip_before_insn); > > #else > > ip = _Unwind_GetIP (context); > > #endif > > if (! ip_before_insn) > > --ip; > > > > Hence the attached patch, that I don't plan to test though. OK anyway? > > > > > > 2009-11-13 Eric Botcazou <ebotcazou@adacore.com> > > > > * exception.cc (PERSONALITY_FUNCTION): Fix oversight. > > > > > Yes, I think that's right. > > Andrew. Andrew, Do you think this could be the origin of the problems we have had on intel darwin with gcj compiling java files? Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-13 18:36 ` Jack Howarth @ 2009-11-13 18:39 ` Andrew Haley 0 siblings, 0 replies; 61+ messages in thread From: Andrew Haley @ 2009-11-13 18:39 UTC (permalink / raw) To: Jack Howarth; +Cc: Eric Botcazou, java Jack Howarth wrote: > On Fri, Nov 13, 2009 at 05:57:03PM +0000, Andrew Haley wrote: >> Eric Botcazou wrote: >>> >>> Hence the attached patch, that I don't plan to test though. OK anyway? >>> >>> >>> 2009-11-13 Eric Botcazou <ebotcazou@adacore.com> >>> >>> * exception.cc (PERSONALITY_FUNCTION): Fix oversight. >>> >> >> Yes, I think that's right. = > Do you think this could be the origin of the problems we have had > on intel darwin with gcj compiling java files? Perhaps. I never guess such things: I always attach a debugger. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-13 17:49 [patch] Fix oddity in personality routine Eric Botcazou 2009-11-13 17:57 ` Andrew Haley @ 2009-11-13 19:18 ` Jack Howarth 2009-11-15 23:02 ` Bryce McKinlay 1 sibling, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-11-13 19:18 UTC (permalink / raw) To: Eric Botcazou; +Cc: java On Fri, Nov 13, 2009 at 06:50:03PM +0100, Eric Botcazou wrote: > Hi, > > r128098 has introduced an oddity in the personality routine: > > int ip_before_insn = 0; > [...] > > // Parse the LSDA header. > p = parse_lsda_header (context, language_specific_data, &info); > #ifdef HAVE_GETIPINFO > ip = _Unwind_GetIPInfo (context, &ip_before_insn); > #else > ip = _Unwind_GetIP (context) - 1; > #endif > if (! ip_before_insn) > --ip; > > So, if !HAVE_GETIPINFO, the IP is decremented by 2! It used to be 1 and both > libstdc++-v3/libsupc++/eh_personality.cc and ada/raise-gcc.c have the expected > version: > > #ifdef _GLIBCXX_HAVE_GETIPINFO > ip = _Unwind_GetIPInfo (context, &ip_before_insn); > #else > ip = _Unwind_GetIP (context); > #endif > if (! ip_before_insn) > --ip; > > Hence the attached patch, that I don't plan to test though. OK anyway? > > > 2009-11-13 Eric Botcazou <ebotcazou@adacore.com> > > * exception.cc (PERSONALITY_FUNCTION): Fix oversight. > > > -- > Eric Botcazou > Index: exception.cc > =================================================================== > --- exception.cc (revision 154059) > +++ exception.cc (working copy) > @@ -328,7 +328,7 @@ PERSONALITY_FUNCTION (int version, > #ifdef HAVE_GETIPINFO > ip = _Unwind_GetIPInfo (context, &ip_before_insn); > #else > - ip = _Unwind_GetIP (context) - 1; > + ip = _Unwind_GetIP (context); > #endif > if (! ip_before_insn) > --ip; Shouldn't this fix also get backported to gcc-4_4-branch and gcc-4_3-branch as well? They both have r128098. Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-13 19:18 ` Jack Howarth @ 2009-11-15 23:02 ` Bryce McKinlay 2009-11-16 14:22 ` Jack Howarth 2009-11-16 15:12 ` Jack Howarth 0 siblings, 2 replies; 61+ messages in thread From: Bryce McKinlay @ 2009-11-15 23:02 UTC (permalink / raw) To: Jack Howarth; +Cc: Eric Botcazou, java On Fri, Nov 13, 2009 at 7:17 PM, Jack Howarth <howarth@bromo.med.uc.edu> wrote: >> Index: exception.cc >> =================================================================== >> --- exception.cc (revision 154059) >> +++ exception.cc (working copy) >> @@ -328,7 +328,7 @@ PERSONALITY_FUNCTION (int version, >> #ifdef HAVE_GETIPINFO >> ip = _Unwind_GetIPInfo (context, &ip_before_insn); >> #else >> - ip = _Unwind_GetIP (context) - 1; >> + ip = _Unwind_GetIP (context); >> #endif >> if (! ip_before_insn) >> --ip; > > > Shouldn't this fix also get backported to gcc-4_4-branch and > gcc-4_3-branch as well? They both have r128098. Jack, can you confirm that this actually fixes the problem you are seeing on Darwin? r128098 dates from 2007 - it's hard to believe that nobody has had a working GCJ on Darwin since then! Bryce ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-15 23:02 ` Bryce McKinlay @ 2009-11-16 14:22 ` Jack Howarth 2009-11-16 15:12 ` Jack Howarth 1 sibling, 0 replies; 61+ messages in thread From: Jack Howarth @ 2009-11-16 14:22 UTC (permalink / raw) To: Bryce McKinlay; +Cc: Eric Botcazou, java On Sun, Nov 15, 2009 at 11:01:22PM +0000, Bryce McKinlay wrote: > On Fri, Nov 13, 2009@7:17 PM, Jack Howarth <howarth@bromo.med.uc.edu> wrote: > > >> Index: exception.cc > >> =================================================================== > >> --- exception.cc (revision 154059) > >> +++ exception.cc (working copy) > >> @@ -328,7 +328,7 @@ PERSONALITY_FUNCTION (int version, > >> #ifdef HAVE_GETIPINFO > >> ip = _Unwind_GetIPInfo (context, &ip_before_insn); > >> #else > >> - ip = _Unwind_GetIP (context) - 1; > >> + ip = _Unwind_GetIP (context); > >> #endif > >> if (! ip_before_insn) > >> --ip; > > > > > > Shouldn't this fix also get backported to gcc-4_4-branch and > > gcc-4_3-branch as well? They both have r128098. > > Jack, can you confirm that this actually fixes the problem you are > seeing on Darwin? r128098 dates from 2007 - it's hard to believe that > nobody has had a working GCJ on Darwin since then! > > Bryce Bryce Unfortunately, r154159 didn't eliminate the crashes on x86_64-apple-darwin9 or x86_64-apple-darwin10 when compiling java code with gcj on either a Core2Duo or Xeon. Oddly... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3 fixes the issue for Andreas Tobler. I am wondering if this is really just tending the problem to go latent under certain conditions though. Also, the Makefile.in and Makefile.am still seem a bit odd to me... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c10 Using variables before they are actually assigned in Makefiles can't be right. I wonder if the same issues exist elsewhere in the libjava build infrastructure. Jack ps I still ought to test the patch in comment 10 under x86_64-apple-darwin9 (as I only tested with x86_64-apple-darwin10). The darwin10 build has the additional complexity that the FSF libgcc isn't ever really used since Apple has subsumed libgcc into libSystem and favors those symbols over any in libgcc. So the unwinder in libSystem is always used under darwin10 regardless of which libgcc is linked in. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-15 23:02 ` Bryce McKinlay 2009-11-16 14:22 ` Jack Howarth @ 2009-11-16 15:12 ` Jack Howarth 2009-11-16 15:17 ` Andrew Haley 1 sibling, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-11-16 15:12 UTC (permalink / raw) To: Bryce McKinlay; +Cc: Eric Botcazou, java I should also add that my results from testing the various i386 and x86_64 fink gcc44 and gcc45 packages under darwin9 and darwin10 are confusing. I find for gcj compiling java (but not class) files... i386-darwin9 x86_64-darwin9 i386-darwin10 x86_darwin10 gcc 4.4.2 works aborts aborts aborts gcc 4.5 aborts aborts aborts aborts I have a backport of the darwin10 patches from gcc 4.4 that I can add to the current gcc 4.3 branch and try that but my gut instinct is that at best we will only find some revision where the latent problem is triggered but not indicating the exact origin of the problem. Jack ps It might still be a good first step to make the Makefiles coherent (which they don't seem to be at the moment) with regard to the ecjx linkage flags. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-16 15:12 ` Jack Howarth @ 2009-11-16 15:17 ` Andrew Haley 2009-11-16 15:34 ` Jack Howarth 0 siblings, 1 reply; 61+ messages in thread From: Andrew Haley @ 2009-11-16 15:17 UTC (permalink / raw) To: java Jack Howarth wrote: > I should also add that my results from testing the > various i386 and x86_64 fink gcc44 and gcc45 packages > under darwin9 and darwin10 are confusing. I find for > gcj compiling java (but not class) files... > > i386-darwin9 x86_64-darwin9 i386-darwin10 x86_darwin10 > gcc 4.4.2 works aborts aborts aborts > gcc 4.5 aborts aborts aborts aborts > > I have a backport of the darwin10 patches from gcc 4.4 > that I can add to the current gcc 4.3 branch and try that > but my gut instinct is that at best we will only find some > revision where the latent problem is triggered but not > indicating the exact origin of the problem. > Jack > ps It might still be a good first step to make the Makefiles > coherent (which they don't seem to be at the moment) with > regard to the ecjx linkage flags. The first step surely would be to have a look and see why ecj1 is aborting. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-16 15:17 ` Andrew Haley @ 2009-11-16 15:34 ` Jack Howarth 2009-11-16 16:59 ` Andrew Haley 0 siblings, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-11-16 15:34 UTC (permalink / raw) To: Andrew Haley; +Cc: java On Mon, Nov 16, 2009 at 03:16:07PM +0000, Andrew Haley wrote: > Jack Howarth wrote: > > I should also add that my results from testing the > > various i386 and x86_64 fink gcc44 and gcc45 packages > > under darwin9 and darwin10 are confusing. I find for > > gcj compiling java (but not class) files... > > > > i386-darwin9 x86_64-darwin9 i386-darwin10 x86_darwin10 > > gcc 4.4.2 works aborts aborts aborts > > gcc 4.5 aborts aborts aborts aborts > > > > I have a backport of the darwin10 patches from gcc 4.4 > > that I can add to the current gcc 4.3 branch and try that > > but my gut instinct is that at best we will only find some > > revision where the latent problem is triggered but not > > indicating the exact origin of the problem. > > Jack > > ps It might still be a good first step to make the Makefiles > > coherent (which they don't seem to be at the moment) with > > regard to the ecjx linkage flags. > > The first step surely would be to have a look and see why ecj1 is > aborting. > > Andrew. Andrew, I'll double check with my patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c10 but originally ecj1 was failing as shown in the backtrace of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c1. Looking at the output from gdb in comment 1, I notice that patch to ecj.jar is nowhere shown. This isn't surprising since the current Makefile.in/am use ecjx_LDFLAGS before it is even assigned. I wonder if we shouldn't work through all of these on the off chance that this is the accumulation of a number of different build errors like that. Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-16 15:34 ` Jack Howarth @ 2009-11-16 16:59 ` Andrew Haley 2009-11-16 18:07 ` Jack Howarth 0 siblings, 1 reply; 61+ messages in thread From: Andrew Haley @ 2009-11-16 16:59 UTC (permalink / raw) To: Jack Howarth; +Cc: java Jack Howarth wrote: > On Mon, Nov 16, 2009 at 03:16:07PM +0000, Andrew Haley wrote: >> Jack Howarth wrote: >>> I should also add that my results from testing the >>> various i386 and x86_64 fink gcc44 and gcc45 packages >>> under darwin9 and darwin10 are confusing. I find for >>> gcj compiling java (but not class) files... >>> >>> i386-darwin9 x86_64-darwin9 i386-darwin10 x86_darwin10 >>> gcc 4.4.2 works aborts aborts aborts >>> gcc 4.5 aborts aborts aborts aborts >>> >>> I have a backport of the darwin10 patches from gcc 4.4 >>> that I can add to the current gcc 4.3 branch and try that >>> but my gut instinct is that at best we will only find some >>> revision where the latent problem is triggered but not >>> indicating the exact origin of the problem. >>> Jack >>> ps It might still be a good first step to make the Makefiles >>> coherent (which they don't seem to be at the moment) with >>> regard to the ecjx linkage flags. >> The first step surely would be to have a look and see why ecj1 is >> aborting. > I'll double check with my patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c10 > but originally ecj1 was failing as shown in the backtrace of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c1. Here: /* If code == _URC_END_OF_STACK, then we reached top of stack without finding a handler for the exception. Since each thread is run in a try/catch, this oughtn't happen. If code is something else, we encountered some sort of heinous lossage from which we could not recover. As is the way of such things, almost certainly we will have crashed before now, rather than actually being able to diagnose the problem. */ abort(); In other words, the stack unwinder has failed. I can't see any alternative to stepping through the unwinder to find out why. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-16 16:59 ` Andrew Haley @ 2009-11-16 18:07 ` Jack Howarth 2009-11-16 19:10 ` Andrew Haley 0 siblings, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-11-16 18:07 UTC (permalink / raw) To: Andrew Haley; +Cc: java On Mon, Nov 16, 2009 at 04:58:10PM +0000, Andrew Haley wrote: > Jack Howarth wrote: > > On Mon, Nov 16, 2009@03:16:07PM +0000, Andrew Haley wrote: > >> Jack Howarth wrote: > >>> I should also add that my results from testing the > >>> various i386 and x86_64 fink gcc44 and gcc45 packages > >>> under darwin9 and darwin10 are confusing. I find for > >>> gcj compiling java (but not class) files... > >>> > >>> i386-darwin9 x86_64-darwin9 i386-darwin10 x86_darwin10 > >>> gcc 4.4.2 works aborts aborts aborts > >>> gcc 4.5 aborts aborts aborts aborts > >>> > >>> I have a backport of the darwin10 patches from gcc 4.4 > >>> that I can add to the current gcc 4.3 branch and try that > >>> but my gut instinct is that@best we will only find some > >>> revision where the latent problem is triggered but not > >>> indicating the exact origin of the problem. > >>> Jack > >>> ps It might still be a good first step to make the Makefiles > >>> coherent (which they don't seem to be@the moment) with > >>> regard to the ecjx linkage flags. > >> The first step surely would be to have a look and see why ecj1 is > >> aborting. > > > I'll double check with my patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c10 > > but originally ecj1 was failing as shown in the backtrace of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c1. > > Here: > > /* If code == _URC_END_OF_STACK, then we reached top of stack without > finding a handler for the exception. Since each thread is run in > a try/catch, this oughtn't happen. If code is something else, we > encountered some sort of heinous lossage from which we could not > recover. As is the way of such things, almost certainly we will have > crashed before now, rather than actually being able to diagnose the > problem. */ > abort(); > > In other words, the stack unwinder has failed. I can't see any alternative > to stepping through the unwinder to find out why. > > Andrew. Andrew, Can you walk me through the process of stepping through the unwinder? Is there a good breakpoint to set so that the process of stepping through the unwinder isn't so painful. I think we should start with darwin9 since it will be using the FSF libgcc's unwinder. Thanks in advance for any advice. Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-16 18:07 ` Jack Howarth @ 2009-11-16 19:10 ` Andrew Haley 2009-11-16 19:48 ` Jack Howarth 2009-11-17 0:48 ` Jack Howarth 0 siblings, 2 replies; 61+ messages in thread From: Andrew Haley @ 2009-11-16 19:10 UTC (permalink / raw) To: Jack Howarth; +Cc: java Jack Howarth wrote: > On Mon, Nov 16, 2009 at 04:58:10PM +0000, Andrew Haley wrote: >> Jack Howarth wrote: >>> On Mon, Nov 16, 2009@03:16:07PM +0000, Andrew Haley wrote: >> Here: >> >> /* If code == _URC_END_OF_STACK, then we reached top of stack without >> finding a handler for the exception. Since each thread is run in >> a try/catch, this oughtn't happen. If code is something else, we >> encountered some sort of heinous lossage from which we could not >> recover. As is the way of such things, almost certainly we will have >> crashed before now, rather than actually being able to diagnose the >> problem. */ >> abort(); >> >> In other words, the stack unwinder has failed. I can't see any alternative >> to stepping through the unwinder to find out why. > Can you walk me through the process of stepping through the unwinder? > Is there a good breakpoint to set so that the process of stepping through > the unwinder isn't so painful. I think we should start with darwin9 since > it will be using the FSF libgcc's unwinder. There's another unwinder? Gosh. Set a bp on '_Jv_Throw' and step through. You'll need to compile libgcc with -O0 or you'll go insane. The unwinder is quite complex, and it takes a fair while to understand it. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-16 19:10 ` Andrew Haley @ 2009-11-16 19:48 ` Jack Howarth 2009-11-17 0:48 ` Jack Howarth 1 sibling, 0 replies; 61+ messages in thread From: Jack Howarth @ 2009-11-16 19:48 UTC (permalink / raw) To: Andrew Haley; +Cc: java On Mon, Nov 16, 2009 at 07:08:49PM +0000, Andrew Haley wrote: > > There's another unwinder? Gosh. > Andrew, It really shouldn't be a shock since with Apple's trajectory to migrate to clang, it becomes more sensible to have one system wide unwinder etc in libSystem. Basically from darwin10 onward, Apple will effectively be using an unwinder derived from gcc 4.2.1. http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html This gcj bug however seems to impact darwin9 as well which will use the FSF libgcc so the problem doesn't seem to be specific to Apple's unwinder in libSystem in darwin10. Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-16 19:10 ` Andrew Haley 2009-11-16 19:48 ` Jack Howarth @ 2009-11-17 0:48 ` Jack Howarth 2009-11-17 10:59 ` Andrew Haley 1 sibling, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-11-17 0:48 UTC (permalink / raw) To: Andrew Haley; +Cc: java On Mon, Nov 16, 2009 at 07:08:49PM +0000, Andrew Haley wrote: > > There's another unwinder? Gosh. > > Set a bp on '_Jv_Throw' and step through. You'll need to compile libgcc > with -O0 or you'll go insane. The unwinder is quite complex, and it takes > a fair while to understand it. > > Andrew. Andrew, I have added an unwinder_walk.txt attachment to PR41991. It is a walk from the _Jv_Throw breakpoint for ecj1 compiling the testme.java test code with a libgcc compiled with -O0 installed. This is with current gcc trunk using the patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3 compiled on x86_64-apple-darwin9.8.0 to make sure that the FSF libgcc is used. Hopefully a fix can be found in the libjava code that calls the unwinder as fixing this within the unwinder won't help us with darwin10 or later. Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-17 0:48 ` Jack Howarth @ 2009-11-17 10:59 ` Andrew Haley 2009-11-17 14:05 ` Jack Howarth 0 siblings, 1 reply; 61+ messages in thread From: Andrew Haley @ 2009-11-17 10:59 UTC (permalink / raw) To: Jack Howarth; +Cc: java Jack Howarth wrote: > On Mon, Nov 16, 2009 at 07:08:49PM +0000, Andrew Haley wrote: >> There's another unwinder? Gosh. >> >> Set a bp on '_Jv_Throw' and step through. You'll need to compile libgcc >> with -O0 or you'll go insane. The unwinder is quite complex, and it takes >> a fair while to understand it. > I have added an unwinder_walk.txt attachment to PR41991. It is a walk > from the _Jv_Throw breakpoint for ecj1 compiling the testme.java test code > with a libgcc compiled with -O0 installed. This is with current gcc trunk > using the patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3 > compiled on x86_64-apple-darwin9.8.0 to make sure that the FSF libgcc is > used. Hopefully a fix can be found in the libjava code that calls the > unwinder as fixing this within the unwinder won't help us with darwin10 > or later. There's probably nothing wrong with the libjava code that calls the unwinder: after all, it works everywhere else. I'm betting this is bad unwind info. Anyway, at least this is a start. It tells us that the stack is walked but no landing pad is found. We don't know why. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-17 10:59 ` Andrew Haley @ 2009-11-17 14:05 ` Jack Howarth 2009-11-17 14:56 ` Andrew Haley 0 siblings, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-11-17 14:05 UTC (permalink / raw) To: Andrew Haley; +Cc: java On Tue, Nov 17, 2009 at 10:58:00AM +0000, Andrew Haley wrote: > Jack Howarth wrote: > > On Mon, Nov 16, 2009 at 07:08:49PM +0000, Andrew Haley wrote: > >> There's another unwinder? Gosh. > >> > >> Set a bp on '_Jv_Throw' and step through. You'll need to compile libgcc > >> with -O0 or you'll go insane. The unwinder is quite complex, and it takes > >> a fair while to understand it. > > > I have added an unwinder_walk.txt attachment to PR41991. It is a walk > > from the _Jv_Throw breakpoint for ecj1 compiling the testme.java test code > > with a libgcc compiled with -O0 installed. This is with current gcc trunk > > using the patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3 > > compiled on x86_64-apple-darwin9.8.0 to make sure that the FSF libgcc is > > used. Hopefully a fix can be found in the libjava code that calls the > > unwinder as fixing this within the unwinder won't help us with darwin10 > > or later. > > There's probably nothing wrong with the libjava code that calls the > unwinder: after all, it works everywhere else. I'm betting this is > bad unwind info. > > Anyway, at least this is a start. It tells us that the stack is > walked but no landing pad is found. We don't know why. > > Andrew. Andrew, In the unwinder walk, are there any particular places where I could get additional debug information in gdb that would be helpful to diagnose this issue? Also, what do you make of the fact that the generated libjava Makefile uses ecjx_LDFLAGS before it is actually assigned... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c10 Could this sort of problem be caused by a build issue from improper Makefiles? Andreas suppressed the crash on his machine using the change in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3 but that is insufficient to fix it on either my MacBook Pro or MacPro under either darwin9 or darwin10 (which is odd). Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-17 14:05 ` Jack Howarth @ 2009-11-17 14:56 ` Andrew Haley 2009-11-17 16:18 ` Jack Howarth 2009-11-17 17:07 ` Jack Howarth 0 siblings, 2 replies; 61+ messages in thread From: Andrew Haley @ 2009-11-17 14:56 UTC (permalink / raw) To: Jack Howarth; +Cc: java Jack Howarth wrote: > On Tue, Nov 17, 2009 at 10:58:00AM +0000, Andrew Haley wrote: >> Jack Howarth wrote: >>> On Mon, Nov 16, 2009 at 07:08:49PM +0000, Andrew Haley wrote: >>>> There's another unwinder? Gosh. >>>> >>>> Set a bp on '_Jv_Throw' and step through. You'll need to compile libgcc >>>> with -O0 or you'll go insane. The unwinder is quite complex, and it takes >>>> a fair while to understand it. >>> I have added an unwinder_walk.txt attachment to PR41991. It is a walk >>> from the _Jv_Throw breakpoint for ecj1 compiling the testme.java test code >>> with a libgcc compiled with -O0 installed. This is with current gcc trunk >>> using the patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3 >>> compiled on x86_64-apple-darwin9.8.0 to make sure that the FSF libgcc is >>> used. Hopefully a fix can be found in the libjava code that calls the >>> unwinder as fixing this within the unwinder won't help us with darwin10 >>> or later. >> There's probably nothing wrong with the libjava code that calls the >> unwinder: after all, it works everywhere else. I'm betting this is >> bad unwind info. >> >> Anyway, at least this is a start. It tells us that the stack is >> walked but no landing pad is found. We don't know why. > In the unwinder walk, are there any particular places where I could > get additional debug information in gdb that would be helpful to diagnose this > issue? Sure. The trace you provided is very incomplete, and in particular I can't see any stepping into _Unwind_RaiseException. The main loop looks like this: while (1) { _Unwind_FrameState fs; /* Set up fs to describe the FDE for the caller of cur_context. The first time through the loop, that means __cxa_throw. */ code = uw_frame_state_for (&cur_context, &fs); if (code == _URC_END_OF_STACK) /* Hit end of stack with no handler found. */ return _URC_END_OF_STACK; if (code != _URC_NO_REASON) /* Some error encountered. Usually the unwinder doesn't diagnose these and merely crashes. */ return _URC_FATAL_PHASE1_ERROR; /* Unwind successful. Run the personality routine, if any. */ if (fs.personality) { code = (*fs.personality) (1, _UA_SEARCH_PHASE, exc->exception_class, exc, &cur_context); if (code == _URC_HANDLER_FOUND) break; else if (code != _URC_CONTINUE_UNWIND) return _URC_FATAL_PHASE1_ERROR; } /* Update cur_context to describe the same frame as fs. */ uw_update_context (&cur_context, &fs); } So, for each stack frame, we read the unwinder data and then call the appropriate personality routine (in this case, in libgcj.) cur_context.ra is the program counter for the current stack frame. So, (gdb) x cur_context.ra 0x7ffff659ca7f <_ZN4java3net14URLClassLoader9findClassEJPNS_4lang5ClassEPNS2_6StringE+255>: 0x41c58949 tells you which frame is being inspected. So, you can see where the exception handler should be, and you can step into the personality routine to see why it's not recognized. > Also, what do you make of the fact that the generated libjava Makefile > uses ecjx_LDFLAGS before it is actually assigned... > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c10 That's probably not right. > Could this sort of problem be caused by a build issue from improper Makefiles? Sorry, I hate to speculate. I simply don't know. > Andreas suppressed the crash on his machine using the change in > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3 but that is insufficient > to fix it on either my MacBook Pro or MacPro under either darwin9 or darwin10 > (which is odd). It may be a completely different problem. He's seeing a SEGV, you're not. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-17 14:56 ` Andrew Haley @ 2009-11-17 16:18 ` Jack Howarth 2009-11-17 16:22 ` Andrew Haley 2009-11-17 17:07 ` Jack Howarth 1 sibling, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-11-17 16:18 UTC (permalink / raw) To: Andrew Haley; +Cc: java On Tue, Nov 17, 2009 at 02:54:53PM +0000, Andrew Haley wrote: > Jack Howarth wrote: > > > In the unwinder walk, are there any particular places where I could > > get additional debug information in gdb that would be helpful to diagnose this > > issue? > > Sure. The trace you provided is very incomplete, and in particular > I can't see any stepping into _Unwind_RaiseException. > > The main loop looks like this: > > while (1) > { > _Unwind_FrameState fs; > > /* Set up fs to describe the FDE for the caller of cur_context. The > first time through the loop, that means __cxa_throw. */ > code = uw_frame_state_for (&cur_context, &fs); > > if (code == _URC_END_OF_STACK) > /* Hit end of stack with no handler found. */ > return _URC_END_OF_STACK; > > if (code != _URC_NO_REASON) > /* Some error encountered. Usually the unwinder doesn't > diagnose these and merely crashes. */ > return _URC_FATAL_PHASE1_ERROR; > > /* Unwind successful. Run the personality routine, if any. */ > if (fs.personality) > { > code = (*fs.personality) (1, _UA_SEARCH_PHASE, exc->exception_class, > exc, &cur_context); > if (code == _URC_HANDLER_FOUND) > break; > else if (code != _URC_CONTINUE_UNWIND) > return _URC_FATAL_PHASE1_ERROR; > } > > /* Update cur_context to describe the same frame as fs. */ > uw_update_context (&cur_context, &fs); > } > > So, for each stack frame, we read the unwinder data and then call the > appropriate personality routine (in this case, in libgcj.) > > cur_context.ra is the program counter for the current stack frame. > So, > > (gdb) x cur_context.ra > 0x7ffff659ca7f <_ZN4java3net14URLClassLoader9findClassEJPNS_4lang5ClassEPNS2_6StringE+255>: 0x41c58949 > > tells you which frame is being inspected. So, you can see where the > exception handler should be, and you can step into the personality > routine to see why it's not recognized. > Andrew, At which points should I be sampling with 'x cur_context.ra'? Is there a particular breakpoint that would be useful to set in order to do this? Also, would it help if I recompiled libgcj with -O0 as well? Jack > > Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-17 16:18 ` Jack Howarth @ 2009-11-17 16:22 ` Andrew Haley 0 siblings, 0 replies; 61+ messages in thread From: Andrew Haley @ 2009-11-17 16:22 UTC (permalink / raw) To: Jack Howarth; +Cc: java Jack Howarth wrote: > On Tue, Nov 17, 2009 at 02:54:53PM +0000, Andrew Haley wrote: >> Jack Howarth wrote: >> >>> In the unwinder walk, are there any particular places where I could >>> get additional debug information in gdb that would be helpful to diagnose this >>> issue? >> Sure. The trace you provided is very incomplete, and in particular >> I can't see any stepping into _Unwind_RaiseException. >> >> The main loop looks like this: >> >> while (1) >> { >> _Unwind_FrameState fs; >> >> /* Set up fs to describe the FDE for the caller of cur_context. The >> first time through the loop, that means __cxa_throw. */ >> code = uw_frame_state_for (&cur_context, &fs); >> >> if (code == _URC_END_OF_STACK) >> /* Hit end of stack with no handler found. */ >> return _URC_END_OF_STACK; >> >> if (code != _URC_NO_REASON) >> /* Some error encountered. Usually the unwinder doesn't >> diagnose these and merely crashes. */ >> return _URC_FATAL_PHASE1_ERROR; >> >> /* Unwind successful. Run the personality routine, if any. */ >> if (fs.personality) >> { >> code = (*fs.personality) (1, _UA_SEARCH_PHASE, exc->exception_class, >> exc, &cur_context); >> if (code == _URC_HANDLER_FOUND) >> break; >> else if (code != _URC_CONTINUE_UNWIND) >> return _URC_FATAL_PHASE1_ERROR; >> } >> >> /* Update cur_context to describe the same frame as fs. */ >> uw_update_context (&cur_context, &fs); >> } >> >> So, for each stack frame, we read the unwinder data and then call the >> appropriate personality routine (in this case, in libgcj.) >> >> cur_context.ra is the program counter for the current stack frame. >> So, >> >> (gdb) x cur_context.ra >> 0x7ffff659ca7f <_ZN4java3net14URLClassLoader9findClassEJPNS_4lang5ClassEPNS2_6StringE+255>: 0x41c58949 >> >> tells you which frame is being inspected. So, you can see where the >> exception handler should be, and you can step into the personality >> routine to see why it's not recognized. > At which points should I be sampling with 'x cur_context.ra'? Is there a particular > breakpoint that would be useful to set in order to do this? Before and sfter uw_frame_state_for. Then step into the personality routine. > Also, would it help if I > recompiled libgcj with -O0 as well? Probably. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-17 14:56 ` Andrew Haley 2009-11-17 16:18 ` Jack Howarth @ 2009-11-17 17:07 ` Jack Howarth 2009-11-17 17:14 ` Andrew Haley 1 sibling, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-11-17 17:07 UTC (permalink / raw) To: Andrew Haley; +Cc: java On Tue, Nov 17, 2009 at 02:54:53PM +0000, Andrew Haley wrote: > Jack Howarth wrote: > > On Tue, Nov 17, 2009 at 10:58:00AM +0000, Andrew Haley wrote: > >> Jack Howarth wrote: > >>> On Mon, Nov 16, 2009 at 07:08:49PM +0000, Andrew Haley wrote: > >>>> There's another unwinder? Gosh. > >>>> > >>>> Set a bp on '_Jv_Throw' and step through. You'll need to compile libgcc > >>>> with -O0 or you'll go insane. The unwinder is quite complex, and it takes > >>>> a fair while to understand it. > >>> I have added an unwinder_walk.txt attachment to PR41991. It is a walk > >>> from the _Jv_Throw breakpoint for ecj1 compiling the testme.java test code > >>> with a libgcc compiled with -O0 installed. This is with current gcc trunk > >>> using the patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3 > >>> compiled on x86_64-apple-darwin9.8.0 to make sure that the FSF libgcc is > >>> used. Hopefully a fix can be found in the libjava code that calls the > >>> unwinder as fixing this within the unwinder won't help us with darwin10 > >>> or later. > >> There's probably nothing wrong with the libjava code that calls the > >> unwinder: after all, it works everywhere else. I'm betting this is > >> bad unwind info. > >> > >> Anyway, at least this is a start. It tells us that the stack is > >> walked but no landing pad is found. We don't know why. > > > In the unwinder walk, are there any particular places where I could > > get additional debug information in gdb that would be helpful to diagnose this > > issue? > > Sure. The trace you provided is very incomplete, and in particular > I can't see any stepping into _Unwind_RaiseException. > Andrew, One question about the absence of stepping into _Unwind_RaiseException. Am I doing the walk incorrectly? The steps I used were... 1) gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 2) (gdb) break _Jv_Throw 3) r testme.java -fbootclasspath=./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccnFt6vF.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccrNgp0M.jar 4) (gdb) s 5) repeatedly hit return to continue stepping through the code Is there something wrong with that approach which would have kept me from walking into Unwind_RaiseException? I assume that gcc trunk's debug code is still compatible with Apple's gdb. If not, I do have a build of gdb 7.0 on Intel darwin that I can use instead. Thanks in advance for any hints on this issue. Jack ps I do notice that gdb can't find the object files from /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax so it might have problems with debugging within libgcj. If I recall correctly this .lax issue is known... http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html > The main loop looks like this: > > while (1) > { > _Unwind_FrameState fs; > > /* Set up fs to describe the FDE for the caller of cur_context. The > first time through the loop, that means __cxa_throw. */ > code = uw_frame_state_for (&cur_context, &fs); > > if (code == _URC_END_OF_STACK) > /* Hit end of stack with no handler found. */ > return _URC_END_OF_STACK; > > if (code != _URC_NO_REASON) > /* Some error encountered. Usually the unwinder doesn't > diagnose these and merely crashes. */ > return _URC_FATAL_PHASE1_ERROR; > > /* Unwind successful. Run the personality routine, if any. */ > if (fs.personality) > { > code = (*fs.personality) (1, _UA_SEARCH_PHASE, exc->exception_class, > exc, &cur_context); > if (code == _URC_HANDLER_FOUND) > break; > else if (code != _URC_CONTINUE_UNWIND) > return _URC_FATAL_PHASE1_ERROR; > } > > /* Update cur_context to describe the same frame as fs. */ > uw_update_context (&cur_context, &fs); > } > > So, for each stack frame, we read the unwinder data and then call the > appropriate personality routine (in this case, in libgcj.) > > cur_context.ra is the program counter for the current stack frame. > So, > > (gdb) x cur_context.ra > 0x7ffff659ca7f <_ZN4java3net14URLClassLoader9findClassEJPNS_4lang5ClassEPNS2_6StringE+255>: 0x41c58949 > > tells you which frame is being inspected. So, you can see where the > exception handler should be, and you can step into the personality > routine to see why it's not recognized. > > > Also, what do you make of the fact that the generated libjava Makefile > > uses ecjx_LDFLAGS before it is actually assigned... > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c10 > > That's probably not right. > > > Could this sort of problem be caused by a build issue from improper Makefiles? > > Sorry, I hate to speculate. I simply don't know. > > > Andreas suppressed the crash on his machine using the change in > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3 but that is insufficient > > to fix it on either my MacBook Pro or MacPro under either darwin9 or darwin10 > > (which is odd). > > It may be a completely different problem. He's seeing a SEGV, you're not. > > Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-17 17:07 ` Jack Howarth @ 2009-11-17 17:14 ` Andrew Haley 2009-11-17 17:38 ` Jack Howarth 0 siblings, 1 reply; 61+ messages in thread From: Andrew Haley @ 2009-11-17 17:14 UTC (permalink / raw) To: Jack Howarth; +Cc: java Jack Howarth wrote: > On Tue, Nov 17, 2009 at 02:54:53PM +0000, Andrew Haley wrote: >> Jack Howarth wrote: >>> On Tue, Nov 17, 2009 at 10:58:00AM +0000, Andrew Haley wrote: >>>> Jack Howarth wrote: >>>>> On Mon, Nov 16, 2009 at 07:08:49PM +0000, Andrew Haley wrote: >>>>>> There's another unwinder? Gosh. >>>>>> >>>>>> Set a bp on '_Jv_Throw' and step through. You'll need to compile libgcc >>>>>> with -O0 or you'll go insane. The unwinder is quite complex, and it takes >>>>>> a fair while to understand it. >>>>> I have added an unwinder_walk.txt attachment to PR41991. It is a walk >>>>> from the _Jv_Throw breakpoint for ecj1 compiling the testme.java test code >>>>> with a libgcc compiled with -O0 installed. This is with current gcc trunk >>>>> using the patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3 >>>>> compiled on x86_64-apple-darwin9.8.0 to make sure that the FSF libgcc is >>>>> used. Hopefully a fix can be found in the libjava code that calls the >>>>> unwinder as fixing this within the unwinder won't help us with darwin10 >>>>> or later. >>>> There's probably nothing wrong with the libjava code that calls the >>>> unwinder: after all, it works everywhere else. I'm betting this is >>>> bad unwind info. >>>> >>>> Anyway, at least this is a start. It tells us that the stack is >>>> walked but no landing pad is found. We don't know why. >>> In the unwinder walk, are there any particular places where I could >>> get additional debug information in gdb that would be helpful to diagnose this >>> issue? >> Sure. The trace you provided is very incomplete, and in particular >> I can't see any stepping into _Unwind_RaiseException. >> > Andrew, > One question about the absence of stepping into _Unwind_RaiseException. > Am I doing the walk incorrectly? The steps I used were... > > 1) gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 > 2) (gdb) break _Jv_Throw > 3) r testme.java -fbootclasspath=./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccnFt6vF.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccrNgp0M.jar > 4) (gdb) s > 5) repeatedly hit return to continue stepping through the code > > Is there something wrong with that approach which would have kept me > from walking into Unwind_RaiseException? Sometimes it doesn't work, so you have to be inventive. Try setting a breakpoint on Unwind_RaiseException, or step a single instruction at a time when you get to a call. > I assume that gcc trunk's > debug code is still compatible with Apple's gdb. If not, I do have > a build of gdb 7.0 on Intel darwin that I can use instead. Thanks > in advance for any hints on this issue. > Jack > ps I do notice that gdb can't find the object files from /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax so it might have problems with debugging within libgcj. If I recall correctly this .lax issue is known... > > http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html Ouch. That will cause gdb breakage, for sure. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-17 17:14 ` Andrew Haley @ 2009-11-17 17:38 ` Jack Howarth 2009-11-27 10:37 ` borlum 0 siblings, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-11-17 17:38 UTC (permalink / raw) To: Andrew Haley; +Cc: java On Tue, Nov 17, 2009 at 05:13:31PM +0000, Andrew Haley wrote: > > Sometimes it doesn't work, so you have to be inventive. Try > setting a breakpoint on Unwind_RaiseException, or step a single > instruction at a time when you get to a call. > > > I assume that gcc trunk's > > debug code is still compatible with Apple's gdb. If not, I do have > > a build of gdb 7.0 on Intel darwin that I can use instead. Thanks > > in advance for any hints on this issue. > > Jack > > ps I do notice that gdb can't find the object files from /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax so it might have problems with debugging within libgcj. If I recall correctly this .lax issue is known... > > > > http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html > > Ouch. That will cause gdb breakage, for sure. Andrew, Re-reading Peter's comments in http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html, I think I may be able to work around the lax issue with the proper setting of LD_LIBRARY to point to the shared library in the build directory. I'll see if I can puzzle that one out. Jack > > Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-17 17:38 ` Jack Howarth @ 2009-11-27 10:37 ` borlum 2009-11-27 10:40 ` Andrew Haley 0 siblings, 1 reply; 61+ messages in thread From: borlum @ 2009-11-27 10:37 UTC (permalink / raw) To: java Jack Howarth-3 wrote: > > On Tue, Nov 17, 2009 at 05:13:31PM +0000, Andrew Haley wrote: >> >> Sometimes it doesn't work, so you have to be inventive. Try >> setting a breakpoint on Unwind_RaiseException, or step a single >> instruction at a time when you get to a call. >> >> > I assume that gcc trunk's >> > debug code is still compatible with Apple's gdb. If not, I do have >> > a build of gdb 7.0 on Intel darwin that I can use instead. Thanks >> > in advance for any hints on this issue. >> > Jack >> > ps I do notice that gdb can't find the object files from >> /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax >> so it might have problems with debugging within libgcj. If I recall >> correctly this .lax issue is known... >> > >> > http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html >> >> Ouch. That will cause gdb breakage, for sure. > > Andrew, > Re-reading Peter's comments in > http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html, I think I > may be able to work around the lax issue with the proper setting of > LD_LIBRARY to point to > the shared library in the build directory. I'll see if I can puzzle that > one out. > Jack >> >> Andrew. > > Hey Andrew, Did you ever solve the problem? I'm having the same rather frustrating error. Thomas -- View this message in context: http://old.nabble.com/-patch--Fix-oddity-in-personality-routine-tp26340585p26540588.html Sent from the gcc - java mailing list archive at Nabble.com. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-27 10:37 ` borlum @ 2009-11-27 10:40 ` Andrew Haley 2009-11-27 10:52 ` borlum 2009-11-27 21:51 ` Jack Howarth 0 siblings, 2 replies; 61+ messages in thread From: Andrew Haley @ 2009-11-27 10:40 UTC (permalink / raw) To: borlum; +Cc: java borlum wrote: > > > Jack Howarth-3 wrote: >> On Tue, Nov 17, 2009 at 05:13:31PM +0000, Andrew Haley wrote: >>> Sometimes it doesn't work, so you have to be inventive. Try >>> setting a breakpoint on Unwind_RaiseException, or step a single >>> instruction at a time when you get to a call. >>> >>>> I assume that gcc trunk's >>>> debug code is still compatible with Apple's gdb. If not, I do have >>>> a build of gdb 7.0 on Intel darwin that I can use instead. Thanks >>>> in advance for any hints on this issue. >>>> Jack >>>> ps I do notice that gdb can't find the object files from >>> /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax >>> so it might have problems with debugging within libgcj. If I recall >>> correctly this .lax issue is known... >>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html >>> Ouch. That will cause gdb breakage, for sure. >> Andrew, >> Re-reading Peter's comments in >> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html, I think I >> may be able to work around the lax issue with the proper setting of >> LD_LIBRARY to point to >> the shared library in the build directory. I'll see if I can puzzle that >> one out. >> Jack >>> Andrew. >> > > Hey Andrew, > > Did you ever solve the problem? I'm having the same rather frustrating > error. Not me, no. I don't have a Darwin system. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-27 10:40 ` Andrew Haley @ 2009-11-27 10:52 ` borlum 2009-11-27 14:20 ` Bryce McKinlay 2009-11-27 21:51 ` Jack Howarth 1 sibling, 1 reply; 61+ messages in thread From: borlum @ 2009-11-27 10:52 UTC (permalink / raw) To: java Andrew Haley wrote: > > Not me, no. I don't have a Darwin system. > > Andrew. > Oh, I guess I wasn't following the thread correctly.. :) I'm afraid I'm too new to the gcc source to fix it myself, I'll keep my fingers crossed and sob quietly by myself in the meantime. Thomas -- View this message in context: http://old.nabble.com/-patch--Fix-oddity-in-personality-routine-tp26340585p26540778.html Sent from the gcc - java mailing list archive at Nabble.com. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-27 10:52 ` borlum @ 2009-11-27 14:20 ` Bryce McKinlay 2009-11-27 16:29 ` Jack Howarth 0 siblings, 1 reply; 61+ messages in thread From: Bryce McKinlay @ 2009-11-27 14:20 UTC (permalink / raw) To: borlum; +Cc: java I did take a quick look at this last week on my Mac and can confirm that there is a problem. A couple of observations: - It seems to effect ecj specifically, other EH tests from the libgcj testsuite seem to work ok. - An ecj built by hand (with "gcj -O0 -g ecj.jar --main=org.eclipse.jdt.internal.compiler.batch.GCCMain") also fails, so I don't think its a build related bug. Unfortunately, neither Apple's gdb nor a freshly build gdb 7.0 seem to work debugging binaries built by gcj head on darwin. gdb 7.0 insists the binary has no debugging info, and Apple gdb gets multiple "could not find partial DIE in cache" internal errors and "Previous frame inner to this frame (gdb could not unwind past this frame)" errors when you try to backtrace. If anyone knows how to get a working debugger for gcj on Darwin then perhaps we can debug this further. Bryce On Fri, Nov 27, 2009 at 10:52 AM, borlum <thomas@borlum.dk> wrote: > > > > Andrew Haley wrote: >> >> Not me, no. I don't have a Darwin system. >> >> Andrew. >> > > Oh, I guess I wasn't following the thread correctly.. :) > > I'm afraid I'm too new to the gcc source to fix it myself, I'll keep my > fingers crossed and sob quietly by myself in the meantime. > > Thomas > > -- > View this message in context: http://old.nabble.com/-patch--Fix-oddity-in-personality-routine-tp26340585p26540778.html > Sent from the gcc - java mailing list archive at Nabble.com. > > ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-27 14:20 ` Bryce McKinlay @ 2009-11-27 16:29 ` Jack Howarth 0 siblings, 0 replies; 61+ messages in thread From: Jack Howarth @ 2009-11-27 16:29 UTC (permalink / raw) To: Bryce McKinlay; +Cc: borlum, java On Fri, Nov 27, 2009 at 02:20:32PM +0000, Bryce McKinlay wrote: > I did take a quick look at this last week on my Mac and can confirm > that there is a problem. > > A couple of observations: > > - It seems to effect ecj specifically, other EH tests from the libgcj > testsuite seem to work ok. > - An ecj built by hand (with "gcj -O0 -g ecj.jar > --main=org.eclipse.jdt.internal.compiler.batch.GCCMain") also fails, > so I don't think its a build related bug. > > Unfortunately, neither Apple's gdb nor a freshly build gdb 7.0 seem to > work debugging binaries built by gcj head on darwin. gdb 7.0 insists > the binary has no debugging info, and Apple gdb gets multiple "could > not find partial DIE in cache" internal errors and "Previous frame > inner to this frame (gdb could not unwind past this frame)" errors > when you try to backtrace. > > If anyone knows how to get a working debugger for gcj on Darwin then > perhaps we can debug this further. > > Bryce > > > On Fri, Nov 27, 2009 at 10:52 AM, borlum <thomas@borlum.dk> wrote: > > > > > > > > Andrew Haley wrote: > >> > >> Not me, no. I don't have a Darwin system. > >> > >> Andrew. > >> > > > > Oh, I guess I wasn't following the thread correctly.. :) > > > > I'm afraid I'm too new to the gcc source to fix it myself, I'll keep my > > fingers crossed and sob quietly by myself in the meantime. > > > > Thomas > > > > -- > > View this message in context: http://old.nabble.com/-patch--Fix-oddity-in-personality-routine-tp26340585p26540778.html > > Sent from the gcc - java mailing list archive at Nabble.com. > > > > It may be helpful to apply the proposed patch to eliminate the problem nulll AT_locations from the dwarf output in FSF gcc trunk... http://gcc.gnu.org/bugzilla/attachment.cgi?id=19160 Currently, because of PR41473, either we are missing dSYM subdirectories in the build or, when dsymutil doesn't actually crash, the resulting debug info is hosed. This issue is fixed with the proposed patch, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473#c85, so that we have proper debug info to walk through now. Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-27 10:40 ` Andrew Haley 2009-11-27 10:52 ` borlum @ 2009-11-27 21:51 ` Jack Howarth 2009-11-28 10:43 ` Andrew Haley 1 sibling, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-11-27 21:51 UTC (permalink / raw) To: Andrew Haley; +Cc: borlum, java On Fri, Nov 27, 2009 at 10:40:17AM +0000, Andrew Haley wrote: > borlum wrote: > > > > > > Jack Howarth-3 wrote: > >> On Tue, Nov 17, 2009 at 05:13:31PM +0000, Andrew Haley wrote: > >>> Sometimes it doesn't work, so you have to be inventive. Try > >>> setting a breakpoint on Unwind_RaiseException, or step a single > >>> instruction at a time when you get to a call. > >>> > >>>> I assume that gcc trunk's > >>>> debug code is still compatible with Apple's gdb. If not, I do have > >>>> a build of gdb 7.0 on Intel darwin that I can use instead. Thanks > >>>> in advance for any hints on this issue. > >>>> Jack > >>>> ps I do notice that gdb can't find the object files from > >>> /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax > >>> so it might have problems with debugging within libgcj. If I recall > >>> correctly this .lax issue is known... > >>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html > >>> Ouch. That will cause gdb breakage, for sure. > >> Andrew, > >> Re-reading Peter's comments in > >> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html, I think I > >> may be able to work around the lax issue with the proper setting of > >> LD_LIBRARY to point to > >> the shared library in the build directory. I'll see if I can puzzle that > >> one out. > >> Jack > >>> Andrew. > >> > > > > Hey Andrew, > > > > Did you ever solve the problem? I'm having the same rather frustrating > > error. > > Not me, no. I don't have a Darwin system. > > Andrew. Andrew, Now that we have a set of patches to fix the breakage in current gcc trunk to dsymutil, I have uploaded a much more complete walk under x86_64-apple-darwin10. I haven't managed to walk into _Unwind_Exception() yet but I do see that the crash occurs on continuing from the 39th instance of the _Unwind_Exception() breakpoint. Is there some way I can get the unwinder data from inside of libgcj itself before the call to _Unwind_Exception()? If the bad unwind information is being generated in libjava wouldn't it be just as easy to see that from outside of libgcc (before the call to _Unwind_Exception()? Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-27 21:51 ` Jack Howarth @ 2009-11-28 10:43 ` Andrew Haley 2009-11-29 17:48 ` Jack Howarth 0 siblings, 1 reply; 61+ messages in thread From: Andrew Haley @ 2009-11-28 10:43 UTC (permalink / raw) To: Jack Howarth; +Cc: borlum, java Jack Howarth wrote: > On Fri, Nov 27, 2009 at 10:40:17AM +0000, Andrew Haley wrote: >> borlum wrote: >>> >>> Jack Howarth-3 wrote: >>>> On Tue, Nov 17, 2009 at 05:13:31PM +0000, Andrew Haley wrote: >>>>> Sometimes it doesn't work, so you have to be inventive. Try >>>>> setting a breakpoint on Unwind_RaiseException, or step a single >>>>> instruction at a time when you get to a call. >>>>> >>>>>> I assume that gcc trunk's >>>>>> debug code is still compatible with Apple's gdb. If not, I do have >>>>>> a build of gdb 7.0 on Intel darwin that I can use instead. Thanks >>>>>> in advance for any hints on this issue. >>>>>> Jack >>>>>> ps I do notice that gdb can't find the object files from >>>>> /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax >>>>> so it might have problems with debugging within libgcj. If I recall >>>>> correctly this .lax issue is known... >>>>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html >>>>> Ouch. That will cause gdb breakage, for sure. >>>> Andrew, >>>> Re-reading Peter's comments in >>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html, I think I >>>> may be able to work around the lax issue with the proper setting of >>>> LD_LIBRARY to point to >>>> the shared library in the build directory. I'll see if I can puzzle that >>>> one out. >>>> Jack >>>>> Andrew. >>> Hey Andrew, >>> >>> Did you ever solve the problem? I'm having the same rather frustrating >>> error. >> Not me, no. I don't have a Darwin system. > Now that we have a set of patches to fix the breakage in current gcc > trunk to dsymutil, I have uploaded a much more complete walk under x86_64-apple-darwin10. > I haven't managed to walk into _Unwind_Exception() yet but I do see that the > crash occurs on continuing from the 39th instance of the _Unwind_Exception() breakpoint. That's probably just the end of the stack. If you do a stack trace in gdb you'll probably find it's something like 39 deep. > Is there some way I can get the unwinder data from inside of libgcj itself before > the call to _Unwind_Exception()? If the bad unwind information is being generated in > libjava wouldn't it be just as easy to see that from outside of libgcc (before the call > to _Unwind_Exception()? You mean decoding the unwinder data by hand? It's not impossible, but it'd be a hell of a job. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-28 10:43 ` Andrew Haley @ 2009-11-29 17:48 ` Jack Howarth 2009-11-29 18:01 ` Andrew Haley 0 siblings, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-11-29 17:48 UTC (permalink / raw) To: Andrew Haley; +Cc: borlum, java On Sat, Nov 28, 2009 at 10:43:26AM +0000, Andrew Haley wrote: > Jack Howarth wrote: > > On Fri, Nov 27, 2009 at 10:40:17AM +0000, Andrew Haley wrote: > >> borlum wrote: > >>> > >>> Jack Howarth-3 wrote: > >>>> On Tue, Nov 17, 2009 at 05:13:31PM +0000, Andrew Haley wrote: > >>>>> Sometimes it doesn't work, so you have to be inventive. Try > >>>>> setting a breakpoint on Unwind_RaiseException, or step a single > >>>>> instruction at a time when you get to a call. > >>>>> > >>>>>> I assume that gcc trunk's > >>>>>> debug code is still compatible with Apple's gdb. If not, I do have > >>>>>> a build of gdb 7.0 on Intel darwin that I can use instead. Thanks > >>>>>> in advance for any hints on this issue. > >>>>>> Jack > >>>>>> ps I do notice that gdb can't find the object files from > >>>>> /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax > >>>>> so it might have problems with debugging within libgcj. If I recall > >>>>> correctly this .lax issue is known... > >>>>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html > >>>>> Ouch. That will cause gdb breakage, for sure. > >>>> Andrew, > >>>> Re-reading Peter's comments in > >>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html, I think I > >>>> may be able to work around the lax issue with the proper setting of > >>>> LD_LIBRARY to point to > >>>> the shared library in the build directory. I'll see if I can puzzle that > >>>> one out. > >>>> Jack > >>>>> Andrew. > >>> Hey Andrew, > >>> > >>> Did you ever solve the problem? I'm having the same rather frustrating > >>> error. > >> Not me, no. I don't have a Darwin system. > > > Now that we have a set of patches to fix the breakage in current gcc > > trunk to dsymutil, I have uploaded a much more complete walk under x86_64-apple-darwin10. > > I haven't managed to walk into _Unwind_Exception() yet but I do see that the > > crash occurs on continuing from the 39th instance of the _Unwind_Exception() breakpoint. > > That's probably just the end of the stack. If you do a stack trace > in gdb you'll probably find it's something like 39 deep. > > > Is there some way I can get the unwinder data from inside of libgcj itself before > > the call to _Unwind_Exception()? If the bad unwind information is being generated in > > libjava wouldn't it be just as easy to see that from outside of libgcc (before the call > > to _Unwind_Exception()? > > You mean decoding the unwinder data by hand? It's not impossible, but > it'd be a hell of a job. > > Andrew. Andrew, I managed to get a build of libgcc at -O0 under darwin9 that I used to walk through the FSF gcc unwinder. The walk is at... http://gcc.gnu.org/bugzilla/attachment.cgi?id=19174 and the list of the frames is at... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c26 Does this clarify the problem at all on intel darwin? Let me know if there is any other particular debug information I can provide. Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-29 17:48 ` Jack Howarth @ 2009-11-29 18:01 ` Andrew Haley 2009-11-29 18:48 ` Jack Howarth 0 siblings, 1 reply; 61+ messages in thread From: Andrew Haley @ 2009-11-29 18:01 UTC (permalink / raw) To: Jack Howarth; +Cc: borlum, java Jack Howarth wrote: > On Sat, Nov 28, 2009 at 10:43:26AM +0000, Andrew Haley wrote: >> Jack Howarth wrote: >>> On Fri, Nov 27, 2009 at 10:40:17AM +0000, Andrew Haley wrote: >>>> borlum wrote: >>>>> Jack Howarth-3 wrote: >>>>>> On Tue, Nov 17, 2009 at 05:13:31PM +0000, Andrew Haley wrote: >>>>>>> Sometimes it doesn't work, so you have to be inventive. Try >>>>>>> setting a breakpoint on Unwind_RaiseException, or step a single >>>>>>> instruction at a time when you get to a call. >>>>>>> >>>>>>>> I assume that gcc trunk's >>>>>>>> debug code is still compatible with Apple's gdb. If not, I do have >>>>>>>> a build of gdb 7.0 on Intel darwin that I can use instead. Thanks >>>>>>>> in advance for any hints on this issue. >>>>>>>> Jack >>>>>>>> ps I do notice that gdb can't find the object files from >>>>>>> /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax >>>>>>> so it might have problems with debugging within libgcj. If I recall >>>>>>> correctly this .lax issue is known... >>>>>>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html >>>>>>> Ouch. That will cause gdb breakage, for sure. >>>>>> Andrew, >>>>>> Re-reading Peter's comments in >>>>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html, I think I >>>>>> may be able to work around the lax issue with the proper setting of >>>>>> LD_LIBRARY to point to >>>>>> the shared library in the build directory. I'll see if I can puzzle that >>>>>> one out. >>>>>> Jack >>>>>>> Andrew. >>>>> Hey Andrew, >>>>> >>>>> Did you ever solve the problem? I'm having the same rather frustrating >>>>> error. >>>> Not me, no. I don't have a Darwin system. >>> Now that we have a set of patches to fix the breakage in current gcc >>> trunk to dsymutil, I have uploaded a much more complete walk under x86_64-apple-darwin10. >>> I haven't managed to walk into _Unwind_Exception() yet but I do see that the >>> crash occurs on continuing from the 39th instance of the _Unwind_Exception() breakpoint. >> That's probably just the end of the stack. If you do a stack trace >> in gdb you'll probably find it's something like 39 deep. >> >>> Is there some way I can get the unwinder data from inside of libgcj itself before >>> the call to _Unwind_Exception()? If the bad unwind information is being generated in >>> libjava wouldn't it be just as easy to see that from outside of libgcc (before the call >>> to _Unwind_Exception()? >> You mean decoding the unwinder data by hand? It's not impossible, but >> it'd be a hell of a job. >> > I managed to get a build of libgcc at -O0 under darwin9 that I used to walk through > the FSF gcc unwinder. The walk is at... > > http://gcc.gnu.org/bugzilla/attachment.cgi?id=19174 > > and the list of the frames is at... > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c26 > > Does this clarify the problem at all on intel darwin? Let me know if there > is any other particular debug information I can provide. It stops when unwinding java.lang.ClassLoader.loadClass(java.lang.String, boolean), either because the unwinder data is buggy (probably) or because the unwinder itself is buggy. It's hard to be exactly clear what's going wrong, but it may be that the place it fails is at the point where the program calls libgcj. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-29 18:01 ` Andrew Haley @ 2009-11-29 18:48 ` Jack Howarth 2009-11-30 10:09 ` Andrew Haley 0 siblings, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-11-29 18:48 UTC (permalink / raw) To: Andrew Haley; +Cc: borlum, java On Sun, Nov 29, 2009 at 06:00:57PM +0000, Andrew Haley wrote: > Jack Howarth wrote: > > On Sat, Nov 28, 2009 at 10:43:26AM +0000, Andrew Haley wrote: > >> Jack Howarth wrote: > >>> On Fri, Nov 27, 2009 at 10:40:17AM +0000, Andrew Haley wrote: > >>>> borlum wrote: > >>>>> Jack Howarth-3 wrote: > >>>>>> On Tue, Nov 17, 2009 at 05:13:31PM +0000, Andrew Haley wrote: > >>>>>>> Sometimes it doesn't work, so you have to be inventive. Try > >>>>>>> setting a breakpoint on Unwind_RaiseException, or step a single > >>>>>>> instruction at a time when you get to a call. > >>>>>>> > >>>>>>>> I assume that gcc trunk's > >>>>>>>> debug code is still compatible with Apple's gdb. If not, I do have > >>>>>>>> a build of gdb 7.0 on Intel darwin that I can use instead. Thanks > >>>>>>>> in advance for any hints on this issue. > >>>>>>>> Jack > >>>>>>>> ps I do notice that gdb can't find the object files from > >>>>>>> /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax > >>>>>>> so it might have problems with debugging within libgcj. If I recall > >>>>>>> correctly this .lax issue is known... > >>>>>>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html > >>>>>>> Ouch. That will cause gdb breakage, for sure. > >>>>>> Andrew, > >>>>>> Re-reading Peter's comments in > >>>>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html, I think I > >>>>>> may be able to work around the lax issue with the proper setting of > >>>>>> LD_LIBRARY to point to > >>>>>> the shared library in the build directory. I'll see if I can puzzle that > >>>>>> one out. > >>>>>> Jack > >>>>>>> Andrew. > >>>>> Hey Andrew, > >>>>> > >>>>> Did you ever solve the problem? I'm having the same rather frustrating > >>>>> error. > >>>> Not me, no. I don't have a Darwin system. > >>> Now that we have a set of patches to fix the breakage in current gcc > >>> trunk to dsymutil, I have uploaded a much more complete walk under x86_64-apple-darwin10. > >>> I haven't managed to walk into _Unwind_Exception() yet but I do see that the > >>> crash occurs on continuing from the 39th instance of the _Unwind_Exception() breakpoint. > >> That's probably just the end of the stack. If you do a stack trace > >> in gdb you'll probably find it's something like 39 deep. > >> > >>> Is there some way I can get the unwinder data from inside of libgcj itself before > >>> the call to _Unwind_Exception()? If the bad unwind information is being generated in > >>> libjava wouldn't it be just as easy to see that from outside of libgcc (before the call > >>> to _Unwind_Exception()? > >> You mean decoding the unwinder data by hand? It's not impossible, but > >> it'd be a hell of a job. > >> > > I managed to get a build of libgcc at -O0 under darwin9 that I used to walk through > > the FSF gcc unwinder. The walk is at... > > > > http://gcc.gnu.org/bugzilla/attachment.cgi?id=19174 > > > > and the list of the frames is at... > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c26 > > > > Does this clarify the problem at all on intel darwin? Let me know if there > > is any other particular debug information I can provide. > > It stops when unwinding java.lang.ClassLoader.loadClass(java.lang.String, boolean), > either because the unwinder data is buggy (probably) or because the unwinder > itself is buggy. Would it help if I just used a breakpoint on uw_frame_state_for() and provided all of the unwinding info that is being processed? Might that clarify if the unwinder data is buggy? Jack > > It's hard to be exactly clear what's going wrong, but it may be that the place > it fails is at the point where the program calls libgcj. > > Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-29 18:48 ` Jack Howarth @ 2009-11-30 10:09 ` Andrew Haley 2009-11-30 16:01 ` Jack Howarth 0 siblings, 1 reply; 61+ messages in thread From: Andrew Haley @ 2009-11-30 10:09 UTC (permalink / raw) To: Jack Howarth; +Cc: borlum, java Jack Howarth wrote: > On Sun, Nov 29, 2009 at 06:00:57PM +0000, Andrew Haley wrote: >> Jack Howarth wrote: >>> On Sat, Nov 28, 2009 at 10:43:26AM +0000, Andrew Haley wrote: >>>> Jack Howarth wrote: >>>>> On Fri, Nov 27, 2009 at 10:40:17AM +0000, Andrew Haley wrote: >>>> >>> I managed to get a build of libgcc at -O0 under darwin9 that I used to walk through >>> the FSF gcc unwinder. The walk is at... >>> >>> http://gcc.gnu.org/bugzilla/attachment.cgi?id=19174 >>> >>> and the list of the frames is at... >>> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c26 >>> >>> Does this clarify the problem at all on intel darwin? Let me know if there >>> is any other particular debug information I can provide. >> It stops when unwinding java.lang.ClassLoader.loadClass(java.lang.String, boolean), >> either because the unwinder data is buggy (probably) or because the unwinder >> itself is buggy. > > Would it help if I just used a breakpoint on uw_frame_state_for() and provided all > of the unwinding info that is being processed? Might that clarify if the unwinder > data is buggy? Not really, no. The only thing now is to debug the unwinder at the point where the exception should be caught. You're seeing a bus error in the unwinder itself, which points to a failure to follow the chain of stack frames. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-30 10:09 ` Andrew Haley @ 2009-11-30 16:01 ` Jack Howarth 2009-11-30 16:07 ` Andrew Haley 0 siblings, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-11-30 16:01 UTC (permalink / raw) To: Andrew Haley; +Cc: borlum, java On Mon, Nov 30, 2009 at 10:09:17AM +0000, Andrew Haley wrote: > Jack Howarth wrote: > > On Sun, Nov 29, 2009 at 06:00:57PM +0000, Andrew Haley wrote: > >> Jack Howarth wrote: > >>> On Sat, Nov 28, 2009 at 10:43:26AM +0000, Andrew Haley wrote: > >>>> Jack Howarth wrote: > >>>>> On Fri, Nov 27, 2009 at 10:40:17AM +0000, Andrew Haley wrote: > > >>>> > >>> I managed to get a build of libgcc at -O0 under darwin9 that I used to walk through > >>> the FSF gcc unwinder. The walk is at... > >>> > >>> http://gcc.gnu.org/bugzilla/attachment.cgi?id=19174 > >>> > >>> and the list of the frames is at... > >>> > >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c26 > >>> > >>> Does this clarify the problem at all on intel darwin? Let me know if there > >>> is any other particular debug information I can provide. > >> It stops when unwinding java.lang.ClassLoader.loadClass(java.lang.String, boolean), > >> either because the unwinder data is buggy (probably) or because the unwinder > >> itself is buggy. > > > > Would it help if I just used a breakpoint on uw_frame_state_for() and provided all > > of the unwinding info that is being processed? Might that clarify if the unwinder > > data is buggy? > > Not really, no. The only thing now is to debug the unwinder at the point > where the exception should be caught. You're seeing a bus error in the > unwinder itself, which points to a failure to follow the chain of stack > frames. > > Andrew. Andrew, I'll generate a complete debug walk from the last instance of the _Unwind_RaiseException breakpoint before the crash tonight. I started doing that this weekend but it was taking forever to complete the walk. What code actually generates the unwind info in gcj? Is it from libffi? I might also drop back to the gcc 4.3.x releases in darwin9 to see if I can detect if this ever worked and if so when it regressed. However, considering that Andreas has managed to get this to be suppressed at times, I wonder if this issue has always been present on intel darwin and just tends to go latent at times. Jack ps It is odd that the unwind info generated for compiling classes with gcj never seems to cause a problem. Could that be a clue as to the segment of code at fault? I noticed that the ecjx.c source is a dummy shell so I was unclear which code is used in gcj to compile java source but not classes. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-30 16:01 ` Jack Howarth @ 2009-11-30 16:07 ` Andrew Haley 2009-12-01 5:02 ` Jack Howarth 0 siblings, 1 reply; 61+ messages in thread From: Andrew Haley @ 2009-11-30 16:07 UTC (permalink / raw) To: Jack Howarth; +Cc: borlum, java Jack Howarth wrote: > On Mon, Nov 30, 2009 at 10:09:17AM +0000, Andrew Haley wrote: >> Jack Howarth wrote: >>> On Sun, Nov 29, 2009 at 06:00:57PM +0000, Andrew Haley wrote: >>>> Jack Howarth wrote: >>>>> On Sat, Nov 28, 2009 at 10:43:26AM +0000, Andrew Haley wrote: >>>>>> Jack Howarth wrote: >>>>>>> On Fri, Nov 27, 2009 at 10:40:17AM +0000, Andrew Haley wrote: >>>>> I managed to get a build of libgcc at -O0 under darwin9 that I used to walk through >>>>> the FSF gcc unwinder. The walk is at... >>>>> >>>>> http://gcc.gnu.org/bugzilla/attachment.cgi?id=19174 >>>>> >>>>> and the list of the frames is at... >>>>> >>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c26 >>>>> >>>>> Does this clarify the problem at all on intel darwin? Let me know if there >>>>> is any other particular debug information I can provide. >>>> It stops when unwinding java.lang.ClassLoader.loadClass(java.lang.String, boolean), >>>> either because the unwinder data is buggy (probably) or because the unwinder >>>> itself is buggy. >>> Would it help if I just used a breakpoint on uw_frame_state_for() and provided all >>> of the unwinding info that is being processed? Might that clarify if the unwinder >>> data is buggy? >> Not really, no. The only thing now is to debug the unwinder at the point >> where the exception should be caught. You're seeing a bus error in the >> unwinder itself, which points to a failure to follow the chain of stack >> frames. > I'll generate a complete debug walk from the last instance of the > _Unwind_RaiseException breakpoint before the crash tonight. I started > doing that this weekend but it was taking forever to complete the walk. > What code actually generates the unwind info in gcj? The gcc back end. > Is it from libffi? libffi has its own unwind info. It's written by hand, and it might be wrong. look in libffi/x86/darwin64.S. > I might also drop back to the gcc 4.3.x releases in darwin9 to see if > I can detect if this ever worked and if so when it regressed. However, > considering that Andreas has managed to get this to be suppressed at > times, I wonder if this issue has always been present on intel darwin > and just tends to go latent at times. That's quite possible, for sure. > ps It is odd that the unwind info generated for compiling classes with > gcj never seems to cause a problem. Could that be a clue as to the > segment of code at fault? I noticed that the ecjx.c source is a dummy > shell so I was unclear which code is used in gcj to compile java source > but not classes. I think you really need to concentrate on the instruction that's causing the bus error. What is is pointing at? What it it trying to do? The other thing that's odd is that there are a number of test cases in the libgcj test suite that stress the interpreter (and therefore libffi) quite a lot. Are you really seeing 100% pass? Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-11-30 16:07 ` Andrew Haley @ 2009-12-01 5:02 ` Jack Howarth 2009-12-01 9:30 ` Andrew Haley 0 siblings, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-12-01 5:02 UTC (permalink / raw) To: Andrew Haley; +Cc: borlum, java Andrew, I have uploaded a bz2 archive of the walk from the last _Unwind_RaiseException breakpoint before the crash up to the crash to PR41991. The crash appears at... _Jv_GetMethodLocal (klass=0x104a298c0, name=0x104af13a0, signature=0x104b1dfe0) at ../../../gcc-4.5-20091128/libjava/java/lang/natClass.cc:1633 1633 && _Jv_equalUtf8Consts (signature, klass->methods[i].signature)) (gdb) _Jv_equalUtf8Consts (a=0x104b1dfe0, b=0x1048262c0) at ../../../gcc-4.5-20091128/libjava/prims.cc:209 209 if (a == b) (gdb) 210 return true; (gdb) 209 if (a == b) (gdb) 211 if (a->hash != b->hash) (gdb) 212 return false; (gdb) 211 if (a->hash != b->hash) (gdb) 214 if (b->length != len) (gdb) 218 len = (len + 1) >> 1; (gdb) 216 aptr = (const _Jv_ushort *)a->data; (gdb) 217 bptr = (const _Jv_ushort *)b->data; (gdb) 218 len = (len + 1) >> 1; (gdb) 219 while (--len >= 0) (gdb) 220 if (*aptr++ != *bptr++) (gdb) 219 while (--len >= 0) (gdb) 220 if (*aptr++ != *bptr++) (gdb) 219 while (--len >= 0) (gdb) 220 if (*aptr++ != *bptr++) (gdb) 219 while (--len >= 0) (gdb) 220 if (*aptr++ != *bptr++) (gdb) 219 while (--len >= 0) (gdb) 220 if (*aptr++ != *bptr++) (gdb) 219 while (--len >= 0) (gdb) 220 if (*aptr++ != *bptr++) (gdb) 219 while (--len >= 0) (gdb) 220 if (*aptr++ != *bptr++) (gdb) 219 while (--len >= 0) (gdb) 220 if (*aptr++ != *bptr++) (gdb) 219 while (--len >= 0) (gdb) 220 if (*aptr++ != *bptr++) (gdb) 219 while (--len >= 0) (gdb) 220 if (*aptr++ != *bptr++) (gdb) 219 while (--len >= 0) (gdb) 220 if (*aptr++ != *bptr++) (gdb) 219 while (--len >= 0) (gdb) 222 return true; (gdb) 223 } (gdb) _Jv_GetMethodLocal (klass=0x104a298c0, name=0x104af13a0, signature=0x104b1dfe0) at ../../../gcc-4.5-20091128/libjava/java/lang/natClass.cc:1632 1632 if (_Jv_equalUtf8Consts (name, klass->methods[i].name) (gdb) 1634 return &klass->methods[i]; (gdb) 1637 } (gdb) _Jv_LookupDeclaredMethod (klass=0x104a298c0, name=0x104af13a0, signature=0x104b1dfe0, declarer_result=0x0) at ../../../gcc-4.5-20091128/libjava/java/lang/natClass.cc:1648 1648 if (meth) (gdb) 1650 if (declarer_result) (gdb) 1657 } (gdb) gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:41 41 if (meth == NULL) (gdb) 37 main_signature); (gdb) 41 if (meth == NULL) (gdb) 43 else if (! ::java::lang::reflect::Modifier::isStatic(meth->accflags)) (gdb) _ZN4java4lang7reflect8Modifier8isStaticEJbi (mod=9) at Modifier.java:268 268 return (mod & STATIC) != 0; (gdb) _ZN4java4lang7reflect8Modifier8isStaticEJbi (mod=9) at Modifier.java:268 268 return (mod & STATIC) != 0; (gdb) 0x0000000100994af0 in dyld_stub__Jv_InitClass () at RowSetEvent.java:51 51 RowSetEvent.java: No such file or directory. in RowSetEvent.java (gdb) _Jv_InitClass (klass=0x10168ce40) at Class.h:740 740 if (__builtin_expect (klass->state == JV_STATE_DONE, true)) (gdb) 743 } (gdb) 0x00000001004168bf in _ZN4java4lang7reflect8Modifier8isStaticEJbi (mod=9) at Modifier.java:268 268 return (mod & STATIC) != 0; (gdb) gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:44 44 msg = "`main' must be static"; (gdb) 43 else if (! ::java::lang::reflect::Modifier::isStatic(meth->accflags)) (gdb) 45 else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags)) (gdb) _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258 258 return (mod & PUBLIC) != 0; (gdb) _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258 258 return (mod & PUBLIC) != 0; (gdb) 0x0000000100994af0 in dyld_stub__Jv_InitClass () at RowSetEvent.java:51 51 RowSetEvent.java: No such file or directory. in RowSetEvent.java (gdb) _Jv_InitClass (klass=0x10168ce40) at Class.h:740 740 if (__builtin_expect (klass->state == JV_STATE_DONE, true)) (gdb) 743 } (gdb) 0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258 258 return (mod & PUBLIC) != 0; (gdb) gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 46 msg = "`main' must be public"; (gdb) 45 else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags)) (gdb) 54 (*real_main) (args); (gdb) Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 51 RowSetEvent.java: No such file or directory. in RowSetEvent.java (gdb) A backtrace only shows... (gdb) bt #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 Previous frame inner to this frame (gdb could not unwind past this frame) Let me know if you have any suggestions for debugging this further. Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-01 5:02 ` Jack Howarth @ 2009-12-01 9:30 ` Andrew Haley 2009-12-01 17:04 ` Jack Howarth 0 siblings, 1 reply; 61+ messages in thread From: Andrew Haley @ 2009-12-01 9:30 UTC (permalink / raw) To: Jack Howarth; +Cc: borlum, java Jack Howarth wrote: > (gdb) > 54 (*real_main) (args); > (gdb) > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 > 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > 51 RowSetEvent.java: No such file or directory. > in RowSetEvent.java > (gdb) > > A backtrace only shows... > > (gdb) bt > #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 > Previous frame inner to this frame (gdb could not unwind past this frame) > > Let me know if you have any suggestions for debugging this further. Disassemble the first 10 or so instructions at the instruction where the EXC_BAD_ACCESS occurs. I think this is a libffi bug. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-01 9:30 ` Andrew Haley @ 2009-12-01 17:04 ` Jack Howarth 2009-12-01 17:24 ` Andrew Haley 0 siblings, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-12-01 17:04 UTC (permalink / raw) To: Andrew Haley; +Cc: borlum, java On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote: > Jack Howarth wrote: > > > (gdb) > > 54 (*real_main) (args); > > (gdb) > > > > Program received signal EXC_BAD_ACCESS, Could not access memory. > > Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 > > 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > > 51 RowSetEvent.java: No such file or directory. > > in RowSetEvent.java > > (gdb) > > > > A backtrace only shows... > > > > (gdb) bt > > #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > > #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 > > Previous frame inner to this frame (gdb could not unwind past this frame) > > > > Let me know if you have any suggestions for debugging this further. > > Disassemble the first 10 or so instructions at the instruction where the > EXC_BAD_ACCESS occurs. I think this is a libffi bug. > > Andrew. Andrew, So just to clarify, for the instance of... ------------------- (gdb) 0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258 258 return (mod & PUBLIC) != 0; (gdb) gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 46 msg = "`main' must be public"; (gdb) 45 else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags)) (gdb) 54 (*real_main) (args); (gdb) Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 51 RowSetEvent.java: No such file or directory. in RowSetEvent.java (gdb) A backtrace only shows... (gdb) bt #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 Previous frame inner to this frame (gdb could not unwind past this frame) ----------------- I want to disassemble from 0x00000001000485be, right? Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-01 17:04 ` Jack Howarth @ 2009-12-01 17:24 ` Andrew Haley 2009-12-01 23:29 ` Jack Howarth 0 siblings, 1 reply; 61+ messages in thread From: Andrew Haley @ 2009-12-01 17:24 UTC (permalink / raw) To: Jack Howarth; +Cc: borlum, java Jack Howarth wrote: > On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote: >> Jack Howarth wrote: >> >>> (gdb) >>> 54 (*real_main) (args); >>> (gdb) >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 >>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 >>> 51 RowSetEvent.java: No such file or directory. >>> in RowSetEvent.java >>> (gdb) >>> >>> A backtrace only shows... >>> >>> (gdb) bt >>> #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 >>> #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 >>> Previous frame inner to this frame (gdb could not unwind past this frame) >>> >>> Let me know if you have any suggestions for debugging this further. >> Disassemble the first 10 or so instructions at the instruction where the >> EXC_BAD_ACCESS occurs. I think this is a libffi bug. >> >> Andrew. > > Andrew, > So just to clarify, for the instance of... > > ------------------- > > (gdb) > 0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258 > 258 return (mod & PUBLIC) != 0; > (gdb) > gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 > 46 msg = "`main' must be public"; > (gdb) > 45 else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags)) > (gdb) > 54 (*real_main) (args); > (gdb) > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 > 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > 51 RowSetEvent.java: No such file or directory. > in RowSetEvent.java > (gdb) > > A backtrace only shows... > > (gdb) bt > #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 > Previous frame inner to this frame (gdb could not unwind past this frame) > > ----------------- > > I want to disassemble from 0x00000001000485be, right? 0x0000000103f05db0, where the fault happens. I think it's a libffi stub, and I think its page permissions are not correctly set. But let's see. What I would do is, at > 54 (*real_main) (args); disassemble the call instruction, it's probably call ($rax) or somesuch. look in $rax with p $rax and disassemble from the address that's in there. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-01 17:24 ` Andrew Haley @ 2009-12-01 23:29 ` Jack Howarth 2009-12-02 9:34 ` Andrew Haley 0 siblings, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-12-01 23:29 UTC (permalink / raw) To: Andrew Haley; +Cc: borlum, java On Tue, Dec 01, 2009 at 05:24:29PM +0000, Andrew Haley wrote: > Jack Howarth wrote: > > On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote: > >> Jack Howarth wrote: > >> > >>> (gdb) > >>> 54 (*real_main) (args); > >>> (gdb) > >>> > >>> Program received signal EXC_BAD_ACCESS, Could not access memory. > >>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 > >>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > >>> 51 RowSetEvent.java: No such file or directory. > >>> in RowSetEvent.java > >>> (gdb) > >>> > >>> A backtrace only shows... > >>> > >>> (gdb) bt > >>> #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > >>> #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 > >>> Previous frame inner to this frame (gdb could not unwind past this frame) > >>> > >>> Let me know if you have any suggestions for debugging this further. > >> Disassemble the first 10 or so instructions at the instruction where the > >> EXC_BAD_ACCESS occurs. I think this is a libffi bug. > >> > >> Andrew. > > > > Andrew, > > So just to clarify, for the instance of... > > > > ------------------- > > > > (gdb) > > 0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258 > > 258 return (mod & PUBLIC) != 0; > > (gdb) > > gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 > > 46 msg = "`main' must be public"; > > (gdb) > > 45 else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags)) > > (gdb) > > 54 (*real_main) (args); > > (gdb) > > > > Program received signal EXC_BAD_ACCESS, Could not access memory. > > Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 > > 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > > 51 RowSetEvent.java: No such file or directory. > > in RowSetEvent.java > > (gdb) > > > > A backtrace only shows... > > > > (gdb) bt > > #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > > #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 > > Previous frame inner to this frame (gdb could not unwind past this frame) > > > > ----------------- > > > > I want to disassemble from 0x00000001000485be, right? > > 0x0000000103f05db0, where the fault happens. I think it's a libffi stub, > and I think its page permissions are not correctly set. > > But let's see. > > What I would do is, at > > > 54 (*real_main) (args); > > disassemble the call instruction, it's probably call ($rax) or somesuch. > look in $rax with > > p $rax > > and disassemble from the address that's in there. > > Andrew. Andrew, I can't disassemble 0x0000000103f05db0... (gdb) disassemble 0x0000000103f05db0 No function contains specified address. Disassembling 0x00000001000485be shows... (gdb) disassemble 0x00000001000485be Dump of assembler code for function _ZN3gnu4java4lang10MainThread9call_mainEJvv: 0x00000001000484f0 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+0>: mov %rbx,-0x18(%rsp) 0x00000001000484f5 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+5>: mov %rdi,%rbx 0x00000001000484f8 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+8>: lea 0x94f508(%rip),%rdi # 0x100997a07 <dyld_stub_write+10609> 0x00000001000484ff <_ZN3gnu4java4lang10MainThread9call_mainEJvv+15>: mov %rbp,-0x10(%rsp) 0x0000000100048504 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+20>: mov %r12,-0x8(%rsp) 0x0000000100048509 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+25>: mov $0x16,%esi 0x000000010004850e <_ZN3gnu4java4lang10MainThread9call_mainEJvv+30>: sub $0x18,%rsp 0x0000000100048512 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+34>: callq 0x100005a50 <_Z17_Jv_makeUtf8ConstPKci> 0x0000000100048517 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+39>: lea 0x94f500(%rip),%rdi # 0x100997a1e <dyld_stub_write+10632> 0x000000010004851e <_ZN3gnu4java4lang10MainThread9call_mainEJvv+46>: mov $0x4,%esi 0x0000000100048523 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+51>: mov %rax,%r12 0x0000000100048526 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+54>: callq 0x100005a50 <_Z17_Jv_makeUtf8ConstPKci> 0x000000010004852b <_ZN3gnu4java4lang10MainThread9call_mainEJvv+59>: mov 0x80(%rbx),%rdi 0x0000000100048532 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+66>: mov $0x3,%esi 0x0000000100048537 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+71>: mov %rax,%rbp 0x000000010004853a <_ZN3gnu4java4lang10MainThread9call_mainEJvv+74>: callq 0x100016830 <_ZN10_Jv_Linker14wait_for_stateEPN4java4lang5ClassEi> 0x000000010004853f <_ZN3gnu4java4lang10MainThread9call_mainEJvv+79>: mov 0x80(%rbx),%rdi 0x0000000100048546 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+86>: xor %ecx,%ecx 0x0000000100048548 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+88>: mov %rbp,%rsi 0x000000010004854b <_ZN3gnu4java4lang10MainThread9call_mainEJvv+91>: mov %r12,%rdx 0x000000010004854e <_ZN3gnu4java4lang10MainThread9call_mainEJvv+94>: callq 0x100051b10 <_Z24_Jv_LookupDeclaredMethodPN4java4lang5ClassEP13_Jv_Utf8ConstS4_PS2_> 0x0000000100048553 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+99>: test %rax,%rax 0x0000000100048556 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+102>: mov %rax,%rbp 0x0000000100048559 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+105>: je 0x1000485f0 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+256> 0x000000010004855f <_ZN3gnu4java4lang10MainThread9call_mainEJvv+111>: movzwl 0x10(%rax),%edi 0x0000000100048563 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+115>: callq 0x1004168b0 <_ZN4java4lang7reflect8Modifier8isStaticEJbi> 0x0000000100048568 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+120>: test %al,%al 0x000000010004856a <_ZN3gnu4java4lang10MainThread9call_mainEJvv+122>: lea 0x94f46a(%rip),%rdx # 0x1009979db <dyld_stub_write+10565> 0x0000000100048571 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+129>: jne 0x1000485a0 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+176> 0x0000000100048573 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+131>: mov 0x1329a96(%rip),%rax # 0x101372010 <ffi_type_longdouble+48> 0x000000010004857a <_ZN3gnu4java4lang10MainThread9call_mainEJvv+138>: lea 0x94f4a2(%rip),%rsi # 0x100997a23 <dyld_stub_write+10637> 0x0000000100048581 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+145>: mov (%rax),%rdi 0x0000000100048584 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+148>: xor %eax,%eax 0x0000000100048586 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+150>: callq 0x100994d4e <dyld_stub_fprintf> 0x000000010004858b <_ZN3gnu4java4lang10MainThread9call_mainEJvv+155>: mov $0x1,%edi 0x0000000100048590 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+160>: callq 0x100994d1e <dyld_stub_exit> 0x0000000100048595 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+165>: nopl 0x0(%rax,%rax,1) 0x000000010004859a <_ZN3gnu4java4lang10MainThread9call_mainEJvv+170>: nopw 0x0(%rax,%rax,1) 0x00000001000485a0 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+176>: movzwl 0x10(%rbp),%edi 0x00000001000485a4 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+180>: callq 0x1004168d0 <_ZN4java4lang7reflect8Modifier8isPublicEJbi> 0x00000001000485a9 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+185>: test %al,%al 0x00000001000485ab <_ZN3gnu4java4lang10MainThread9call_mainEJvv+187>: lea 0x94f43f(%rip),%rdx # 0x1009979f1 <dyld_stub_write+10587> 0x00000001000485b2 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+194>: je 0x100048573 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+131> 0x00000001000485b4 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+196>: mov 0x90(%rbx),%rdi 0x00000001000485bb <_ZN3gnu4java4lang10MainThread9call_mainEJvv+203>: callq *0x18(%rbp) 0x00000001000485be <_ZN3gnu4java4lang10MainThread9call_mainEJvv+206>: callq 0x100062450 <_Z14_Jv_ThreadWaitv> 0x00000001000485c3 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+211>: lea 0x1629dde(%rip),%rax # 0x1016723a8 <_ZN4java4lang11ThreadGroup22had_uncaught_exceptionE> 0x00000001000485ca <_ZN3gnu4java4lang10MainThread9call_mainEJvv+218>: mov (%rsp),%rbx 0x00000001000485ce <_ZN3gnu4java4lang10MainThread9call_mainEJvv+222>: mov 0x8(%rsp),%rbp 0x00000001000485d3 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+227>: mov 0x10(%rsp),%r12 0x00000001000485d8 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+232>: movzbl (%rax),%edi 0x00000001000485db <_ZN3gnu4java4lang10MainThread9call_mainEJvv+235>: add $0x18,%rsp 0x00000001000485df <_ZN3gnu4java4lang10MainThread9call_mainEJvv+239>: jmpq 0x100409600 <_ZN4java4lang7Runtime20exitNoChecksAccessorEJvi> 0x00000001000485e4 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+244>: nopw 0x0(%rax,%rax,1) 0x00000001000485ea <_ZN3gnu4java4lang10MainThread9call_mainEJvv+250>: nopw 0x0(%rax,%rax,1) 0x00000001000485f0 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+256>: lea 0x94f3c1(%rip),%rdx # 0x1009979b8 <dyld_stub_write+10530> 0x00000001000485f7 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+263>: jmpq 0x100048573 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+131> Do I need to actually stop the process of stepping through the code before I hit the crash in order to disassemble real_main? I tried... (gdb) break ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 Breakpoint 1 at 0x20c49ba4b0a5ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46. (gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar warning: posix_spawn failed, trying execvp, error: 86 Reading symbols for shared libraries +++++.. done Breakpoint 1 at 0x1000485ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46. Breakpoint 1, gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 46 msg = "`main' must be public"; (gdb) s Current language: auto; currently c++ 45 else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags)) (gdb) s 54 (*real_main) (args); (gdb) bt #0 gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 #1 0x0000000104875dc0 in ?? () at ClassHelper.java:106 #2 0x0000000104875f00 in ?? () at ClassHelper.java:106 #3 0x000000010493e980 in ?? () at ClassHelper.java:106 #4 0x00000001000b1b74 in _ZN3gnu4java4lang10MainThread3runEJvv (this=0x104875dc0) at MainThread.java:106 Previous frame inner to this frame (gdb could not unwind past this frame) (gdb) info line 54 Line 54 of "../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc" starts at address 0x1000485b4 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+196> and ends at 0x1000485be <_ZN3gnu4java4lang10MainThread9call_mainEJvv+206>. (gdb) disassemble 0x1000485b4 0x1000485be Dump of assembler code from 0x1000485b4 to 0x1000485be: 0x00000001000485b4 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+196>: mov 0x90(%rbx),%rdi 0x00000001000485bb <_ZN3gnu4java4lang10MainThread9call_mainEJvv+203>: callq *0x18(%rbp) End of assembler dump. (gdb) I'm not sure what to do at this point to disassemble the call destination... (gdb) disassemble *0x18(%rbp) A syntax error in expression, near `%rbp)'. (gdb) disassemble 0x18(%rbp) A syntax error in expression, near `%rbp)'. (gdb) disassemble %rbp A syntax error in expression, near `%rbp'. I am at the correct spot though since the next step causes the crash. Also I do notice that the output from "disassemble 0x1000485b4 0x1000485be" is listed in the longer disassembly from 0x00000001000485be. Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-01 23:29 ` Jack Howarth @ 2009-12-02 9:34 ` Andrew Haley 2009-12-03 1:08 ` Jack Howarth 0 siblings, 1 reply; 61+ messages in thread From: Andrew Haley @ 2009-12-02 9:34 UTC (permalink / raw) To: Jack Howarth; +Cc: borlum, java Jack Howarth wrote: > On Tue, Dec 01, 2009 at 05:24:29PM +0000, Andrew Haley wrote: >> Jack Howarth wrote: >>> On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote: >>>> Jack Howarth wrote: >>>> >>>>> (gdb) >>>>> 54 (*real_main) (args); >>>>> (gdb) >>>>> >>>>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 >>>>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 >>>>> 51 RowSetEvent.java: No such file or directory. >>>>> in RowSetEvent.java >>>>> (gdb) >>>>> >>>>> A backtrace only shows... >>>>> >>>>> (gdb) bt >>>>> #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 >>>>> #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 >>>>> Previous frame inner to this frame (gdb could not unwind past this frame) >>>>> >>>>> Let me know if you have any suggestions for debugging this further. >>>> Disassemble the first 10 or so instructions at the instruction where the >>>> EXC_BAD_ACCESS occurs. I think this is a libffi bug. >>>> >>>> Andrew. >>> Andrew, >>> So just to clarify, for the instance of... >>> >>> ------------------- >>> >>> (gdb) >>> 0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258 >>> 258 return (mod & PUBLIC) != 0; >>> (gdb) >>> gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 >>> 46 msg = "`main' must be public"; >>> (gdb) >>> 45 else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags)) >>> (gdb) >>> 54 (*real_main) (args); >>> (gdb) >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 >>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 >>> 51 RowSetEvent.java: No such file or directory. >>> in RowSetEvent.java >>> (gdb) >>> >>> A backtrace only shows... >>> >>> (gdb) bt >>> #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 >>> #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 >>> Previous frame inner to this frame (gdb could not unwind past this frame) >>> >>> ----------------- >>> >>> I want to disassemble from 0x00000001000485be, right? >> 0x0000000103f05db0, where the fault happens. I think it's a libffi stub, >> and I think its page permissions are not correctly set. >> >> But let's see. >> >> What I would do is, at >> >>> 54 (*real_main) (args); >> disassemble the call instruction, it's probably call ($rax) or somesuch. >> look in $rax with >> >> p $rax >> >> and disassemble from the address that's in there. >> >> Andrew. > > Andrew, > I can't disassemble 0x0000000103f05db0... > > (gdb) disassemble 0x0000000103f05db0 > No function contains specified address. x/10i 0x0000000103f05db0 Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-02 9:34 ` Andrew Haley @ 2009-12-03 1:08 ` Jack Howarth 2009-12-03 10:26 ` Andrew Haley 0 siblings, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-12-03 1:08 UTC (permalink / raw) To: Andrew Haley; +Cc: borlum, java On Wed, Dec 02, 2009 at 09:34:33AM +0000, Andrew Haley wrote: > Jack Howarth wrote: > > On Tue, Dec 01, 2009 at 05:24:29PM +0000, Andrew Haley wrote: > >> Jack Howarth wrote: > >>> On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote: > >>>> Jack Howarth wrote: > >>>> > >>>>> (gdb) > >>>>> 54 (*real_main) (args); > >>>>> (gdb) > >>>>> > >>>>> Program received signal EXC_BAD_ACCESS, Could not access memory. > >>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 > >>>>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > >>>>> 51 RowSetEvent.java: No such file or directory. > >>>>> in RowSetEvent.java > >>>>> (gdb) > >>>>> > >>>>> A backtrace only shows... > >>>>> > >>>>> (gdb) bt > >>>>> #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > >>>>> #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 > >>>>> Previous frame inner to this frame (gdb could not unwind past this frame) > >>>>> > >>>>> Let me know if you have any suggestions for debugging this further. > >>>> Disassemble the first 10 or so instructions at the instruction where the > >>>> EXC_BAD_ACCESS occurs. I think this is a libffi bug. > >>>> > >>>> Andrew. > >>> Andrew, > >>> So just to clarify, for the instance of... > >>> > >>> ------------------- > >>> > >>> (gdb) > >>> 0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258 > >>> 258 return (mod & PUBLIC) != 0; > >>> (gdb) > >>> gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 > >>> 46 msg = "`main' must be public"; > >>> (gdb) > >>> 45 else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags)) > >>> (gdb) > >>> 54 (*real_main) (args); > >>> (gdb) > >>> > >>> Program received signal EXC_BAD_ACCESS, Could not access memory. > >>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 > >>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > >>> 51 RowSetEvent.java: No such file or directory. > >>> in RowSetEvent.java > >>> (gdb) > >>> > >>> A backtrace only shows... > >>> > >>> (gdb) bt > >>> #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > >>> #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 > >>> Previous frame inner to this frame (gdb could not unwind past this frame) > >>> > >>> ----------------- > >>> > >>> I want to disassemble from 0x00000001000485be, right? > >> 0x0000000103f05db0, where the fault happens. I think it's a libffi stub, > >> and I think its page permissions are not correctly set. > >> > >> But let's see. > >> > >> What I would do is, at > >> > >>> 54 (*real_main) (args); > >> disassemble the call instruction, it's probably call ($rax) or somesuch. > >> look in $rax with > >> > >> p $rax > >> > >> and disassemble from the address that's in there. > >> > >> Andrew. > > > > Andrew, > > I can't disassemble 0x0000000103f05db0... > > > > (gdb) disassemble 0x0000000103f05db0 > > No function contains specified address. > > x/10i 0x0000000103f05db0 > > Andrew. Andrew, Okay, I see... gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 ... gdb) break ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 Breakpoint 1 at 0x20c49ba4b0a5ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46. (gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar warning: posix_spawn failed, trying execvp, error: 86 Reading symbols for shared libraries +++++.. done Breakpoint 1 at 0x1000485ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46. Breakpoint 1, gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 46 msg = "`main' must be public"; (gdb) s Current language: auto; currently c++ 45 else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags)) (gdb) s 54 (*real_main) (args); (gdb) x/10i 0x0000000103f05db0 0x103f05db0: mov $0x1009814e8,%r11 0x103f05dba: mov $0x103f05db0,%r10 0x103f05dc4: clc 0x103f05dc5: rex.WB jmpq *%r11 0x103f05dc8: add %bl,-0x10(%rsi) 0x103f05dcb: add (%rcx),%eax 0x103f05dcd: add %al,(%rax) 0x103f05dcf: add %ah,%al 0x103f05dd1: (bad) 0x103f05dd2: cwtl (gdb) bt #0 gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 #1 0x0000000104875dc0 in ?? () at ClassHelper.java:106 #2 0x0000000104875f00 in ?? () at ClassHelper.java:106 #3 0x000000010493e980 in ?? () at ClassHelper.java:106 #4 0x00000001000b1b74 in _ZN3gnu4java4lang10MainThread3runEJvv (this=0x104875dc0) at MainThread.java:106 Previous frame inner to this frame (gdb could not unwind past this frame) (gdb) p $rax $1 = 1 (gdb) s Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 0x0000000103f05db0 in ?? () at ClassHelper.java:106 106 ClassHelper.java: No such file or directory. in ClassHelper.java What do you make of the bad assembly at 0x103f05dd1? Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-03 1:08 ` Jack Howarth @ 2009-12-03 10:26 ` Andrew Haley 2009-12-03 14:03 ` Jack Howarth 0 siblings, 1 reply; 61+ messages in thread From: Andrew Haley @ 2009-12-03 10:26 UTC (permalink / raw) To: Jack Howarth; +Cc: borlum, java Jack Howarth wrote: > On Wed, Dec 02, 2009 at 09:34:33AM +0000, Andrew Haley wrote: >> Jack Howarth wrote: >>> On Tue, Dec 01, 2009 at 05:24:29PM +0000, Andrew Haley wrote: >>>> Jack Howarth wrote: >>>>> On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote: >>>>>> Jack Howarth wrote: >>>>>> >>>>>>> (gdb) >>>>>>> 54 (*real_main) (args); >>>>>>> (gdb) >>>>>>> >>>>>>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>>>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 >>>>>>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 >>>>>>> 51 RowSetEvent.java: No such file or directory. >>>>>>> in RowSetEvent.java >>>>>>> (gdb) >>>>>>> >>>>>>> A backtrace only shows... >>>>>>> >>>>>>> (gdb) bt >>>>>>> #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 >>>>>>> #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 >>>>>>> Previous frame inner to this frame (gdb could not unwind past this frame) >>>>>>> >>>>>>> Let me know if you have any suggestions for debugging this further. >>>>>> Disassemble the first 10 or so instructions at the instruction where the >>>>>> EXC_BAD_ACCESS occurs. I think this is a libffi bug. >>>>>> >>>>>> Andrew. >>>>> Andrew, >>>>> So just to clarify, for the instance of... >>>>> >>>>> ------------------- >>>>> >>>>> (gdb) >>>>> 0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258 >>>>> 258 return (mod & PUBLIC) != 0; >>>>> (gdb) >>>>> gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 >>>>> 46 msg = "`main' must be public"; >>>>> (gdb) >>>>> 45 else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags)) >>>>> (gdb) >>>>> 54 (*real_main) (args); >>>>> (gdb) >>>>> >>>>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 >>>>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 >>>>> 51 RowSetEvent.java: No such file or directory. >>>>> in RowSetEvent.java >>>>> (gdb) >>>>> >>>>> A backtrace only shows... >>>>> >>>>> (gdb) bt >>>>> #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 >>>>> #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 >>>>> Previous frame inner to this frame (gdb could not unwind past this frame) >>>>> >>>>> ----------------- >>>>> >>>>> I want to disassemble from 0x00000001000485be, right? >>>> 0x0000000103f05db0, where the fault happens. I think it's a libffi stub, >>>> and I think its page permissions are not correctly set. >>>> >>>> But let's see. >>>> >>>> What I would do is, at >>>> >>>>> 54 (*real_main) (args); >>>> disassemble the call instruction, it's probably call ($rax) or somesuch. >>>> look in $rax with >>>> >>>> p $rax >>>> >>>> and disassemble from the address that's in there. >>>> >>>> Andrew. >>> Andrew, >>> I can't disassemble 0x0000000103f05db0... >>> >>> (gdb) disassemble 0x0000000103f05db0 >>> No function contains specified address. >> x/10i 0x0000000103f05db0 >> >> Andrew. > > Andrew, > Okay, I see... > > gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 > ... > gdb) break ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 > Breakpoint 1 at 0x20c49ba4b0a5ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46. > (gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar > Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar > warning: posix_spawn failed, trying execvp, error: 86 > Reading symbols for shared libraries +++++.. done > Breakpoint 1 at 0x1000485ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46. > > Breakpoint 1, gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 > 46 msg = "`main' must be public"; > (gdb) s > Current language: auto; currently c++ > 45 else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags)) > (gdb) s > 54 (*real_main) (args); > (gdb) x/10i 0x0000000103f05db0 > 0x103f05db0: mov $0x1009814e8,%r11 > 0x103f05dba: mov $0x103f05db0,%r10 > 0x103f05dc4: clc > 0x103f05dc5: rex.WB jmpq *%r11 > 0x103f05dc8: add %bl,-0x10(%rsi) > 0x103f05dcb: add (%rcx),%eax > 0x103f05dcd: add %al,(%rax) > 0x103f05dcf: add %ah,%al > 0x103f05dd1: (bad) > 0x103f05dd2: cwtl > (gdb) bt > #0 gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 > #1 0x0000000104875dc0 in ?? () at ClassHelper.java:106 > #2 0x0000000104875f00 in ?? () at ClassHelper.java:106 > #3 0x000000010493e980 in ?? () at ClassHelper.java:106 > #4 0x00000001000b1b74 in _ZN3gnu4java4lang10MainThread3runEJvv (this=0x104875dc0) at MainThread.java:106 > Previous frame inner to this frame (gdb could not unwind past this frame) > (gdb) p $rax > $1 = 1 > > (gdb) s > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 > 0x0000000103f05db0 in ?? () at ClassHelper.java:106 > 106 ClassHelper.java: No such file or directory. > in ClassHelper.java > > What do you make of the bad assembly at 0x103f05dd1? There is no bad assembly: there's a jump at 0x103f05dc5. I know what's going on. The OS forbids execution of memory in the heap. But, there is an extra flag, -Wl,-allow_stack_execute, that allows this permission. This is a misnamed flag, since we never execute code on the stack. I think it's really controlling heap execution, not stack execution. We need to pass this flag everywhere, whenever a program is compiled by gcj. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-03 10:26 ` Andrew Haley @ 2009-12-03 14:03 ` Jack Howarth 2009-12-03 14:10 ` Andrew Haley 2009-12-03 19:18 ` Boehm, Hans 0 siblings, 2 replies; 61+ messages in thread From: Jack Howarth @ 2009-12-03 14:03 UTC (permalink / raw) To: Andrew Haley; +Cc: borlum, java On Thu, Dec 03, 2009 at 10:25:30AM +0000, Andrew Haley wrote: > Jack Howarth wrote: > > On Wed, Dec 02, 2009 at 09:34:33AM +0000, Andrew Haley wrote: > >> Jack Howarth wrote: > >>> On Tue, Dec 01, 2009 at 05:24:29PM +0000, Andrew Haley wrote: > >>>> Jack Howarth wrote: > >>>>> On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote: > >>>>>> Jack Howarth wrote: > >>>>>> > >>>>>>> (gdb) > >>>>>>> 54 (*real_main) (args); > >>>>>>> (gdb) > >>>>>>> > >>>>>>> Program received signal EXC_BAD_ACCESS, Could not access memory. > >>>>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 > >>>>>>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > >>>>>>> 51 RowSetEvent.java: No such file or directory. > >>>>>>> in RowSetEvent.java > >>>>>>> (gdb) > >>>>>>> > >>>>>>> A backtrace only shows... > >>>>>>> > >>>>>>> (gdb) bt > >>>>>>> #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > >>>>>>> #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 > >>>>>>> Previous frame inner to this frame (gdb could not unwind past this frame) > >>>>>>> > >>>>>>> Let me know if you have any suggestions for debugging this further. > >>>>>> Disassemble the first 10 or so instructions at the instruction where the > >>>>>> EXC_BAD_ACCESS occurs. I think this is a libffi bug. > >>>>>> > >>>>>> Andrew. > >>>>> Andrew, > >>>>> So just to clarify, for the instance of... > >>>>> > >>>>> ------------------- > >>>>> > >>>>> (gdb) > >>>>> 0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258 > >>>>> 258 return (mod & PUBLIC) != 0; > >>>>> (gdb) > >>>>> gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 > >>>>> 46 msg = "`main' must be public"; > >>>>> (gdb) > >>>>> 45 else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags)) > >>>>> (gdb) > >>>>> 54 (*real_main) (args); > >>>>> (gdb) > >>>>> > >>>>> Program received signal EXC_BAD_ACCESS, Could not access memory. > >>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 > >>>>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > >>>>> 51 RowSetEvent.java: No such file or directory. > >>>>> in RowSetEvent.java > >>>>> (gdb) > >>>>> > >>>>> A backtrace only shows... > >>>>> > >>>>> (gdb) bt > >>>>> #0 0x0000000103f05db0 in ?? () at RowSetEvent.java:51 > >>>>> #1 0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 > >>>>> Previous frame inner to this frame (gdb could not unwind past this frame) > >>>>> > >>>>> ----------------- > >>>>> > >>>>> I want to disassemble from 0x00000001000485be, right? > >>>> 0x0000000103f05db0, where the fault happens. I think it's a libffi stub, > >>>> and I think its page permissions are not correctly set. > >>>> > >>>> But let's see. > >>>> > >>>> What I would do is, at > >>>> > >>>>> 54 (*real_main) (args); > >>>> disassemble the call instruction, it's probably call ($rax) or somesuch. > >>>> look in $rax with > >>>> > >>>> p $rax > >>>> > >>>> and disassemble from the address that's in there. > >>>> > >>>> Andrew. > >>> Andrew, > >>> I can't disassemble 0x0000000103f05db0... > >>> > >>> (gdb) disassemble 0x0000000103f05db0 > >>> No function contains specified address. > >> x/10i 0x0000000103f05db0 > >> > >> Andrew. > > > > Andrew, > > Okay, I see... > > > > gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 > > ... > > gdb) break ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 > > Breakpoint 1 at 0x20c49ba4b0a5ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46. > > (gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar > > Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar > > warning: posix_spawn failed, trying execvp, error: 86 > > Reading symbols for shared libraries +++++.. done > > Breakpoint 1 at 0x1000485ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46. > > > > Breakpoint 1, gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46 > > 46 msg = "`main' must be public"; > > (gdb) s > > Current language: auto; currently c++ > > 45 else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags)) > > (gdb) s > > 54 (*real_main) (args); > > (gdb) x/10i 0x0000000103f05db0 > > 0x103f05db0: mov $0x1009814e8,%r11 > > 0x103f05dba: mov $0x103f05db0,%r10 > > 0x103f05dc4: clc > > 0x103f05dc5: rex.WB jmpq *%r11 > > 0x103f05dc8: add %bl,-0x10(%rsi) > > 0x103f05dcb: add (%rcx),%eax > > 0x103f05dcd: add %al,(%rax) > > 0x103f05dcf: add %ah,%al > > 0x103f05dd1: (bad) > > 0x103f05dd2: cwtl > > (gdb) bt > > #0 gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54 > > #1 0x0000000104875dc0 in ?? () at ClassHelper.java:106 > > #2 0x0000000104875f00 in ?? () at ClassHelper.java:106 > > #3 0x000000010493e980 in ?? () at ClassHelper.java:106 > > #4 0x00000001000b1b74 in _ZN3gnu4java4lang10MainThread3runEJvv (this=0x104875dc0) at MainThread.java:106 > > Previous frame inner to this frame (gdb could not unwind past this frame) > > (gdb) p $rax > > $1 = 1 > > > > (gdb) s > > > > Program received signal EXC_BAD_ACCESS, Could not access memory. > > Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0 > > 0x0000000103f05db0 in ?? () at ClassHelper.java:106 > > 106 ClassHelper.java: No such file or directory. > > in ClassHelper.java > > > > What do you make of the bad assembly at 0x103f05dd1? > > There is no bad assembly: there's a jump at 0x103f05dc5. > > I know what's going on. > > The OS forbids execution of memory in the heap. But, there is an extra > flag, -Wl,-allow_stack_execute, that allows this permission. This is > a misnamed flag, since we never execute code on the stack. I think it's > really controlling heap execution, not stack execution. > > We need to pass this flag everywhere, whenever a program is compiled by > gcj. > > Andrew. Andrew, This sounds like the patch that Andreas proposed in... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3 which didn't solve the problem on my MacPro or MacBook Pro under darwin9 or darwin10. He also ran into the issue again later... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c17 Do you think that -Wl,-allow_stack_execute needs to be passed even more widely than on just ecjx_LDFLAGS? Any suggestions as to where I should be passing it? Perhaps on something like LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of libjava? Or should we even be building libffi and boehm-gc with that as well? Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-03 14:03 ` Jack Howarth @ 2009-12-03 14:10 ` Andrew Haley 2009-12-03 19:18 ` Boehm, Hans 1 sibling, 0 replies; 61+ messages in thread From: Andrew Haley @ 2009-12-03 14:10 UTC (permalink / raw) To: Jack Howarth; +Cc: borlum, java Jack Howarth wrote: > On Thu, Dec 03, 2009 at 10:25:30AM +0000, Andrew Haley wrote: >> Jack Howarth wrote: >>> On Wed, Dec 02, 2009 at 09:34:33AM +0000, Andrew Haley wrote: >>>> Jack Howarth wrote: >>>>> On Tue, Dec 01, 2009 at 05:24:29PM +0000, Andrew Haley wrote: >>>>>> Jack Howarth wrote: >>>>>>> On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote: >>> >>> What do you make of the bad assembly at 0x103f05dd1? >> There is no bad assembly: there's a jump at 0x103f05dc5. >> >> I know what's going on. >> >> The OS forbids execution of memory in the heap. But, there is an extra >> flag, -Wl,-allow_stack_execute, that allows this permission. This is >> a misnamed flag, since we never execute code on the stack. I think it's >> really controlling heap execution, not stack execution. >> >> We need to pass this flag everywhere, whenever a program is compiled by >> gcj. >> >> Andrew. > > Andrew, > This sounds like the patch that Andreas proposed in... > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3 > > which didn't solve the problem on my MacPro or MacBook Pro > under darwin9 or darwin10. He also ran into the issue again > later... > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c17 > > Do you think that -Wl,-allow_stack_execute needs to be passed > even more widely than on just ecjx_LDFLAGS? Any suggestions as > to where I should be passing it? Perhaps on something like > LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of libjava? Or should > we even be building libffi and boehm-gc with that as well? I don't see =-Wl,-allow_stack_execute passed to anything except when linking gij. That's why IMO gij works but nothing else does. This needs to be everywhere, for all programs. I think SYSTEMSPEC would do it, or add a new linker configure variable. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* RE: [patch] Fix oddity in personality routine 2009-12-03 14:03 ` Jack Howarth 2009-12-03 14:10 ` Andrew Haley @ 2009-12-03 19:18 ` Boehm, Hans 2009-12-03 21:25 ` Andrew Haley 1 sibling, 1 reply; 61+ messages in thread From: Boehm, Hans @ 2009-12-03 19:18 UTC (permalink / raw) To: Jack Howarth, Andrew Haley; +Cc: borlum, java > From: Jack Howarth > Do you think that -Wl,-allow_stack_execute needs to be > passed even more widely than on just ecjx_LDFLAGS? Any > suggestions as to where I should be passing it? Perhaps on > something like LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of > libjava? Or should we even be building libffi and boehm-gc > with that as well? > Jack > > I haven't been following this completely, but: The GC also has a compile-time flag NO_EXECUTE_PERMISSION, which affects heap executability. I think the documentation says that this only affects incremental collection, but looking at the code, I'm not sure I believe that anymore. I think it generally affects whether memory allocated with mmap is made executable, and we've been doing more and more of that. Hans ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-03 19:18 ` Boehm, Hans @ 2009-12-03 21:25 ` Andrew Haley 2009-12-04 3:01 ` Jack Howarth 2009-12-04 4:12 ` Jack Howarth 0 siblings, 2 replies; 61+ messages in thread From: Andrew Haley @ 2009-12-03 21:25 UTC (permalink / raw) To: Boehm, Hans; +Cc: Jack Howarth, borlum, java Boehm, Hans wrote: >> From: Jack Howarth >> Do you think that -Wl,-allow_stack_execute needs to be >> passed even more widely than on just ecjx_LDFLAGS? Any >> suggestions as to where I should be passing it? Perhaps on >> something like LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of >> libjava? Or should we even be building libffi and boehm-gc >> with that as well? >> > I haven't been following this completely, but: > > The GC also has a compile-time flag NO_EXECUTE_PERMISSION, which affects heap executability. I think that's probably not the cause, since libffi allocates memory itself. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-03 21:25 ` Andrew Haley @ 2009-12-04 3:01 ` Jack Howarth 2009-12-04 9:45 ` Andrew Haley 2009-12-04 4:12 ` Jack Howarth 1 sibling, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-12-04 3:01 UTC (permalink / raw) To: Andrew Haley; +Cc: Boehm, Hans, borlum, java On Thu, Dec 03, 2009 at 09:25:11PM +0000, Andrew Haley wrote: > Boehm, Hans wrote: > >> From: Jack Howarth > >> Do you think that -Wl,-allow_stack_execute needs to be > >> passed even more widely than on just ecjx_LDFLAGS? Any > >> suggestions as to where I should be passing it? Perhaps on > >> something like LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of > >> libjava? Or should we even be building libffi and boehm-gc > >> with that as well? > >> > > I haven't been following this completely, but: > > > > The GC also has a compile-time flag NO_EXECUTE_PERMISSION, which affects heap executability. > > I think that's probably not the cause, since libffi allocates memory itself. > > Andrew. Andrew, On reflection, shouldn't something like... Index: libjava/Makefile.in =================================================================== --- libjava/Makefile.in (revision 154965) +++ libjava/Makefile.in (working copy) @@ -8500,8 +8500,7 @@ $(am__append_28) gij_SOURCES = gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \ - -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \ - $(extra_gij_ldflags) + -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) gij_LINK = $(GCJLINK) $(gij_LDFLAGS) gij_LDADD = -L$(here)/.libs libgij.la Index: libjava/Makefile.am =================================================================== --- libjava/Makefile.am (revision 154965) +++ libjava/Makefile.am (working copy) @@ -294,7 +294,7 @@ LTLDFLAGS = $(shell $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) GCJLINK = $(LIBTOOL) --tag=GCJ $(LIBTOOLFLAGS) --mode=link $(GCJ) -L$(here) \ - $(JC1FLAGS) $(LTLDFLAGS) -o $@ + $(extra_gij_ldflags) $(JC1FLAGS) $(LTLDFLAGS) -o $@ GCJ_FOR_ECJX = @GCJ_FOR_ECJX@ GCJ_FOR_ECJX_LINK = $(GCJ_FOR_ECJX) -o $@ LIBLINK = $(LIBTOOL) --tag=CXX $(LIBTOOLFLAGS) --mode=link $(CXX) -L$(here) \ @@ -1065,8 +1065,7 @@ ## need this because we are explicitly using libtool to link using the ## `.la' file. gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \ - -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \ - $(extra_gij_ldflags) + -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) gij_LINK = $(GCJLINK) $(gij_LDFLAGS) ## See jv_convert_LDADD. gij_LDADD = -L$(here)/.libs libgij.la ...be appropriate to make sure that all java executables on darwin are linked with -Wl,-allow_stack_execute? However, this raises the question of why the gcj and ecj1 compilers aren't doing the same? As I understand this, any executables created with libraries containing code that executes on the stack (like libgcj) needs to link the binaries with -Wl,-allow_stack_execute. Shouldn't this apply to gcj and ecj1 as well since they create executables which are linked against libgcj? Wouldn't we have to do this by adding the missing -allow_stack_execute flag to libjava/libgcj.spec.in? Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-04 3:01 ` Jack Howarth @ 2009-12-04 9:45 ` Andrew Haley 0 siblings, 0 replies; 61+ messages in thread From: Andrew Haley @ 2009-12-04 9:45 UTC (permalink / raw) To: Jack Howarth; +Cc: Boehm, Hans, borlum, java Jack Howarth wrote: > On Thu, Dec 03, 2009 at 09:25:11PM +0000, Andrew Haley wrote: >> Boehm, Hans wrote: >>>> From: Jack Howarth >>>> Do you think that -Wl,-allow_stack_execute needs to be >>>> passed even more widely than on just ecjx_LDFLAGS? Any >>>> suggestions as to where I should be passing it? Perhaps on >>>> something like LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of >>>> libjava? Or should we even be building libffi and boehm-gc >>>> with that as well? >>>> >>> I haven't been following this completely, but: >>> >>> The GC also has a compile-time flag NO_EXECUTE_PERMISSION, which affects heap executability. >> I think that's probably not the cause, since libffi allocates memory itself. >> >> Andrew. > > Andrew, > On reflection, shouldn't something like... > > Index: libjava/Makefile.in > =================================================================== > --- libjava/Makefile.in (revision 154965) > +++ libjava/Makefile.in (working copy) > @@ -8500,8 +8500,7 @@ > $(am__append_28) > gij_SOURCES = > gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \ > - -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \ > - $(extra_gij_ldflags) > + -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) > > gij_LINK = $(GCJLINK) $(gij_LDFLAGS) > gij_LDADD = -L$(here)/.libs libgij.la > Index: libjava/Makefile.am > =================================================================== > --- libjava/Makefile.am (revision 154965) > +++ libjava/Makefile.am (working copy) > @@ -294,7 +294,7 @@ > > LTLDFLAGS = $(shell $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) > GCJLINK = $(LIBTOOL) --tag=GCJ $(LIBTOOLFLAGS) --mode=link $(GCJ) -L$(here) \ > - $(JC1FLAGS) $(LTLDFLAGS) -o $@ > + $(extra_gij_ldflags) $(JC1FLAGS) $(LTLDFLAGS) -o $@ > GCJ_FOR_ECJX = @GCJ_FOR_ECJX@ > GCJ_FOR_ECJX_LINK = $(GCJ_FOR_ECJX) -o $@ > LIBLINK = $(LIBTOOL) --tag=CXX $(LIBTOOLFLAGS) --mode=link $(CXX) -L$(here) \ > @@ -1065,8 +1065,7 @@ > ## need this because we are explicitly using libtool to link using the > ## `.la' file. > gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \ > - -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \ > - $(extra_gij_ldflags) > + -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) > gij_LINK = $(GCJLINK) $(gij_LDFLAGS) > ## See jv_convert_LDADD. > gij_LDADD = -L$(here)/.libs libgij.la > > ...be appropriate to make sure that all java executables on darwin are linked with > -Wl,-allow_stack_execute? No, because it will only affect the binaries in gcj, not things the user compiles. That's why I suggested SYSTEMSPEC. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-03 21:25 ` Andrew Haley 2009-12-04 3:01 ` Jack Howarth @ 2009-12-04 4:12 ` Jack Howarth 2009-12-04 9:44 ` Andrew Haley 1 sibling, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-12-04 4:12 UTC (permalink / raw) To: Andrew Haley; +Cc: Boehm, Hans, borlum, java Using the patch... Index: libjava/Makefile.in =================================================================== --- libjava/Makefile.in (revision 154965) +++ libjava/Makefile.in (working copy) @@ -1070,7 +1070,7 @@ GCJ_WITH_FLAGS = $(GCJ) --encoding=UTF-8 -Wno-deprecated LTLDFLAGS = $(shell $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) GCJLINK = $(LIBTOOL) --tag=GCJ $(LIBTOOLFLAGS) --mode=link $(GCJ) -L$(here) \ - $(JC1FLAGS) $(LTLDFLAGS) -o $@ + $(extra_gij_ldflags) $(JC1FLAGS) $(LTLDFLAGS) -o $@ GCJ_FOR_ECJX_LINK = $(GCJ_FOR_ECJX) -o $@ LIBLINK = $(LIBTOOL) --tag=CXX $(LIBTOOLFLAGS) --mode=link $(CXX) -L$(here) \ @@ -8500,8 +8500,7 @@ $(am__append_28) gij_SOURCES = gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \ - -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \ - $(extra_gij_ldflags) + -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) gij_LINK = $(GCJLINK) $(gij_LDFLAGS) gij_LDADD = -L$(here)/.libs libgij.la Index: libjava/Makefile.am =================================================================== --- libjava/Makefile.am (revision 154965) +++ libjava/Makefile.am (working copy) @@ -294,7 +294,7 @@ LTLDFLAGS = $(shell $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) GCJLINK = $(LIBTOOL) --tag=GCJ $(LIBTOOLFLAGS) --mode=link $(GCJ) -L$(here) \ - $(JC1FLAGS) $(LTLDFLAGS) -o $@ + $(extra_gij_ldflags) $(JC1FLAGS) $(LTLDFLAGS) -o $@ GCJ_FOR_ECJX = @GCJ_FOR_ECJX@ GCJ_FOR_ECJX_LINK = $(GCJ_FOR_ECJX) -o $@ LIBLINK = $(LIBTOOL) --tag=CXX $(LIBTOOLFLAGS) --mode=link $(CXX) -L$(here) \ @@ -1065,8 +1065,7 @@ ## need this because we are explicitly using libtool to link using the ## `.la' file. gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \ - -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \ - $(extra_gij_ldflags) + -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) gij_LINK = $(GCJLINK) $(gij_LDFLAGS) ## See jv_convert_LDADD. gij_LDADD = -L$(here)/.libs libgij.la The crash in gcj still occurs but it may have moved location (I am under darwin10 at the moment). I see... gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/ecj1 (gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/share/xtal/ccp4-6.1.2/bin/:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc3tiRxo.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccsmjxPB.jar Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/share/xtal/ccp4-6.1.2/bin/:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc3tiRxo.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccsmjxPB.jar Reading symbols for shared libraries +++++. done Program received signal SIGABRT, Aborted. 0x00007fff843d4fe6 in __kill () (gdb) bt #0 0x00007fff843d4fe6 in __kill () #1 0x00007fff84475e32 in abort () #2 0x00007fff844bffc9 in _Unwind_FindEnclosingFunction () #3 0x000000010001091c in gnu::classpath::VMStackWalker::getCallingClassLoader (pc=0x10098c8ac) at ../../../gcc-4.5-20091203/libjava/gnu/classpath/natVMStackWalker.cc:104 Previous frame inner to this frame (gdb could not unwind past this frame) (gdb) x/10i 0x000000010001091c 0x10001091c <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+28>: mov %rax,%rbx 0x10001091f <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+31>: callq 0x100005cd0 <_ZN14_Jv_StackTrace14UpdateNCodeMapEv> 0x100010924 <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+36>: lea 0x1c7b4b5(%rip),%rax # 0x101c8bde0 <_ZN14_Jv_StackTrace8ncodeMapE> 0x10001092b <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+43>: mov %rbx,%rsi 0x10001092e <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+46>: mov (%rax),%rdi 0x100010931 <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+49>: mov (%rdi),%rdx 0x100010934 <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+52>: callq *0x60(%rdx) 0x100010937 <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+55>: test %rax,%rax 0x10001093a <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+58>: je 0x100010950 <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+80> 0x10001093c <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+60>: mov 0xa8(%rax),%rax This is interesting since on x86_64-apple-darwin10, we have been failing... FAIL: WalkerTest execution - source compiled test FAIL: WalkerTest -findirect-dispatch execution - source compiled test FAIL: WalkerTest -O3 execution - source compiled test FAIL: WalkerTest -O3 -findirect-dispatch execution - source compiled test in the libjava testsuite. Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-04 4:12 ` Jack Howarth @ 2009-12-04 9:44 ` Andrew Haley 2009-12-04 14:51 ` Jack Howarth 0 siblings, 1 reply; 61+ messages in thread From: Andrew Haley @ 2009-12-04 9:44 UTC (permalink / raw) To: Jack Howarth; +Cc: Boehm, Hans, borlum, java Jack Howarth wrote: > Using the patch... Let's see the compile time output, when the executables were linked. > This is interesting since on x86_64-apple-darwin10, we have been failing... > > FAIL: WalkerTest execution - source compiled test > FAIL: WalkerTest -findirect-dispatch execution - source compiled test > FAIL: WalkerTest -O3 execution - source compiled test > FAIL: WalkerTest -O3 -findirect-dispatch execution - source compiled test Since when? You didn't mention this before. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-04 9:44 ` Andrew Haley @ 2009-12-04 14:51 ` Jack Howarth 2009-12-04 14:59 ` Andrew Haley 0 siblings, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-12-04 14:51 UTC (permalink / raw) To: Andrew Haley; +Cc: Boehm, Hans, borlum, java On Fri, Dec 04, 2009 at 09:44:29AM +0000, Andrew Haley wrote: > Jack Howarth wrote: > > Using the patch... > > Let's see the compile time output, when the executables were linked. > > > This is interesting since on x86_64-apple-darwin10, we have been failing... > > > > FAIL: WalkerTest execution - source compiled test > > FAIL: WalkerTest -findirect-dispatch execution - source compiled test > > FAIL: WalkerTest -O3 execution - source compiled test > > FAIL: WalkerTest -O3 -findirect-dispatch execution - source compiled test > > Since when? You didn't mention this before. > > Andrew. Andrew, I believe we have been seeing the additional WalkerTest failures under darwin10 ever since gcc trunk was fixed so that darwin10 built with stack execution like darwin9... http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01532.html However this may all be a red herring because x86_64-apple-darwin9 (which doesn't show these WalkerTest failures) shows the same issue with gcj crashing when compiling java code. I suspect we may have a layered problem here and need to work through each section. This weekend, I do some additional builds to verify that the crash debugs to the same locations in both darwin9 and darwin10 with and without the proposed patch to pass -Wl,-allow_stack_execute on GCJLINK. The WalkerTest failures in darwin10 may be orthogonal to the issue of gcj crashing since they don't occur in darwin9 and darwin9 has the gcj issue as well. I'll do some builds this weekend to verify that... 1) x86_64-apple-darwin9 still passes the WalkerTests 2) x86_64-apple-darwin9 and x86_64-apple-darwin10 both backtrace to the same place when gcj crashes compiling java code. 3) When the GCJLINK to patched to always pass -Wl,-allow_stack_execute that the backtrace moves to the same place in both x86_64-apple-darwin9 and x86_64-apple-darwin10. 4) I'll also back out the libgcc-ext patch completely and verify that x86_64-apple-darwin9 crashes at the same locations for step 2 and 3. This will verify that the system unwinder and the FSF libgcc unwinder both behave the same in these gcj crashes. Jack ps As I mentioned before, darwin10 uses an unwinder in libSystem which is derived from that in gcc 4.2.1. Also, since the libgcc_ext patch went into gcc trunk, darwin9 also links in the system libgcc_s.10.5 before the FSF libgcc_s so that it also now uses the system unwinder (from libgcc). However note that thse gcj crashes predate all of this. I have verified that they go as far back as gcc 4.3.4. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-04 14:51 ` Jack Howarth @ 2009-12-04 14:59 ` Andrew Haley 2009-12-04 15:23 ` Jack Howarth 0 siblings, 1 reply; 61+ messages in thread From: Andrew Haley @ 2009-12-04 14:59 UTC (permalink / raw) To: Jack Howarth; +Cc: Boehm, Hans, borlum, java Jack Howarth wrote: > On Fri, Dec 04, 2009 at 09:44:29AM +0000, Andrew Haley wrote: >> Jack Howarth wrote: >>> Using the patch... >> Let's see the compile time output, when the executables were linked. >> >>> This is interesting since on x86_64-apple-darwin10, we have been failing... >>> >>> FAIL: WalkerTest execution - source compiled test >>> FAIL: WalkerTest -findirect-dispatch execution - source compiled test >>> FAIL: WalkerTest -O3 execution - source compiled test >>> FAIL: WalkerTest -O3 -findirect-dispatch execution - source compiled test >> Since when? You didn't mention this before. > I believe we have been seeing the additional WalkerTest > failures under darwin10 ever since gcc trunk was fixed so > that darwin10 built with stack execution like darwin9... > > http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01532.html OK. I'm pretty sure this is a different failure. > However this may all be a red herring because x86_64-apple-darwin9 > (which doesn't show these WalkerTest failures) shows the > same issue with gcj crashing when compiling java code. > I suspect we may have a layered problem here and need > to work through each section. This weekend, I do some additional > builds to verify that the crash debugs to the same locations > in both darwin9 and darwin10 with and without the proposed > patch to pass -Wl,-allow_stack_execute on GCJLINK. Right. > The WalkerTest failures in darwin10 may be orthogonal to > the issue of gcj crashing since they don't occur in darwin9 > and darwin9 has the gcj issue as well. I'll do some builds this > weekend to verify that... > > 1) x86_64-apple-darwin9 still passes the WalkerTests > 2) x86_64-apple-darwin9 and x86_64-apple-darwin10 both backtrace > to the same place when gcj crashes compiling java code. > 3) When the GCJLINK to patched to always pass -Wl,-allow_stack_execute > that the backtrace moves to the same place in both x86_64-apple-darwin9 > and x86_64-apple-darwin10. Do you see the same page fault once -Wl,-allow_stack_execute is used? If not, this one is fixed, and we can look at the unwinder fproblem. > 4) I'll also back out the libgcc-ext patch completely and verify that > x86_64-apple-darwin9 crashes at the same locations for step 2 and 3. > This will verify that the system unwinder and the FSF libgcc unwinder > both behave the same in these gcj crashes. > ps As I mentioned before, darwin10 uses an unwinder in libSystem which > is derived from that in gcc 4.2.1. Also, since the libgcc_ext patch > went into gcc trunk, darwin9 also links in the system libgcc_s.10.5 > before the FSF libgcc_s so that it also now uses the system unwinder > (from libgcc). However note that thse gcj crashes predate all of this. > I have verified that they go as far back as gcc 4.3.4. OK. So, we may have just one bug left rather than two. Here's hoping. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-04 14:59 ` Andrew Haley @ 2009-12-04 15:23 ` Jack Howarth 2009-12-04 15:48 ` Andrew Haley 0 siblings, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-12-04 15:23 UTC (permalink / raw) To: Andrew Haley; +Cc: Boehm, Hans, borlum, java On Fri, Dec 04, 2009 at 02:59:43PM +0000, Andrew Haley wrote: > > > I suspect we may have a layered problem here and need > > to work through each section. This weekend, I do some additional > > builds to verify that the crash debugs to the same locations > > in both darwin9 and darwin10 with and without the proposed > > patch to pass -Wl,-allow_stack_execute on GCJLINK. > > Right. > Andrew, Just to double check, you do agree that everything linked with GCJLINK should be passed -Wl,-allow_stack_execute on darwin9/darwin10? I am a bit confused by the criteria used to determine which java binaries need the ld flag for -allow_stack_execute. If the a shared library contains code that needs to execute on the stack (libgcj) shouldn't any executable that links in that shared lib use the -allow_stack_execute ld flag? Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-04 15:23 ` Jack Howarth @ 2009-12-04 15:48 ` Andrew Haley 2009-12-04 15:57 ` Bryce McKinlay 2009-12-04 15:59 ` Jack Howarth 0 siblings, 2 replies; 61+ messages in thread From: Andrew Haley @ 2009-12-04 15:48 UTC (permalink / raw) To: Jack Howarth; +Cc: Boehm, Hans, borlum, java Jack Howarth wrote: > On Fri, Dec 04, 2009 at 02:59:43PM +0000, Andrew Haley wrote: >>> I suspect we may have a layered problem here and need >>> to work through each section. This weekend, I do some additional >>> builds to verify that the crash debugs to the same locations >>> in both darwin9 and darwin10 with and without the proposed >>> patch to pass -Wl,-allow_stack_execute on GCJLINK. >> Right. >> > > Andrew, > Just to double check, you do agree that everything linked with > GCJLINK should be passed -Wl,-allow_stack_execute on darwin9/darwin10? I think so. > I am a bit confused by the criteria used to determine which java binaries > need the ld flag for -allow_stack_execute. If the a shared library contains > code that needs to execute on the stack No gcj library needs to execute on the stack, only the heap. I think the flag is misnamed. > (libgcj) shouldn't any executable > that links in that shared lib use the -allow_stack_execute ld flag? Yes, which is why I suggested you use SYSTEMSPEC. (Twice now, I think. :-) SYSTEMSPEC should pass that flag to everything liked with gcj. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-04 15:48 ` Andrew Haley @ 2009-12-04 15:57 ` Bryce McKinlay 2009-12-05 4:37 ` Jack Howarth 2009-12-05 6:54 ` Jack Howarth 2009-12-04 15:59 ` Jack Howarth 1 sibling, 2 replies; 61+ messages in thread From: Bryce McKinlay @ 2009-12-04 15:57 UTC (permalink / raw) To: Andrew Haley; +Cc: Jack Howarth, Boehm, Hans, borlum, java [-- Attachment #1: Type: text/plain, Size: 406 bytes --] On Fri, Dec 4, 2009 at 3:48 PM, Andrew Haley <aph@redhat.com> wrote: > Yes, which is why I suggested you use SYSTEMSPEC. (Twice now, I think. :-) > > SYSTEMSPEC should pass that flag to everything liked with gcj. Jack, Here's a patch that adds the allow_stack_execute flag to SYSTEMSPEC as suggested by Andrew. It does not fix the problem with ecj, but I agree it's a good idea. Bryce [-- Attachment #2: libgcj-darwin-systemspec.patch --] [-- Type: application/octet-stream, Size: 11812 bytes --] Index: Makefile.in =================================================================== --- Makefile.in (revision 154954) +++ Makefile.in (working copy) @@ -819,7 +819,6 @@ docdir = @docdir@ dvidir = @dvidir@ exec_prefix = @exec_prefix@ -extra_gij_ldflags = @extra_gij_ldflags@ extra_ldflags = @extra_ldflags@ extra_ldflags_libjava = @extra_ldflags_libjava@ $(am__append_9) gcc_suffix = @gcc_suffix@ @@ -8500,8 +8499,7 @@ $(am__append_28) gij_SOURCES = gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \ - -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \ - $(extra_gij_ldflags) + -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) gij_LINK = $(GCJLINK) $(gij_LDFLAGS) gij_LDADD = -L$(here)/.libs libgij.la Index: configure.ac =================================================================== --- configure.ac (revision 154954) +++ configure.ac (working copy) @@ -889,6 +889,9 @@ SYSTEMSPEC="-lunicows $SYSTEMSPEC" fi ;; + *-*-darwin[[912]]*) + SYSTEMSPEC="-allow_stack_execute" + ;; *) SYSTEMSPEC= ;; @@ -919,9 +922,6 @@ # on Darwin -single_module speeds up loading of the dynamic libraries. extra_ldflags_libjava=-Wl,-single_module ;; -*-*-darwin[[912]]*) - extra_gij_ldflags=-Wl,-allow_stack_execute - ;; arm*linux*eabi) # Some of the ARM unwinder code is actually in libstdc++. We # could in principle replicate it in libgcj, but it's better to @@ -935,7 +935,6 @@ ;; esac AC_SUBST(extra_ldflags_libjava) -AC_SUBST(extra_gij_ldflags) AC_SUBST(extra_ldflags) AC_SUBST(LIBSTDCXXSPEC) Index: configure =================================================================== --- configure (revision 154954) +++ configure (working copy) @@ -843,7 +843,6 @@ LIBGCJTESTSPEC LIBSTDCXXSPEC extra_ldflags -extra_gij_ldflags extra_ldflags_libjava X_EXTRA_LIBS X_LIBS @@ -7511,13 +7510,13 @@ else lt_cv_nm_interface="BSD nm" echo "int some_variable = 0;" > conftest.$ac_ext - (eval echo "\"\$as_me:7514: $ac_compile\"" >&5) + (eval echo "\"\$as_me:7513: $ac_compile\"" >&5) (eval "$ac_compile" 2>conftest.err) cat conftest.err >&5 - (eval echo "\"\$as_me:7517: $NM \\\"conftest.$ac_objext\\\"\"" >&5) + (eval echo "\"\$as_me:7516: $NM \\\"conftest.$ac_objext\\\"\"" >&5) (eval "$NM \"conftest.$ac_objext\"" 2>conftest.err > conftest.out) cat conftest.err >&5 - (eval echo "\"\$as_me:7520: output\"" >&5) + (eval echo "\"\$as_me:7519: output\"" >&5) cat conftest.out >&5 if $GREP 'External.*some_variable' conftest.out > /dev/null; then lt_cv_nm_interface="MS dumpbin" @@ -8712,7 +8711,7 @@ ;; *-*-irix6*) # Find out which ABI we are using. - echo '#line 8715 "configure"' > conftest.$ac_ext + echo '#line 8714 "configure"' > conftest.$ac_ext if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_compile\""; } >&5 (eval $ac_compile) 2>&5 ac_status=$? @@ -10646,11 +10645,11 @@ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:10649: $lt_compile\"" >&5) + (eval echo "\"\$as_me:10648: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:10653: \$? = $ac_status" >&5 + echo "$as_me:10652: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings other than the usual output. @@ -10985,11 +10984,11 @@ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:10988: $lt_compile\"" >&5) + (eval echo "\"\$as_me:10987: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:10992: \$? = $ac_status" >&5 + echo "$as_me:10991: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings other than the usual output. @@ -11090,11 +11089,11 @@ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:11093: $lt_compile\"" >&5) + (eval echo "\"\$as_me:11092: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:11097: \$? = $ac_status" >&5 + echo "$as_me:11096: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -11145,11 +11144,11 @@ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:11148: $lt_compile\"" >&5) + (eval echo "\"\$as_me:11147: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:11152: \$? = $ac_status" >&5 + echo "$as_me:11151: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -13554,7 +13553,7 @@ lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 13557 "configure" +#line 13556 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -13650,7 +13649,7 @@ lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 13653 "configure" +#line 13652 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -15612,11 +15611,11 @@ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:15615: $lt_compile\"" >&5) + (eval echo "\"\$as_me:15614: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:15619: \$? = $ac_status" >&5 + echo "$as_me:15618: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings other than the usual output. @@ -15711,11 +15710,11 @@ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:15714: $lt_compile\"" >&5) + (eval echo "\"\$as_me:15713: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:15718: \$? = $ac_status" >&5 + echo "$as_me:15717: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -15763,11 +15762,11 @@ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:15766: $lt_compile\"" >&5) + (eval echo "\"\$as_me:15765: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:15770: \$? = $ac_status" >&5 + echo "$as_me:15769: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -17179,11 +17178,11 @@ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:17182: $lt_compile\"" >&5) + (eval echo "\"\$as_me:17181: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:17186: \$? = $ac_status" >&5 + echo "$as_me:17185: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings other than the usual output. @@ -17512,11 +17511,11 @@ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:17515: $lt_compile\"" >&5) + (eval echo "\"\$as_me:17514: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:17519: \$? = $ac_status" >&5 + echo "$as_me:17518: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings other than the usual output. @@ -17611,11 +17610,11 @@ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:17614: $lt_compile\"" >&5) + (eval echo "\"\$as_me:17613: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:17618: \$? = $ac_status" >&5 + echo "$as_me:17617: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -17663,11 +17662,11 @@ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:17666: $lt_compile\"" >&5) + (eval echo "\"\$as_me:17665: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:17670: \$? = $ac_status" >&5 + echo "$as_me:17669: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -19265,7 +19264,7 @@ enableval=$enable_sjlj_exceptions; : else cat > conftest.$ac_ext << EOF -#line 19268 "configure" +#line 19267 "configure" struct S { ~S(); }; void bar(); void foo() @@ -19595,6 +19594,9 @@ SYSTEMSPEC="-lunicows $SYSTEMSPEC" fi ;; + *-*-darwin[912]*) + SYSTEMSPEC="-allow_stack_execute" + ;; *) SYSTEMSPEC= ;; @@ -20346,9 +20348,6 @@ # on Darwin -single_module speeds up loading of the dynamic libraries. extra_ldflags_libjava=-Wl,-single_module ;; -*-*-darwin[912]*) - extra_gij_ldflags=-Wl,-allow_stack_execute - ;; arm*linux*eabi) # Some of the ARM unwinder code is actually in libstdc++. We # could in principle replicate it in libgcj, but it's better to @@ -20367,7 +20366,6 @@ - # Allow the GC to be disabled. Can be useful when debugging. { $as_echo "$as_me:${as_lineno-$LINENO}: checking for garbage collector to use" >&5 $as_echo_n "checking for garbage collector to use... " >&6; } Index: Makefile.am =================================================================== --- Makefile.am (revision 154954) +++ Makefile.am (working copy) @@ -1065,8 +1065,7 @@ ## need this because we are explicitly using libtool to link using the ## `.la' file. gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \ - -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \ - $(extra_gij_ldflags) + -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) gij_LINK = $(GCJLINK) $(gij_LDFLAGS) ## See jv_convert_LDADD. gij_LDADD = -L$(here)/.libs libgij.la ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-04 15:57 ` Bryce McKinlay @ 2009-12-05 4:37 ` Jack Howarth 2009-12-05 6:54 ` Jack Howarth 1 sibling, 0 replies; 61+ messages in thread From: Jack Howarth @ 2009-12-05 4:37 UTC (permalink / raw) To: Bryce McKinlay; +Cc: Andrew Haley, Boehm, Hans, borlum, java On Fri, Dec 04, 2009 at 03:57:11PM +0000, Bryce McKinlay wrote: > On Fri, Dec 4, 2009 at 3:48 PM, Andrew Haley <aph@redhat.com> wrote: > > > Yes, which is why I suggested you use SYSTEMSPEC. (Twice now, I think. :-) > > > > SYSTEMSPEC should pass that flag to everything liked with gcj. > > Jack, > > Here's a patch that adds the allow_stack_execute flag to SYSTEMSPEC as > suggested by Andrew. > > It does not fix the problem with ecj, but I agree it's a good idea. > > Bryce Bryce, Your proposed patch builds libjava normally on x86_64-apple-darwin10 and I now see... # # This spec file is read by gcj when linking. # It is used to specify the standard libraries we need in order # to link with libgcj. # %rename startfile startfileorig *startfile: %(startfileorig) %rename lib liborig *lib: %{s-bc-abi:} -lgcj -lm -L/sw/lib -liconv -lpthread -lz -allow_stack_execute -ldl %(libgcc) %(liborig) *jc1: -fhash-synchronization -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions in /sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.2.0/4.5.0/../../../libgcj.spec instead of... # # This spec file is read by gcj when linking. # It is used to specify the standard libraries we need in order # to link with libgcj. # %rename startfile startfileorig *startfile: %(startfileorig) %rename lib liborig *lib: %{s-bc-abi:} -lgcj -lm -L/sw/lib -liconv -lpthread -lz -ldl %(libgcc) %(liborig) *jc1: -fhash-synchronization -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions Linking with gcj -v also reveals that -allow_stack_execute is being passed to collect2 as expected. Can we get this in to gcc trunk as an obvious change? Jack ps Gcj still crashes compiling java as I saw yesterday with the alternative approach to passing -stack_allow_execute... [MacPro:~] howarth% gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/ecj1 GNU gdb 6.3.50-20050815 (Apple version gdb-1346) (Fri Sep 18 20:40:51 UTC 2009) Copyright 2004 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 "x86_64-apple-darwin"...Reading symbols for shared libraries ...... done warning: Could not find object file "/var/tmp//cckmtKiq.o" - no debug information available for "/var/tmp//cc4vWuF2.i". (gdb) break ../../../gcc-4.5-20091204/libjava/gnu/classpath/natVMStackWalker.cc:104 Breakpoint 1 at 0x20c49ba4ad2864: file ../../../gcc-4.5-20091204/libjava/gnu/classpath/natVMStackWalker.cc, line 104. Breakpoint 2 at 0x20c49ba4ad28a0: file ../../../gcc-4.5-20091204/libjava/gnu/classpath/natVMStackWalker.cc, line 104. warning: Multiple breakpoints were set. Use the "delete" command to delete unwanted breakpoints. (gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/share/xtal/ccp4-6.1.2/bin/:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccf5cqZS.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccK4ZxH8.jar Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/share/xtal/ccp4-6.1.2/bin/:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccf5cqZS.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccK4ZxH8.jar Reading symbols for shared libraries +++++. done Breakpoint 1, gnu::classpath::VMStackWalker::getCallingClassLoader (pc=0x10098d774) at ../../../gcc-4.5-20091204/libjava/gnu/classpath/natVMStackWalker.cc:104 104 jclass klass = GET_CALLING_CLASS(pc); (gdb) s Current language: auto; currently c++ 0x0000000100994db2 in dyld_stub__Unwind_FindEnclosingFunction () (gdb) s Single stepping until exit from function dyld_stub__Unwind_FindEnclosingFunction, which has no line number information. 0x00007fff844bffc0 in _Unwind_FindEnclosingFunction () (gdb) s Single stepping until exit from function _Unwind_FindEnclosingFunction, which has no line number information. Program received signal SIGABRT, Aborted. 0x00007fff843d4fe6 in __kill () (gdb) I'll repeat this build on x86_64-apple-darwin9 tomorrow to verify that in both darwin9 and darwin10 (with the proper passing of -allow_stack_execute) that the crash has moved to the same location and update the PR. Thanks again for the patch. Jack ps After I verify that stock gcc trunk behaves the same under darwin9 with the above patch, I'll rebuild gcc trunk with the libgcc_ext changes regressed out to verify that the FSF libgcc and the system libgcc unwinder are both failing in the same manner on darwin9. This will also allow me to walk the unwinder (as unfortunately Apple's libgcc and libSystem unwinders don't ship with debug code...sigh). ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-04 15:57 ` Bryce McKinlay 2009-12-05 4:37 ` Jack Howarth @ 2009-12-05 6:54 ` Jack Howarth 1 sibling, 0 replies; 61+ messages in thread From: Jack Howarth @ 2009-12-05 6:54 UTC (permalink / raw) To: Bryce McKinlay; +Cc: Andrew Haley, Boehm, Hans, borlum, java On Fri, Dec 04, 2009 at 03:57:11PM +0000, Bryce McKinlay wrote: > On Fri, Dec 4, 2009 at 3:48 PM, Andrew Haley <aph@redhat.com> wrote: > > > Yes, which is why I suggested you use SYSTEMSPEC. (Twice now, I think. :-) > > > > SYSTEMSPEC should pass that flag to everything liked with gcj. > > Jack, > > Here's a patch that adds the allow_stack_execute flag to SYSTEMSPEC as > suggested by Andrew. > > It does not fix the problem with ecj, but I agree it's a good idea. > > Bryce Bryce, Your patch eliminates the crashes in gcj completely for gcc trunk on x86_64-apple-darwin9 if I also regress out r154282 and r154283 so that the FSF libgcc's unwinder is used again. So we are starting to peel the layers off of the problem. Your patch definitely should go into gcc trunk and gcc 4.4 branch (where it will be immediately useful on darwin9 since the libgcc_ext changes don't exist there). In case you are unaware, the r154282 and r154283 commits introduced a new libgcc_ext shared library on darwin to provide the additional symbols that have been added to libgcc since the libgcc 10.4 and 10.5 stubs were defined. One 'feature' of this change is that both the system libgcc and the FSF libgcc are linked in. The logic is that since the 10.4/10.5 stubs are no longer built on FSF gcc trunk, those symbols will be provided by the first libgcc to be linked in (which is the system's). The second libgcc_s linked in comes from FSF gcc and provides the additional symbols via the 10.4/10.5 libgcc_ext stubs. Mike Stump approved the logic of all of this. I will revert back to the r154282 and r154283 commits being in place under darwin9. When the system libgcc is used under darwin9 (which is now the default behavior in gcc trunk for darwin), gcj crashes with your patch in place when compiling java code... Breakpoint 1 (./../../gcc-4.5-20091204/libjava/exception.cc:128) pending. (gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccamdOl5.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccaNqaGi.jar Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccamdOl5.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccaNqaGi.jar warning: posix_spawn failed, trying execvp, error: 86 Reading symbols for shared libraries ++++.+. done Program received signal SIGABRT, Aborted. 0x00007fff810c3f16 in __kill () (gdb) bt #0 0x00007fff810c3f16 in __kill () #1 0x00007fff81134f6d in abort () #2 0x000000010001342b in _Jv_Throw (value=0x10483e6c0) at ../../../gcc-4.5-20091204/libjava/exception.cc:128 Previous frame inner to this frame (gdb could not unwind past this frame) This crash appears to be different from that seen under darwin10. That might not be surprising as the unwinder is a different one subsumed into libSystem in that case. Unfortunately it won't be trivial to get debug code for the system unwinder. Hopefully, I can just use the approach of examining the assembly at the address of the crash to define the scope of the problem in both darwin9 and darwin10. In any case, we have made significant progress towards solving PR41991. Thanks in advance for any help in getting your patch into gcc trunk and 4.4 branch as an obvious fix. Jack ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-04 15:48 ` Andrew Haley 2009-12-04 15:57 ` Bryce McKinlay @ 2009-12-04 15:59 ` Jack Howarth 2009-12-04 16:06 ` Andrew Haley 1 sibling, 1 reply; 61+ messages in thread From: Jack Howarth @ 2009-12-04 15:59 UTC (permalink / raw) To: Andrew Haley; +Cc: Boehm, Hans, borlum, java On Fri, Dec 04, 2009 at 03:48:03PM +0000, Andrew Haley wrote: > Jack Howarth wrote: > > On Fri, Dec 04, 2009 at 02:59:43PM +0000, Andrew Haley wrote: > >>> I suspect we may have a layered problem here and need > >>> to work through each section. This weekend, I do some additional > >>> builds to verify that the crash debugs to the same locations > >>> in both darwin9 and darwin10 with and without the proposed > >>> patch to pass -Wl,-allow_stack_execute on GCJLINK. > >> Right. > >> > > > > Andrew, > > Just to double check, you do agree that everything linked with > > GCJLINK should be passed -Wl,-allow_stack_execute on darwin9/darwin10? > > I think so. > > > I am a bit confused by the criteria used to determine which java binaries > > need the ld flag for -allow_stack_execute. If the a shared library contains > > code that needs to execute on the stack > > No gcj library needs to execute on the stack, only the heap. I think the flag > is misnamed. > > > (libgcj) shouldn't any executable > > that links in that shared lib use the -allow_stack_execute ld flag? > > Yes, which is why I suggested you use SYSTEMSPEC. (Twice now, I think. :-) > > SYSTEMSPEC should pass that flag to everything liked with gcj. > > Andrew. Andrew, I tried SYSTEMSPEC last night and it didn't eliminate the crashes in gcj. I'll double check that tonight and specifically look for when libtool is using gcj to link to make sure the -allow_stack_execute flag is invoked. If so, I'll make sure that the location of the crash in gcj has shifted as it did when passing -Wl,-allow_stack_execute on GCJLINK. Jack ps Should I take this to mean that SYSTEMSPEC will cause gcj to automatically pass -Wl,-allow_stack_execute when it links code? I assume I should be able to see that with -v being pased to gcj. What confuses me is that gcj -v shows ejc1 being invoked. So does ecj1 get the -Wl,-allow_stack_execute passed on from gcj or should it be invoking -Wl,-allow_stack_execute on its own from SYSTEMSPEC? ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [patch] Fix oddity in personality routine 2009-12-04 15:59 ` Jack Howarth @ 2009-12-04 16:06 ` Andrew Haley 0 siblings, 0 replies; 61+ messages in thread From: Andrew Haley @ 2009-12-04 16:06 UTC (permalink / raw) To: Jack Howarth; +Cc: Boehm, Hans, borlum, java Jack Howarth wrote: > On Fri, Dec 04, 2009 at 03:48:03PM +0000, Andrew Haley wrote: >> Jack Howarth wrote: >>> On Fri, Dec 04, 2009 at 02:59:43PM +0000, Andrew Haley wrote: >>>>> I suspect we may have a layered problem here and need >>>>> to work through each section. This weekend, I do some additional >>>>> builds to verify that the crash debugs to the same locations >>>>> in both darwin9 and darwin10 with and without the proposed >>>>> patch to pass -Wl,-allow_stack_execute on GCJLINK. >>>> Right. >>>> >>> Andrew, >>> Just to double check, you do agree that everything linked with >>> GCJLINK should be passed -Wl,-allow_stack_execute on darwin9/darwin10? >> I think so. >> >>> I am a bit confused by the criteria used to determine which java binaries >>> need the ld flag for -allow_stack_execute. If the a shared library contains >>> code that needs to execute on the stack >> No gcj library needs to execute on the stack, only the heap. I think the flag >> is misnamed. >> >>> (libgcj) shouldn't any executable >>> that links in that shared lib use the -allow_stack_execute ld flag? >> Yes, which is why I suggested you use SYSTEMSPEC. (Twice now, I think. :-) >> >> SYSTEMSPEC should pass that flag to everything liked with gcj. > I tried SYSTEMSPEC last night and it didn't eliminate the crashes in gcj. I'll double > check that tonight and specifically look for when libtool is using gcj to link to make > sure the -allow_stack_execute flag is invoked. If so, I'll make sure that the location of > the crash in gcj has shifted as it did when passing -Wl,-allow_stack_execute on GCJLINK. OK. > ps Should I take this to mean that SYSTEMSPEC will cause gcj to automatically pass > -Wl,-allow_stack_execute when it links code? I assume I should be able to see that with > -v being pased to gcj. Yes. This should work everywhere, all the time. > What confuses me is that gcj -v shows ejc1 being invoked. Yes. > So does ecj1 get the -Wl,-allow_stack_execute passed on from gcj or should it be invoking > -Wl,-allow_stack_execute on its own from SYSTEMSPEC? ecj1 doesn't get passed -allow_stack_execute, the linker does. Adding -allow_stack_execute to SYSTEMSPEC will make sure that the linker is always passed this command. Bryce's patch is right, I think. Andrew. ^ permalink raw reply [flat|nested] 61+ messages in thread
end of thread, other threads:[~2009-12-05 6:54 UTC | newest] Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-11-13 17:49 [patch] Fix oddity in personality routine Eric Botcazou 2009-11-13 17:57 ` Andrew Haley 2009-11-13 18:36 ` Jack Howarth 2009-11-13 18:39 ` Andrew Haley 2009-11-13 19:18 ` Jack Howarth 2009-11-15 23:02 ` Bryce McKinlay 2009-11-16 14:22 ` Jack Howarth 2009-11-16 15:12 ` Jack Howarth 2009-11-16 15:17 ` Andrew Haley 2009-11-16 15:34 ` Jack Howarth 2009-11-16 16:59 ` Andrew Haley 2009-11-16 18:07 ` Jack Howarth 2009-11-16 19:10 ` Andrew Haley 2009-11-16 19:48 ` Jack Howarth 2009-11-17 0:48 ` Jack Howarth 2009-11-17 10:59 ` Andrew Haley 2009-11-17 14:05 ` Jack Howarth 2009-11-17 14:56 ` Andrew Haley 2009-11-17 16:18 ` Jack Howarth 2009-11-17 16:22 ` Andrew Haley 2009-11-17 17:07 ` Jack Howarth 2009-11-17 17:14 ` Andrew Haley 2009-11-17 17:38 ` Jack Howarth 2009-11-27 10:37 ` borlum 2009-11-27 10:40 ` Andrew Haley 2009-11-27 10:52 ` borlum 2009-11-27 14:20 ` Bryce McKinlay 2009-11-27 16:29 ` Jack Howarth 2009-11-27 21:51 ` Jack Howarth 2009-11-28 10:43 ` Andrew Haley 2009-11-29 17:48 ` Jack Howarth 2009-11-29 18:01 ` Andrew Haley 2009-11-29 18:48 ` Jack Howarth 2009-11-30 10:09 ` Andrew Haley 2009-11-30 16:01 ` Jack Howarth 2009-11-30 16:07 ` Andrew Haley 2009-12-01 5:02 ` Jack Howarth 2009-12-01 9:30 ` Andrew Haley 2009-12-01 17:04 ` Jack Howarth 2009-12-01 17:24 ` Andrew Haley 2009-12-01 23:29 ` Jack Howarth 2009-12-02 9:34 ` Andrew Haley 2009-12-03 1:08 ` Jack Howarth 2009-12-03 10:26 ` Andrew Haley 2009-12-03 14:03 ` Jack Howarth 2009-12-03 14:10 ` Andrew Haley 2009-12-03 19:18 ` Boehm, Hans 2009-12-03 21:25 ` Andrew Haley 2009-12-04 3:01 ` Jack Howarth 2009-12-04 9:45 ` Andrew Haley 2009-12-04 4:12 ` Jack Howarth 2009-12-04 9:44 ` Andrew Haley 2009-12-04 14:51 ` Jack Howarth 2009-12-04 14:59 ` Andrew Haley 2009-12-04 15:23 ` Jack Howarth 2009-12-04 15:48 ` Andrew Haley 2009-12-04 15:57 ` Bryce McKinlay 2009-12-05 4:37 ` Jack Howarth 2009-12-05 6:54 ` Jack Howarth 2009-12-04 15:59 ` Jack Howarth 2009-12-04 16:06 ` Andrew Haley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).