X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_NO,SPF_NEUTRAL,TW_DF,T_RP_MATCHES_RCVD
X-Spam-Check-By:	sourceware.org
Message-ID:	<4FA299FD.9070903@cornell.edu>
Date:	Thu, 03 May 2012 10:45:17 -0400
From:	Ken Brown <kbrown AT cornell DOT edu>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
CC:	Eli Zaretskii <eliz AT gnu DOT org>
Subject:	Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)
References:	<announce DOT 4F9EF137 DOT 7070904 AT cornell DOT edu> <4F9F32ED DOT 3030808 AT cs DOT utoronto DOT ca> <4F9F3751 DOT 6000406 AT cs DOT utoronto DOT ca> <4F9F45A1 DOT 60500 AT cornell DOT edu> <4F9F5DEF DOT 30804 AT cs DOT utoronto DOT ca> <4FA13CB9 DOT 6000903 AT cornell DOT edu> <4FA16BEE DOT 3070605 AT cs DOT utoronto DOT ca> <4FA1A0DF DOT 3040101 AT cs DOT utoronto DOT ca>
In-Reply-To:	<4FA1A0DF.3040101@cs.utoronto.ca>
X-PMX-CORNELL-SPAM-CHECKED:	Pawpaw
X-Original-Sender:	kbrown AT cornell DOT edu - Thu May 3 10:45:18 2012
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

On 5/2/2012 5:02 PM, Ryan Johnson wrote:
> On 02/05/2012 1:16 PM, Ryan Johnson wrote:
>> On 02/05/2012 9:55 AM, Ken Brown wrote:
>>> On 4/30/2012 11:52 PM, Ryan Johnson wrote:
>>>> On 30/04/2012 10:08 PM, Ken Brown wrote:
>>>>> On 4/30/2012 9:07 PM, Ryan Johnson wrote:
>>>>>> On 30/04/2012 8:48 PM, Ryan Johnson wrote:
>>>>>>> On 30/04/2012 4:08 PM, Ken Brown wrote:
>>>>>>>> Test releases of the emacs, emacs-X11, and emacs-el packages
>>>>>>>> (24.0.96-1) are now available. This is a pretest for the upcoming
>>>>>>>> release of emacs-24.1.
>>>>>>>>
>>>>>>>> Emacs users are encouraged to try it and report any problems to the
>>>>>>>> cygwin mailing list.
>>>>>>> I'm experiencing regular seg faults, often while using gdb but not
>>>>>>> always (switching between buffers is another big offender). I'm not
>>>>>>> sure what other information I can provide, other than the
>>>>>>> EIP=610CF707
>>>>>>> reported in the .stackdump file...
>>>>>> Caught one in gdb (no symbols, sadly):
>>>>>>
>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>> [Switching to Thread 8128.0x3d0]
>>>>>> 0x0000010c in ?? ()
>>>>>> (gdb) bt
>>>>>> #0 0x0000010c in ?? ()
>>>>>> #1 0x0054b0ac in ?? ()
>>>>>> #2 0x004e4303 in ?? ()
>>>>>> #3 0x0054afbe in ?? ()
>>>>>> #4 0x004e4e96 in ?? ()
>>>>>> #5 0x004e5180 in ?? ()
>>>>>> #6 0x004dfbec in ?? ()
>>>>>> #7 0x610070d8 in _cygwin_exit_return () from /usr/bin/cygwin1.dll
>>>>>> #8 0x00000003 in ?? ()
>>>>>> #9 0x610050dd in _cygtls::call2(unsigned long (*)(void*, void*),
>>>>>> void*,
>>>>>> void*)
>>>>>> () from /usr/bin/cygwin1.dll
>>>>>> Backtrace stopped: Not enough registers or memory available to unwind
>>>>>> further
>>>>>>
>>>>>> HTH... I'm reverting for now (I can re-install if you've got specific
>>>>>> ideas to try out)
>>>>>
>>>>> Thanks for testing. I'll try to make debugging symbols available so
>>>>> that you can get a better backtrace. It might be a few days before I
>>>>> get to it.
>>>
>>> I can still make debugging symbols available for the version I built
>>> if you'd like, but you'll get a more reliable backtrace from a build
>>> without optimization. Would you like to build it yourself (with
>>> CFLAGS='-g -O0') and send a backtrace? If so, you can get the source
>>> from
>>>
>>> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.96.tar.gz
>>>
>>> I'm copying Eli Zaretskii, one of the Emacs developers, who might be
>>> able to help with debugging if you can get a useful backtrace. Please
>>> keep him in the CC if you reply.
>>>
>>> By the way, you can find some good hints about debugging emacs in
>>> etc/DEBUG in the emacs distribution.
>> I've downloaded the sources and will get back to you when I've had a
>> chance to build and play with them.
> Figures... after using the home-built version for about 4 hours, I've
> only had one seg fault, and it was deep in Windows code somewhere
> (something about acquiring a reader lock on a file, perhaps?); gdb
> couldn't find any cygwin or emacs code to pin a stacktrace on.
>
> The gdb-mi integration also seems to work reasonably well, with a few
> exceptions:
>
> 1. The (gdb) prompt basically never displays.

I find that I sometimes have to press RET before I see the prompt.  I'll 
try to figure out why that's happening, but at least pressing RET 
provides a workaround in the meantime.

> 2. Breakpoints don't always jump to the source file. I could have sworn
> this worked before, but the 4h run that didn't crash definitely doesn't.
> This may have something to do with the fact that I'm loading the target
> file manually (to avoid the long-standing endless initialization
> feature/bug).

Again, pressing RET seems to avoid the endless initialization bug. 
(This was fixed once and was a Cygwin bug, so I think it won't be hard 
for me to resurrect my test case and get it fixed again.)

> 3. Breakpoints having "commands" stuck to them do not display their
> name/args when triggered, nor do some outputs for commands (such as "fr
> 0") which they issue. This makes it hard to see which breakpoint a given
> output corresponds to (print still works). The same applies for
> breakpoints that just stop.
>
> The combination of all three makes it really hard to tell when gdb
> breaks into execution. The only indication is that the status line
> changes to [breakpoint], or [interrupt] if the target program faults.

I agree that there are some issues to be worked out, which may well be 
Cygwin specific.  But getting to the bottom of the crashes is a higher 
priority.

> One last note: I normally use emacs in terminal mode, but couldn't do
> that inside gdb (for obvious reasons). Some of the behaviors I observed
> before -- including seg faults -- may be terminal-specific, and some of
> the new strangeness I'm pointing out now may be X11-specific... or it
> might just be the difference between -O0 and -O2.

What do you mean by "terminal mode"?  Do you mean you run emacs under 
mintty?  Or do you run it under xterm with the -nw switch?  And could 
you elaborate on the "obvious reasons"?  I don't see why you can't run 
emacs in a terminal under gdb; or attach to it from a different terminal 
if that's more convenient.

If you continue to find that my build crashes for you but your build 
doesn't, we should try to figure out what the differences are.  You 
could download the source for the Cygwin package and rebuild using my 
.cygport file, with the line

   CFLAGS="-g -O0"

added.  I can send more detailed instructions if you're not familiar 
with cygport.  (For one thing, you'll have to go to the build/src 
directory in order to run the unstripped binary under gdb.)

Ken

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

- Raw text -