This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]