Issues with latest rtorrent under Win7 x64 when attempting to package

Issues with latest rtorrent under Win7 x64 when attempting to package

[Chris Sutcliffe]

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

Hi All,

I've built the latest libtorrent / rtorrent, packaged it and tested it
on WinXP x86 with no issues.  I then attempted to test on Win7 x64 and
it's crashing constantly.  I've disabled Windows Defender and
uninstalled my antivirus software, done a rebaseall, and nothing seems
to help.  I'd appreciate any pointers on what to try next, as I'm at a
bit of a loss.

I've attached by cygcheck.out and would be more than happy to provide
an strace if that would be useful.

Thank you,

Chris

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

[-- Attachment #2: cygcheck.out --]
[-- Type: application/octet-stream, Size: 30347 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: Issues with latest rtorrent under Win7 x64 when attempting to package

[Chris Sutcliffe]

On 19 May 2011 11:40, Chris Sutcliffe wrote:
> I've built the latest libtorrent / rtorrent, packaged it and tested it
> on WinXP x86 with no issues.  I then attempted to test on Win7 x64 and
> it's crashing constantly.  I've disabled Windows Defender and
> uninstalled my antivirus software, done a rebaseall, and nothing seems
> to help.  I'd appreciate any pointers on what to try next, as I'm at a
> bit of a loss.

Creating a debug build hasn't helped either.  When it crashes it's
causing a stack dump, so doing a 'bt' in gdb just returns 'no stack'.

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: Issues with latest rtorrent under Win7 x64 when attempting to package

[Christopher Faylor]

On Thu, May 19, 2011 at 10:01:47PM -0400, Chris Sutcliffe wrote:
>On 19 May 2011 11:40, Chris Sutcliffe wrote:
>> I've built the latest libtorrent / rtorrent, packaged it and tested it
>> on WinXP x86 with no issues. ?I then attempted to test on Win7 x64 and
>> it's crashing constantly. ?I've disabled Windows Defender and
>> uninstalled my antivirus software, done a rebaseall, and nothing seems
>> to help. ?I'd appreciate any pointers on what to try next, as I'm at a
>> bit of a loss.
>
>Creating a debug build hasn't helped either.  When it crashes it's
>causing a stack dump, so doing a 'bt' in gdb just returns 'no stack'.

That probably means that it's forking.  You're debugging the parent
when the child is having problems.

The addresses in the stack dump can be decoded with gdb:

l *0xnnnnn
^
that's an "ell".

cgf

--
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: Issues with latest rtorrent under Win7 x64 when attempting to package

[Chris Sutcliffe]

On 20 May 2011 01:44, Christopher Faylor wrote:
> On Thu, May 19, 2011 at 10:01:47PM -0400, Chris Sutcliffe wrote:
>>Creating a debug build hasn't helped either.  When it crashes it's
>>causing a stack dump, so doing a 'bt' in gdb just returns 'no stack'.
>
> That probably means that it's forking.  You're debugging the parent
> when the child is having problems.
>
> The addresses in the stack dump can be decoded with gdb:
>
> l *0xnnnnn
> ^
> that's an "ell".

I've tried l *0xnnnn for each of the addresses in the stack dump:

Stack trace:
Frame     Function  Args
0028C77C  76D51A2C  (00000002, 7EFDE000, 00000000, 0000002F)
0028C798  76D54238  (00000002, 0028C7F0, 00000000, 0000002F)
0028C908  610BF0DD  (0028CA1C, 0028C980, 0028C960, 0028C940)
0028CA68  610BF7C0  (00000001, 020D9680, 020D96A0, 020D96C0)
0028CAB8  610C3545  (020D79F8, 0000B5F5, 00000000, 020EC060)
0028CD28  00405AA8  (61244184, 00000000, 0028CD68, 61007038)
0028CD68  61007038  (00000000, 0028CDA4, 61006980, 7EFDE000)
End of stack trace

Each time I get:

No source file for address 0xnnnnnn.

I've tried both the Frame and Function addresses.

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: Issues with latest rtorrent under Win7 x64 when attempting to package

[Christopher Faylor]

On Fri, May 20, 2011 at 12:51:24PM -0400, Chris Sutcliffe wrote:
>On 20 May 2011 01:44, Christopher Faylor wrote:
>> On Thu, May 19, 2011 at 10:01:47PM -0400, Chris Sutcliffe wrote:
>>>Creating a debug build hasn't helped either. ?When it crashes it's
>>>causing a stack dump, so doing a 'bt' in gdb just returns 'no stack'.
>>
>> That probably means that it's forking. ?You're debugging the parent
>> when the child is having problems.
>>
>> The addresses in the stack dump can be decoded with gdb:
>>
>> l *0xnnnnn
>> ^
>> that's an "ell".
>
>I've tried l *0xnnnn for each of the addresses in the stack dump:
>
>Stack trace:
>Frame     Function  Args
>0028C77C  76D51A2C  (00000002, 7EFDE000, 00000000, 0000002F)
>0028C798  76D54238  (00000002, 0028C7F0, 00000000, 0000002F)
>0028C908  610BF0DD  (0028CA1C, 0028C980, 0028C960, 0028C940)
>0028CA68  610BF7C0  (00000001, 020D9680, 020D96A0, 020D96C0)
>0028CAB8  610C3545  (020D79F8, 0000B5F5, 00000000, 020EC060)
>0028CD28  00405AA8  (61244184, 00000000, 0028CD68, 61007038)
>0028CD68  61007038  (00000000, 0028CDA4, 61006980, 7EFDE000)
>End of stack trace
>
>Each time I get:
>
>No source file for address 0xnnnnnn.
>
>I've tried both the Frame and Function addresses.

Sounds like you don't have cygwin1.dbg (in the the cygwin src package if
you're using a release or downloadable if you're using a snapshot) and
either your program is stripped or it isn't built with debugging.
FWIW, 0x00405AA8 is likely the address of some location in rtorrent.

cgf

--
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: Issues with latest rtorrent under Win7 x64 when attempting to package

[Chris Sutcliffe]

On 20 May 2011 13:15, Christopher Faylor wrote:
> On Fri, May 20, 2011 at 12:51:24PM -0400, Chris Sutcliffe wrote:
>>On 20 May 2011 01:44, Christopher Faylor wrote:
>>> On Thu, May 19, 2011 at 10:01:47PM -0400, Chris Sutcliffe wrote:
>>>>Creating a debug build hasn't helped either. ?When it crashes it's
>>>>causing a stack dump, so doing a 'bt' in gdb just returns 'no stack'.
>>>
>>> That probably means that it's forking. ?You're debugging the parent
>>> when the child is having problems.
>>>
>>> The addresses in the stack dump can be decoded with gdb:
>>>
>>> l *0xnnnnn
>>> ^
>>> that's an "ell".
>>
>>I've tried l *0xnnnn for each of the addresses in the stack dump:
>>
>>Stack trace:
>>Frame     Function  Args
>>0028C77C  76D51A2C  (00000002, 7EFDE000, 00000000, 0000002F)
>>0028C798  76D54238  (00000002, 0028C7F0, 00000000, 0000002F)
>>0028C908  610BF0DD  (0028CA1C, 0028C980, 0028C960, 0028C940)
>>0028CA68  610BF7C0  (00000001, 020D9680, 020D96A0, 020D96C0)
>>0028CAB8  610C3545  (020D79F8, 0000B5F5, 00000000, 020EC060)
>>0028CD28  00405AA8  (61244184, 00000000, 0028CD68, 61007038)
>>0028CD68  61007038  (00000000, 0028CDA4, 61006980, 7EFDE000)
>>End of stack trace
>>
>>Each time I get:
>>
>>No source file for address 0xnnnnnn.
>>
>>I've tried both the Frame and Function addresses.
>
> Sounds like you don't have cygwin1.dbg (in the the cygwin src package if
> you're using a release or downloadable if you're using a snapshot) and
> either your program is stripped or it isn't built with debugging.
> FWIW, 0x00405AA8 is likely the address of some location in rtorrent.

No luck with 0x00405AA8, but it could be in libtorrent.dll, which I
will also build with debugging info.  I did manage to find the
following (after loading the cygwin1.dbg symbols):

0x61007038 is in dll_crt0_1(void*)
(/ext/build/netrel/src/cygwin-1.7.9-1/winsup/cygwin/dcrt0.cc:974).
969     /ext/build/netrel/src/cygwin-1.7.9-1/winsup/cygwin/dcrt0.cc:
No such file or directory.
        in /ext/build/netrel/src/cygwin-1.7.9-1/winsup/cygwin/dcrt0.cc

However my Cygwin source is in /usr as opposed to /ext/build/netrel,
is there a way to tell gdb to look there instead?

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: Issues with latest rtorrent under Win7 x64 when attempting to package

[Christopher Faylor]

On Fri, May 20, 2011 at 01:38:42PM -0400, Chris Sutcliffe wrote:
>On 20 May 2011 13:15, Christopher Faylor wrote:
>> On Fri, May 20, 2011 at 12:51:24PM -0400, Chris Sutcliffe wrote:
>>>On 20 May 2011 01:44, Christopher Faylor wrote:
>>>> On Thu, May 19, 2011 at 10:01:47PM -0400, Chris Sutcliffe wrote:
>>>>>Creating a debug build hasn't helped either. ?When it crashes it's
>>>>>causing a stack dump, so doing a 'bt' in gdb just returns 'no stack'.
>>>>
>>>> That probably means that it's forking. ?You're debugging the parent
>>>> when the child is having problems.
>>>>
>>>> The addresses in the stack dump can be decoded with gdb:
>>>>
>>>> l *0xnnnnn
>>>> ^
>>>> that's an "ell".
>>>
>>>I've tried l *0xnnnn for each of the addresses in the stack dump:
>>>
>>>Stack trace:
>>>Frame ? ? Function ?Args
>>>0028C77C ?76D51A2C ?(00000002, 7EFDE000, 00000000, 0000002F)
>>>0028C798 ?76D54238 ?(00000002, 0028C7F0, 00000000, 0000002F)
>>>0028C908 ?610BF0DD ?(0028CA1C, 0028C980, 0028C960, 0028C940)
>>>0028CA68 ?610BF7C0 ?(00000001, 020D9680, 020D96A0, 020D96C0)
>>>0028CAB8 ?610C3545 ?(020D79F8, 0000B5F5, 00000000, 020EC060)
>>>0028CD28 ?00405AA8 ?(61244184, 00000000, 0028CD68, 61007038)
>>>0028CD68 ?61007038 ?(00000000, 0028CDA4, 61006980, 7EFDE000)
>>>End of stack trace
>>>
>>>Each time I get:
>>>
>>>No source file for address 0xnnnnnn.
>>>
>>>I've tried both the Frame and Function addresses.
>>
>> Sounds like you don't have cygwin1.dbg (in the the cygwin src package if
>> you're using a release or downloadable if you're using a snapshot) and
>> either your program is stripped or it isn't built with debugging.
>> FWIW, 0x00405AA8 is likely the address of some location in rtorrent.
>
>No luck with 0x00405AA8, but it could be in libtorrent.dll, which I
>will also build with debugging info.  I did manage to find the
>following (after loading the cygwin1.dbg symbols):
>
>0x61007038 is in dll_crt0_1(void*)
>(/ext/build/netrel/src/cygwin-1.7.9-1/winsup/cygwin/dcrt0.cc:974).
>969     /ext/build/netrel/src/cygwin-1.7.9-1/winsup/cygwin/dcrt0.cc:
>No such file or directory.
>        in /ext/build/netrel/src/cygwin-1.7.9-1/winsup/cygwin/dcrt0.cc
>
>However my Cygwin source is in /usr as opposed to /ext/build/netrel,
>is there a way to tell gdb to look there instead?

Yes: "info gdb" or "help" in gdb will tell you how.  In "info gdb" look
for "Source" and then "Source Path".

cgf

--
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: Issues with latest rtorrent under Win7 x64 when attempting to package

[Chris Sutcliffe]

On 20 May 2011 13:44, Christopher Faylor wrote:
> On Fri, May 20, 2011 at 01:38:42PM -0400, Chris Sutcliffe wrote:
>>No luck with 0x00405AA8, but it could be in libtorrent.dll, which I
>>will also build with debugging info.  I did manage to find the
>>following (after loading the cygwin1.dbg symbols):
>>
>>0x61007038 is in dll_crt0_1(void*)
>>(/ext/build/netrel/src/cygwin-1.7.9-1/winsup/cygwin/dcrt0.cc:974).
>>969     /ext/build/netrel/src/cygwin-1.7.9-1/winsup/cygwin/dcrt0.cc:
>>No such file or directory.
>>        in /ext/build/netrel/src/cygwin-1.7.9-1/winsup/cygwin/dcrt0.cc
>>
>>However my Cygwin source is in /usr as opposed to /ext/build/netrel,
>>is there a way to tell gdb to look there instead?
>
> Yes: "info gdb" or "help" in gdb will tell you how.  In "info gdb" look
> for "Source" and then "Source Path".

Thank you for the tip.

After rebuilding libsigc and libtorrent with debug symbols as well
I've made some headway.  Here is what I get now when rtorrent crashes
(it no longer stack dumps):

Program received signal SIGABRT, Aborted.
0x77af014d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
   from /cygdrive/c/Windows/system32/ntdll.dll
(gdb) bt
#0  0x77af014d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
   from /cygdrive/c/Windows/system32/ntdll.dll
#1  0x77af014d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
   from /cygdrive/c/Windows/system32/ntdll.dll
#2  0x77050962 in WaitForMultipleObjectsEx ()
   from /cygdrive/c/Windows/syswow64/KernelBase.dll
#3  0x00000002 in ?? ()
#4  0x00000001 in ?? ()
#5  0x0028c6d8 in ?? ()

Any thoughts on next steps?

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: Issues with latest rtorrent under Win7 x64 when attempting to package

[Chris Sutcliffe]

An additional crash (attempting to load a torrent) now gives the following:

Program received signal SIGABRT, Aborted.
0x77aef8c1 in ntdll!RtlUpdateClonedSRWLock ()
   from /cygdrive/c/Windows/system32/ntdll.dll
(gdb) bt
#0  0x77aef8c1 in ntdll!RtlUpdateClonedSRWLock ()
   from /cygdrive/c/Windows/system32/ntdll.dll
#1  0x77aef8c1 in ntdll!RtlUpdateClonedSRWLock ()
   from /cygdrive/c/Windows/system32/ntdll.dll
#2  0x77050816 in WaitForSingleObjectEx ()
   from /cygdrive/c/Windows/syswow64/KernelBase.dll
#3  0x000004cc in ?? ()
#4  0x76d51194 in KERNEL32!GetPrivateProfileStructA ()
   from /cygdrive/c/Windows/syswow64/kernel32.dll
#5  0x000004cc in ?? ()
#6  0x76d51148 in KERNEL32!GetPrivateProfileStructA ()
   from /cygdrive/c/Windows/syswow64/kernel32.dll
#7  0x000004cc in ?? ()
#8  0x610c92fa in sig_send () from /usr/bin/cygwin1.dll
#9  0x610c6057 in _pinfo::kill () from /usr/bin/cygwin1.dll
#10 0x610c643c in kill0 () from /usr/bin/cygwin1.dll
#11 0x610c6551 in kill () from /usr/bin/cygwin1.dll
#12 0x610c658c in raise () from /usr/bin/cygwin1.dll
#13 0x610c65f5 in abort () from /usr/bin/cygwin1.dll
#14 0x6e3cc1bf in cygstdc++-6!_ZN9__gnu_cxx27__verbose_terminate_handlerEv ()
   from /usr/bin/cygstdc++-6.dll
#15 0x6e3c640a in cygstdc++-6!_ZN10__cxxabiv111__terminateEPFvvE ()
   from /usr/bin/cygstdc++-6.dll
#16 0x6e422ff3 in cygstdc++-6!_ZSt9terminatev () from /usr/bin/cygstdc++-6.dll
#17 0x6e42891b in cygstdc++-6!__cxa_rethrow () from /usr/bin/cygstdc++-6.dll
#18 0x6e3cc16b in cygstdc++-6!_ZN9__gnu_cxx27__verbose_terminate_handlerEv ()
   from /usr/bin/cygstdc++-6.dll
#19 0x6e3c640a in cygstdc++-6!_ZN10__cxxabiv111__terminateEPFvvE ()
   from /usr/bin/cygstdc++-6.dll
#20 0x6e422ff3 in cygstdc++-6!_ZSt9terminatev () from /usr/bin/cygstdc++-6.dll
#21 0x6e428986 in cygstdc++-6!__cxa_throw () from /usr/bin/cygstdc++-6.dll
#22 0x01e9fe3a in torrent::SocketStream::read_stream_throws (this=0x35a8de8,
    buf=0x35a96a0, length=68)
    at /usr/src/libtorrent/libtorrent-0.12.8-1/src/libtorrent-0.12.8/src/net/soc
ket_stream.cc:68
#23 0x01ea5140 in torrent::Handshake::fill_read_buffer (this=0x35a8de8,
    size=0)
    at /usr/src/libtorrent/libtorrent-0.12.8-1/src/libtorrent-0.12.8/src/protoco
l/handshake.cc:210
#24 0x01ea614c in torrent::Handshake::read_info (this=0x35a8de8)
    at /usr/src/libtorrent/libtorrent-0.12.8-1/src/libtorrent-0.12.8/src/protoco
l/handshake.cc:461
#25 0x01ea653c in torrent::Handshake::event_read (this=0x35a8de8)
    at /usr/src/libtorrent/libtorrent-0.12.8-1/src/libtorrent-0.12.8/src/protoco
l/handshake.cc:737
#26 0x01ed4220 in std::for_each<__gnu_cxx::__normal_iterator<torrent::Event**, s
td::vector<torrent::Event*, rak::cacheline_allocator<void*> > >, torrent::poll_c
heck_t<std::mem_fun_t<void, torrent::Event> > > (__first=
l/handshake.cc:210
#24 0x01ea614c in torrent::Handshake::read_info (this=0x35a8de8)
    at /usr/src/libtorrent/libtorrent-0.12.8-1/src/libtorrent-0.12.8/src/protoco
l/handshake.cc:461
#25 0x01ea653c in torrent::Handshake::event_read (this=0x35a8de8)
    at /usr/src/libtorrent/libtorrent-0.12.8-1/src/libtorrent-0.12.8/src/protoco
l/handshake.cc:737
#26 0x01ed4220 in std::for_each<__gnu_cxx::__normal_iterator<torrent::Event**, s
td::vector<torrent::Event*, rak::cacheline_allocator<void*> > >, torrent::poll_c
heck_t<std::mem_fun_t<void, torrent::Event> > > (__first=
      {_M_current = 0x3531700}, __last={_M_current = 0x353173c}, __f=
        {m_poll = 0x3531180, m_set = 0x3532e00, m_op = {<std::unary_function<tor
rent::Event*, void>> = {<No data fields>}, _M_f = &virtual table offset 8}})
    at /usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/bits/stl_function.h:525
#27 0x01e6ce09 in torrent::PollSelect::perform (this=0x3531180,
    readSet=0x3532e00, writeSet=0x3532e20, exceptSet=0x3532e40)
    at /usr/src/libtorrent/libtorrent-0.12.8-1/src/libtorrent-0.12.8/src/torrent
/poll_select.cc:198
#28 0x00472c9d in _fu313___ZN7torrent10ThreadBase8m_globalE ()
    at /usr/src/rtorrent/rtorrent-0.8.8-1/src/rtorrent-0.8.8/src/core/poll_manag
er_select.cc:107
#29 0x00405aa8 in main (argc=1, argv=0x35098c8)
    at /usr/src/rtorrent/rtorrent-0.8.8-1/src/rtorrent-0.8.8/src/main.cc:853

If there is anything more I can do to help debug this further, please
let me know.

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