rebaseall and cygstdc++-6.dll

rebaseall and cygstdc++-6.dll

[Chris Sutcliffe]

Hi All,

Just a heads up around an issue I encountered with rtorrent after 
executing rebaseall. I ran in to some forking issues so I executed 
rebaseall after which rtorrent started to crash constantly during 
various operations.  Through trial and error I narrowed it down to 
cygstdc++-6.dll being rebased.  As a result I updated rebaseall to 
exclude cygstdc++ (at line 110) by adding "-e '/cygstdc++-6.dll$/d'".

I'm not sure what the issue is with rebasing cygstdc++-6.dll, but I 
figured I should share my findings in case someone else runs in to a 
similar issue.

Chris

-- 
Chris Sutcliffe
ir0nh34d@gmail.com

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: rebaseall and cygstdc++-6.dll

[Dave Korn]

On 10/09/2011 02:57, Chris Sutcliffe wrote:
> Hi All,
> 
> Just a heads up around an issue I encountered with rtorrent after
> executing rebaseall. I ran in to some forking issues so I executed
> rebaseall after which rtorrent started to crash constantly during
> various operations.  Through trial and error I narrowed it down to
> cygstdc++-6.dll being rebased.  As a result I updated rebaseall to
> exclude cygstdc++ (at line 110) by adding "-e '/cygstdc++-6.dll$/d'".
> 
> I'm not sure what the issue is with rebasing cygstdc++-6.dll, but I
> figured I should share my findings in case someone else runs in to a
> similar issue.

  Is that the newest version that goes along with gcc-4.5.3-2?  Off the top of
my head I remember something like this happening before, but I thought we'd
fixed it.  I'll have to do some digging if it's still happening to the new one.

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: rebaseall and cygstdc++-6.dll

[Chris Sutcliffe]

On 10/09/2011 1:15 PM, Dave Korn wrote:
> On 10/09/2011 02:57, Chris Sutcliffe wrote:
>> I'm not sure what the issue is with rebasing cygstdc++-6.dll, but I
>> figured I should share my findings in case someone else runs in to a
>> similar issue.
>
>    Is that the newest version that goes along with gcc-4.5.3-2?  Off the top of
> my head I remember something like this happening before, but I thought we'd
> fixed it.  I'll have to do some digging if it's still happening to the new one.

Yes, that's with gcc-4.5.3-2.

Cheers,

Chris

-- 
Chris Sutcliffe
ir0nh34d@gmail.com

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: rebaseall and cygstdc++-6.dll

[Dave Korn]

On 11/09/2011 02:27, Chris Sutcliffe wrote:
> On 10/09/2011 1:15 PM, Dave Korn wrote:
>> On 10/09/2011 02:57, Chris Sutcliffe wrote:
>>> I'm not sure what the issue is with rebasing cygstdc++-6.dll, but I
>>> figured I should share my findings in case someone else runs in to a
>>> similar issue.
>>
>> Is that the newest version that goes along with gcc-4.5.3-2? Off the top
>> of my head I remember something like this happening before, but I thought
>>  we'd fixed it. I'll have to do some digging if it's still happening to
>> the new one.
> 
> Yes, that's with gcc-4.5.3-2.

  Tried building a C++ "hello world" and rebasing the cygstdc dll without any
untoward side effects.  It's also not the previous bug I was thinking of,
that's definitely long gone.

  I'm building rtorrent now to see if that shows it up for me.  Do you have a
copy of the bad DLL that you could send me off-list?

    cheers,
      DaveK

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: rebaseall and cygstdc++-6.dll

[Dave Korn]

On 11/09/2011 02:53, Dave Korn wrote:
> Do you have a copy of the bad DLL that you could send me off-list?

  Oh, also any of the resulting rtorrent .stackdump files you might have lying
around too.

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: rebaseall and cygstdc++-6.dll

[Yaakov (Cygwin/X)]

On Fri, 2011-09-09 at 21:57 -0400, Chris Sutcliffe wrote:
> Just a heads up around an issue I encountered with rtorrent after 
> executing rebaseall. I ran in to some forking issues so I executed 
> rebaseall after which rtorrent started to crash constantly during 
> various operations.  Through trial and error I narrowed it down to 
> cygstdc++-6.dll being rebased.  As a result I updated rebaseall to 
> exclude cygstdc++ (at line 110) by adding "-e '/cygstdc++-6.dll$/d'".
> 
> I'm not sure what the issue is with rebasing cygstdc++-6.dll, but I 
> figured I should share my findings in case someone else runs in to a 
> similar issue.

http://cygwin.com/ml/cygwin-developers/2011-07/msg00058.html ??


Yaakov



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: rebaseall and cygstdc++-6.dll

[Dave Korn]

On 13/09/2011 22:20, Yaakov (Cygwin/X) wrote:
> On Fri, 2011-09-09 at 21:57 -0400, Chris Sutcliffe wrote:
>> Just a heads up around an issue I encountered with rtorrent after 
>> executing rebaseall. I ran in to some forking issues so I executed 
>> rebaseall after which rtorrent started to crash constantly during 
>> various operations.  Through trial and error I narrowed it down to 
>> cygstdc++-6.dll being rebased.  As a result I updated rebaseall to 
>> exclude cygstdc++ (at line 110) by adding "-e '/cygstdc++-6.dll$/d'".
>>
>> I'm not sure what the issue is with rebasing cygstdc++-6.dll, but I 
>> figured I should share my findings in case someone else runs in to a 
>> similar issue.
> 
> http://cygwin.com/ml/cygwin-developers/2011-07/msg00058.html ??

  It sounds like the same problem Corinna saw.  It can't be the exact same bug
as the one she linked to there, because that fix went into binutils ages ago,
but it could conceivably be related.  It turns out that it can also happen
with DLLs that have been rebased down as well as up, after all.  I suspect a
typeinfo problem but am still investigating.

    cheers,
      DaveK

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: rebaseall and cygstdc++-6.dll

[Dave Korn]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

On 10/09/2011 02:57, Chris Sutcliffe wrote:
> Hi All,
> 
> Just a heads up around an issue I encountered with rtorrent after
> executing rebaseall. I ran in to some forking issues so I executed
> rebaseall after which rtorrent started to crash constantly during
> various operations.  Through trial and error I narrowed it down to
> cygstdc++-6.dll being rebased.  As a result I updated rebaseall to
> exclude cygstdc++ (at line 110) by adding "-e '/cygstdc++-6.dll$/d'".
> 
> I'm not sure what the issue is with rebasing cygstdc++-6.dll, but I
> figured I should share my findings in case someone else runs in to a
> similar issue.

  I finally nailed this one down.  Stray base relocs against references to
symbols in discarded COMDAT sections remaining in the .eh_frame data cause the
stack unwind lookup to get lost.  Sourceware CVS is down right now but I'll be
sending the attached to binutils when it's working again, and I've started
building a 4.5.3-3 release.

    cheers,
      DaveK


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: no-base-relocs-against-discarded-sections-patch.diff --]
[-- Type: text/x-c; name="no-base-relocs-against-discarded-sections-patch.diff", Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: rebaseall and cygstdc++-6.dll

[Dave Korn]

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]

On 25/09/2011 07:07, Dave Korn wrote:
>  Sourceware CVS is down right now but I'll be
> sending the attached to binutils when it's working again, 

  Yeah, d'oh.  Maybe I'll send the file with the actual patch in it, instead
of the fresh diff I tried to generate when CVS wasn't working!  Attached, JFTR.

    cheers,
      DaveK


[-- Attachment #2: no-base-relocs-against-discarded-sections.diff --]
[-- Type: text/x-c, Size: 712 bytes --]

--- pe-dll.c.orig	2011-09-25 03:11:10.906250000 +0100
+++ pe-dll.c	2011-09-25 03:11:10.781250000 +0100
@@ -1398,6 +1398,16 @@ generate_reloc (bfd *abfd, struct bfd_li
 		      else if (!blhe || blhe->type != bfd_link_hash_defined)
 			continue;
 		    }
+		  /* Nor for Dwarf FDE references to discarded sections.  */
+		  else if (bfd_is_abs_section (sym->section->output_section))
+		    {
+		      /* These are the same section names that
+			 _bfd_elf_default_action_discarded chooses to discard
+			 relocs against.  */
+		      if (!strcmp (s->name, ".eh_frame")
+			  || !strcmp (s->name, ".gcc_except_table"))
+			continue;
+		    }
 
 		  reloc_data[total_relocs].vma = sec_vma + relocs[i]->address;
 


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: rebaseall and cygstdc++-6.dll

[Chris Sutcliffe]

On 25 September 2011 02:07, Dave Korn wrote:
>  I finally nailed this one down.  Stray base relocs against references to
> symbols in discarded COMDAT sections remaining in the .eh_frame data cause the
> stack unwind lookup to get lost.  Sourceware CVS is down right now but I'll be
> sending the attached to binutils when it's working again, and I've started
> building a 4.5.3-3 release.

I'm confused, is the issue in binutils or gcc?  If the issue is in
binutils, is rebuilding gcc going to help?  Either way, glad you
nailed it!

Thank you,

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: rebaseall and cygstdc++-6.dll

[Dave Korn]

On 25/09/2011 21:31, Chris Sutcliffe wrote:
> On 25 September 2011 02:07, Dave Korn wrote:
>>  I finally nailed this one down.  Stray base relocs against references to
>> symbols in discarded COMDAT sections remaining in the .eh_frame data cause the
>> stack unwind lookup to get lost.  Sourceware CVS is down right now but I'll be
>> sending the attached to binutils when it's working again, and I've started
>> building a 4.5.3-3 release.
> 
> I'm confused, is the issue in binutils or gcc?  If the issue is in
> binutils, is rebuilding gcc going to help?  Either way, glad you
> nailed it!

  The problem is in binutils, and the fact that it generates base relocs for
entries from EH data that should be just ignored.

  http://sourceware.org/ml/binutils/2011-09/msg00174.html
contains more detail, if you want to ask more let's do it on the binutils list.

  So to answer your question: the gcc language-specific runtime DLLs have to
be built using the patched version of binutils, otherwise they break when they
get rebased; that's why I'm rebuilding the gcc packages - having already
locally rebuilt binutils.  This will only be a big issue for anyone who wants
to rebuild gcc from source themselves, the new packages I upload to the distro
will still work for everyone regardless of what binutils they have installed
and/or how or when or where they get rebased.

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: rebaseall and cygstdc++-6.dll

[Yaakov (Cygwin/X)]

On Mon, 2011-09-26 at 02:15 +0100, Dave Korn wrote:
>   The problem is in binutils, and the fact that it generates base relocs for
> entries from EH data that should be just ignored.
> 
>   http://sourceware.org/ml/binutils/2011-09/msg00174.html
> contains more detail, if you want to ask more let's do it on the binutils list.
> 
>   So to answer your question: the gcc language-specific runtime DLLs have to
> be built using the patched version of binutils, otherwise they break when they
> get rebased; that's why I'm rebuilding the gcc packages - having already
> locally rebuilt binutils.  This will only be a big issue for anyone who wants
> to rebuild gcc from source themselves, the new packages I upload to the distro
> will still work for everyone regardless of what binutils they have installed
> and/or how or when or where they get rebased.

Except that this issue doesn't affect only libstdc++, but any C++
library which throws exceptions (as I have seen on my system).  So we
really do need a patched binutils ASAP.


Yaakov



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: rebaseall and cygstdc++-6.dll

[Marco Atzeri]

On 9/26/2011 5:15 AM, Yaakov (Cygwin/X) wrote:
> On Mon, 2011-09-26 at 02:15 +0100, Dave Korn wrote:
>>    The problem is in binutils, and the fact that it generates base relocs for
>> entries from EH data that should be just ignored.
>>
>>    http://sourceware.org/ml/binutils/2011-09/msg00174.html
>> contains more detail, if you want to ask more let's do it on the binutils list.
>>
>>    So to answer your question: the gcc language-specific runtime DLLs have to
>> be built using the patched version of binutils, otherwise they break when they
>> get rebased; that's why I'm rebuilding the gcc packages - having already
>> locally rebuilt binutils.  This will only be a big issue for anyone who wants
>> to rebuild gcc from source themselves, the new packages I upload to the distro
>> will still work for everyone regardless of what binutils they have installed
>> and/or how or when or where they get rebased.
>
> Except that this issue doesn't affect only libstdc++, but any C++
> library which throws exceptions (as I have seen on my system).  So we
> really do need a patched binutils ASAP.
>

There is an easy way to identify such libraries ?
Just to know if I need to rebuild some of mines .

>
> Yaakov
>

Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: rebaseall and cygstdc++-6.dll

[Ryan Johnson]

On 26/09/2011 2:28 AM, Marco Atzeri wrote:
> On 9/26/2011 5:15 AM, Yaakov (Cygwin/X) wrote:
>> On Mon, 2011-09-26 at 02:15 +0100, Dave Korn wrote:
>>>    The problem is in binutils, and the fact that it generates base 
>>> relocs for
>>> entries from EH data that should be just ignored.
>>>
>>>    http://sourceware.org/ml/binutils/2011-09/msg00174.html
>>> contains more detail, if you want to ask more let's do it on the 
>>> binutils list.
>>>
>>>    So to answer your question: the gcc language-specific runtime 
>>> DLLs have to
>>> be built using the patched version of binutils, otherwise they break 
>>> when they
>>> get rebased; that's why I'm rebuilding the gcc packages - having 
>>> already
>>> locally rebuilt binutils.  This will only be a big issue for anyone 
>>> who wants
>>> to rebuild gcc from source themselves, the new packages I upload to 
>>> the distro
>>> will still work for everyone regardless of what binutils they have 
>>> installed
>>> and/or how or when or where they get rebased.
>>
>> Except that this issue doesn't affect only libstdc++, but any C++
>> library which throws exceptions (as I have seen on my system).  So we
>> really do need a patched binutils ASAP.
>>
>
> There is an easy way to identify such libraries ?
> Just to know if I need to rebuild some of mines .
If the problem affects any library which throws (as opposed to one which 
merely supports propagating/unwinding due to exceptions), then the 
presence of __cxa_throw in the output of nm would be a good indicator. 
If unwind handlers are also affected, then anything with a .eh_frame 
section is suspect (but that would be all C++ programs unless compiled 
in no-except mode).

Ryan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: rebaseall and cygstdc++-6.dll

[Dave Korn]

On 26/09/2011 04:15, Yaakov (Cygwin/X) wrote:
> On Mon, 2011-09-26 at 02:15 +0100, Dave Korn wrote:
>>   The problem is in binutils, and the fact that it generates base relocs for
>> entries from EH data that should be just ignored.
>>
>>   http://sourceware.org/ml/binutils/2011-09/msg00174.html
>> contains more detail, if you want to ask more let's do it on the binutils list.
>>
>>   So to answer your question: the gcc language-specific runtime DLLs have to
>> be built using the patched version of binutils, otherwise they break when they
>> get rebased; that's why I'm rebuilding the gcc packages - having already
>> locally rebuilt binutils.  This will only be a big issue for anyone who wants
>> to rebuild gcc from source themselves, the new packages I upload to the distro
>> will still work for everyone regardless of what binutils they have installed
>> and/or how or when or where they get rebased.
> 
> Except that this issue doesn't affect only libstdc++, but any C++
> library which throws exceptions (as I have seen on my system).  So we
> really do need a patched binutils ASAP.

  True.  And not just any library that throws exceptions, but any library that
might be in the call stack at the time an exception is thrown and through
which the libgcc eh code needs to unwind, so potentially even plain C
libraries could be affected in the presence of mixed-language callbacks.
That's a pretty rare combination fortunately, but most C++ libs that throw
exceptions should be considered at risk.

  (I'm running the gcc testsuites against DLLs built with the new code, then
I'm going to rebase them all and run the tests again, so it'll be a day or two
before that's all done and I can check the fix in, but it'll be in time for
the forthcoming 2.22 release).

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple