[patch] Fix oddity in personality routine

[Eric Botcazou-3]

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@...>

        * exception.cc (PERSONALITY_FUNCTION): Fix oversight.


--
Eric Botcazou

[p.diff]

---

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;

---

[Andrew Haley]

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@...>
>
> * exception.cc (PERSONALITY_FUNCTION): Fix oversight.
>

Yes, I think that's right.

Andrew.

[Jack Howarth-3]

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@...>
> >
> > * 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

[Andrew Haley]

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@...>
>>>
>>> * 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.

[Jack Howarth-3]

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@...>
>
> * 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

[Bryce McKinlay-3]

On Fri, Nov 13, 2009 at 7:17 PM, Jack Howarth <howarth@...> 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

[Jack Howarth-3]

On Sun, Nov 15, 2009 at 11:01:22PM +0000, Bryce McKinlay wrote:

> On Fri, Nov 13, 2009@7:17 PM, Jack Howarth <howarth@...> 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.

[Jack Howarth-3]

   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.

[Andrew Haley]

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.

[Jack Howarth-3]

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

[Andrew Haley]

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.

[Jack Howarth-3]

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

[Andrew Haley]

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.

[Jack Howarth-3]

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

[Jack Howarth-3]

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

[Andrew Haley]

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.

[Jack Howarth-3]

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

[Andrew Haley]

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.

[Jack Howarth-3]

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.

[Andrew Haley]

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.