[ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)

Ryan Johnson ryan.johnson@cs.utoronto.ca
Thu May 3 20:10:00 GMT 2012


On 03/05/2012 10:45 AM, Ken Brown wrote:
> 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.
That worked at first, but after a while it stopped and never came back.
>
>> 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.)
Not for me it doesn't. Maybe this fix you mention is patched into your 
version?

>
>> 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.
I usually run under mintty with -nw. When following the instructions in 
that /etc/DEBUG file you pointed me at, the .gdbinit included 
breakpoints and other pre-main intializations to perform that would not 
happen if I merely attached to a running emacs. However, that will 
probably be my next attempt, since the X11 route didn't pan out (and I 
dislike using the graphical version).

> 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.)
It won't happen this weekend, but I may get back to you on this later.

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



More information about the Cygwin mailing list