X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL,TW_DF,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Message-ID: <4FA2E61C.5070809@cs.utoronto.ca> Date: Thu, 03 May 2012 16:10:04 -0400 From: Ryan Johnson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST) References: <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> <4FA299FD DOT 9070903 AT cornell DOT edu> In-Reply-To: <4FA299FD.9070903@cornell.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , 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 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