Re: Binutils objcopy bug (was Re: rebase segfault)
On 1/16/2013 1:35 PM, Corinna Vinschen wrote: This is a serious bug in objcopy in the current binutils. Given that cygport creates the debug info automatically, we might end up with spuriously broken DLLs in the distro. I checked with objcopy from the older binutils 2.51.53-2, and the problem did not show up. I also built the latest binutils release 2.23.1 and the problem also doesn't show, so we probably can get away with just a black eye by updating binutils to 2.23.1. Chris? Hi Corinna, it seems not so easy. Just built from cvs objcopy --version GNU objcopy (GNU Binutils) 2.23.51.20130119 but the problem is still there Corinna Regards 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: rtorrent and recent snapshots - apparent problem with msync()
On Jan 18 16:24, Christopher Faylor wrote: > On Fri, Jan 18, 2013 at 04:10:25PM -0500, Christopher Faylor wrote: > >On Sat, Jan 19, 2013 at 12:18:39AM +0400, Andrey Repin wrote: > >>Greetings, Corinna Vinschen! > >> > I saw that you made another change to this function. Is it possible that > this might actually fix the "rtorrent problem"? > >> > >>> No. It only adds the MS_SYNC handling. rtorrent uses MS_ASYNC. > >> > >>That made me think... If rtorrent uses MS_ASYNC, shouldn't *rtorrent* be > >>prepared for consequences? Instead of you trying to satisfy its > >>expectations? Me adding MS_SYNC handling has nothing to do with the original problem. It was just something I realized being missing in our msync implementation while looking into the rtorrent behaviour. Actually, what I was really looking into at this time was... > >It does seem that way. > > Actually, it isn't that clear. It seems like msync is failing in the > MS_ASYNC case when it shouldn't be, i.e., rtorrent is within its rights > to expect the operation to succeed. ...this: Under Linux, msync might return with errno set to EBUSY if "MS_INVALIDATE was specified in flags, and a memory lock exists for the specified address range."(*) This sounds a lot like what rtorrent occurs. So, what I was looking for is if rtorrent calls msync with the MS_INVALIDATE flag, but it doesn't. Right now the msync loop does not handle MS_INVALIDATE specificially, only after the loop is exited is EBUSY returned now. OTOH, usually the kernel is not expected to lock a memory page temporarily for its own dubious purposes *and* let a user mode function call fail due to that. Corinna (*) http://www.kernel.org/doc/man-pages/online/pages/man2/msync.2.html -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Binutils objcopy bug (was Re: rebase segfault)
On Jan 19 09:56, marco atzeri wrote: > On 1/16/2013 1:35 PM, Corinna Vinschen wrote: > > >This is a serious bug in objcopy in the current binutils. Given that > >cygport creates the debug info automatically, we might end up with > >spuriously broken DLLs in the distro. > > > >I checked with objcopy from the older binutils 2.51.53-2, and the > >problem did not show up. I also built the latest binutils release > >2.23.1 and the problem also doesn't show, so we probably can get away > >with just a black eye by updating binutils to 2.23.1. Chris? > > > > Hi Corinna, > it seems not so easy. > > Just built from cvs > > objcopy --version > GNU objcopy (GNU Binutils) 2.23.51.20130119 > > but the problem is still there You're right, unfortunately. I don't know what I did when testing it 3 days ago, but now I can reproduce the crash even with 2.23.1. Bummer. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Fwd:
http://vinipoderevecciano.it/admin/about/ht6wn2.php -- 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: deadlock with busy waiting on sigfe
On 2013-01-16 AM 11:14, Christopher Faylor wrote: On Tue, Jan 15, 2013 at 08:46:46PM -0500, Christopher Faylor wrote: Sorry, the backtraces were actually useful because they show that you are apparently running cygwin-snapshot-20130107. Apparently you haven't been watching the discussion about this issue in the Cygwin list. The problem of a Cygwin process hanging after a single CTRL-C should be fixed in later snapshots although there is another reported CTRL-C issue. cgf now i found hang where the argument of program was sed s/^\(.*\)-\([^-]*-[^-]*\)$/\2/ with newer cygwin snapshot. (gdb) thread apply all bt Thread 4 (Thread 12972.0x382c): #0 0x7c95a22a in ntdll!DbgBreakPoint () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c97fc68 in ntdll!DbgUiRemoteBreakin () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x0005 in ?? () #3 0x0001 in ?? () #4 0x003effd0 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 2 (Thread 12972.0x32c8): #0 0x7c96845c in ntdll!KiFastSystemCallRet () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c9678c9 in ntdll!ZwSetInformationThread () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c8324f9 in SetThreadPriority () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x6108760b in yield () at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/miscfuncs.cc:244 #4 0x610d6ee4 in _cygtls::lock() () from /usr/bin/cygwin1.dll #5 0x6103035e in sigpacket::setup_handler (this=0x6cac34, handler=0x6102fe30 , siga=..., tls=0x22ce64) ---Type to continue, or q to quit--- at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/exceptions.cc:796 #6 0x61031a48 in sigpacket::process (this=0x6cac34) at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/exceptions.cc:1274 #7 0x610dd2dc in wait_sig () at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/sigproc.cc:1389 #8 0x61003ea5 in cygthread::callfunc (this=0x6118b400 , issimplestub=) at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/cygthread.cc:51 #9 0x6100442f in cygthread::stub (arg=0x6118b400 ) at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/cygthread.cc:93 #10 0x6100538d in _cygtls::call2 (this=, func=0x610043e0 <_ZN9cygthread4stubEPv@4>, arg=0x6118b400 , buf=0x6100551b <_cygtls::call(unsigned long (*)(void*, void*), void*)+91>) at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/cygtls.cc:99 #11 0x006cffb8 in ?? () #12 0x7c82484f in KERNEL32!GetModuleHandleA () from /cygdrive/c/WINDOWS/system32/kernel32.dll #13 0x in ?? () Thread 1 (Thread 12972.0x2f38): #0 0x7c96845c in ntdll!KiFastSystemCallRet () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c9678c9 in ntdll!ZwSetInformationThread () ---Type to continue, or q to quit--- from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c8324f9 in SetThreadPriority () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x6108764d in yield () at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/miscfuncs.cc:253 #4 0x610d6dcc in _sigfe () from /usr/bin/cygwin1.dll #5 0x61083a40 in mallinfo () at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/malloc_wrapper.cc:2 6 #6 0x6123e9a0 in saved_categories () from /usr/bin/cygwin1.dll #7 0x in ?? () (gdb) (gdb) x 7ffdd000+4 0x7ffdd004: 0x0023 (gdb) x ((_cygtls*)(0x0023-319c))->stackptr 0x22da30: 0x61083ac9 (gdb) i line *0x61083ac9 Line 290 of "/netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/malloc_wrapper .cc" starts at address 0x61083ac9 and ends at 0x61083ad3 . It seems that malloc_init called sigfe-annotated malloc or free during wait_sig thread tried to process exit signal. -- Regards. -- 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: deadlock with busy waiting on sigfe
On Sun, Jan 20, 2013 at 02:23:23PM +0900, jojelino wrote: >On 2013-01-16 AM 11:14, Christopher Faylor wrote: >> On Tue, Jan 15, 2013 at 08:46:46PM -0500, Christopher Faylor wrote: >> Sorry, the backtraces were actually useful because they show that you >> are apparently running cygwin-snapshot-20130107. Apparently you haven't >> been watching the discussion about this issue in the Cygwin list. The >> problem of a Cygwin process hanging after a single CTRL-C should be >> fixed in later snapshots although there is another reported CTRL-C >> issue. > >now i found hang where the argument of program was sed >s/^\(.*\)-\([^-]*-[^-]*\)$/\2/ with newer cygwin snapshot. Once again: don't care about your backtraces. Submit a proper bug report. 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
