Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)
On 5/3/2012 4:10 PM, Ryan Johnson wrote: 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: The gdb-mi integration also seems to work reasonably well, with a few exceptions: [...] (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.) This is now fixed (http://cygwin.com/ml/cygwin/2012-05/msg00084.html). 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). I'm not sure why you're using the -nw switch when you start emacs in mintty. As far as I can tell from the documentation, -nw shouldn't do anything if you're not running under X. But it also shouldn't do any harm. In any case, I still don't see why you can't run emacs under gdb in mintty: $ cd emacs-24.0.95/src/ $ gdb ./emacs.exe GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-cygwin. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /tmp/emacs-24.0.95/src/emacs.exe...done. SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] Environment variable DISPLAY not defined. TERM = xterm Breakpoint 1 at 0x4ded26: file emacs.c, line 394. Temporary breakpoint 2 at 0x4f8970: file sysdep.c, line 855. (gdb) r -Q [...] Now if it crashes, won't you be returned to gdb where you can get a backtrace? And attaching from another mintty also works; gdb processes the .gdbinit file just fine as long as you start gdb from the emacs src directory: $ gdb --pid=13144 GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-cygwin. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Attaching to process 5672 [New Thread 5672.0xd24] [New Thread 5672.0x2dec] [New Thread 5672.0x2b08] [New Thread 5672.0x13c0] [New Thread 5672.0x2cd4] [New Thread 5672.0x2de4] [New Thread 5672.0x2818] [New Thread 5672.0x33d0] Reading symbols from /tmp/emacs-24.0.95/src/emacs.exe...done. SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] Environment variable DISPLAY not defined. TERM = xterm Breakpoint 1 at 0x4ded26: file emacs.c, line 394. Temporary breakpoint 2 at 0x4f8970: file sysdep.c, line 855. (gdb) c Continuing. 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
Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)
On 04/05/2012 1:39 PM, Ken Brown wrote: On 5/3/2012 4:10 PM, Ryan Johnson wrote: 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: The gdb-mi integration also seems to work reasonably well, with a few exceptions: [...] (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.) This is now fixed (http://cygwin.com/ml/cygwin/2012-05/msg00084.html). Ack. 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). I'm not sure why you're using the -nw switch when you start emacs in mintty. As far as I can tell from the documentation, -nw shouldn't do anything if you're not running under X. I have DISPLAY defined for things like gnuplot, but don't want emacs to use it even when X is available... I still don't see why you can't run emacs under gdb in mintty: $ cd emacs-24.0.95/src/ $ gdb ./emacs.exe GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-cygwin. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /tmp/emacs-24.0.95/src/emacs.exe...done. SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] Environment variable DISPLAY not defined. TERM = xterm Breakpoint 1 at 0x4ded26: file emacs.c, line 394. Temporary breakpoint 2 at 0x4f8970: file sysdep.c, line 855. (gdb) r -Q [...] Now if it crashes, won't you be returned to gdb where you can get a backtrace? I guess that might work, since I wouldn't do anything but grab the backtrace. It just doesn't work well to mix gdb and curses-using apps in the same terminal. And attaching from another mintty also works; gdb processes the .gdbinit file just fine as long as you start gdb from the emacs src directory: Duh... I hadn't thought to specify the --pid switch; I usually just attach inside gdb, and that's too late for the purposes of .gdbinit. Thanks! 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
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] 0x010c in ?? () (gdb) bt #0 0x010c 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 0x0003 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,
Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)
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] 0x010c in ?? () (gdb) bt #0 0x010c 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 0x0003 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
Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)
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] 0x010c in ?? () (gdb) bt #0 0x010c 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 0x0003 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. Do you have a recipe that will reliably produce a segfault for you? I've been using emacs-24 for months without any problems (as long as I build without gsettings support, as I did for emacs-24.0.96-1). But I haven't tested gdb-mi for a while. You said you got segfaults even while not using gdb-mi. But did you get segfaults in an emacs session in which you didn't use gdb-mi at all in the entire session? Good point. I probably had used gdb-mi at some point during every session that crashed. I just fooled around with M-x gdb a little and didn't get a crash (although I did see some minor annoyances involving I/O synchronization that I'll try to debug when I get a chance). So be sure to let me know if you find a reproducible way of getting a crash, preferably starting with 'emacs -Q'. 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
Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)
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] 0x010c in ?? () (gdb) bt #0 0x010c 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 0x0003 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. 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
Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)
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] 0x010c in ?? () (gdb) bt #0 0x010c 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 0x0003 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
Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)
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... Also, gdb-mi seems to be alpha quality, is it supposed to be fully usable and stable at this point? (and is there a way to disable it and return to --annotate=3?) 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
Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)
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] 0x010c in ?? () (gdb) bt #0 0x010c 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 0x0003 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) 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
Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)
On 4/30/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... Also, gdb-mi seems to be alpha quality, is it supposed to be fully usable and stable at this point? (and is there a way to disable it and return to --annotate=3?) There have been recent problems reported with gdb-mi, so there will probably be bugfixes before emacs-24.1 is released. I don't know offhand of a way to return to --annotate=3. 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
Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)
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] 0x010c in ?? () (gdb) bt #0 0x010c 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 0x0003 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. Do you have a recipe that will reliably produce a segfault for you? I've been using emacs-24 for months without any problems (as long as I build without gsettings support, as I did for emacs-24.0.96-1). But I haven't tested gdb-mi for a while. You said you got segfaults even while not using gdb-mi. But did you get segfaults in an emacs session in which you didn't use gdb-mi at all in the entire session? 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
Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)
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] 0x010c in ?? () (gdb) bt #0 0x010c 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 0x0003 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. Do you have a recipe that will reliably produce a segfault for you? I've been using emacs-24 for months without any problems (as long as I build without gsettings support, as I did for emacs-24.0.96-1). But I haven't tested gdb-mi for a while. You said you got segfaults even while not using gdb-mi. But did you get segfaults in an emacs session in which you didn't use gdb-mi at all in the entire session? Good point. I probably had used gdb-mi at some point during every session that crashed. 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
