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

[Ryan Johnson]

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.

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

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.

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.

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