Date: Wed, 26 Sep 2012 15:41:01 +0200 From: Andrea Venturoli <ml@netfence.it> To: Ashish SHUKLA <ashish@freebsd.org> Cc: freebsd-ports@freebsd.org Subject: Re: emacs23 Message-ID: <506305ED.6010705@netfence.it> In-Reply-To: <86k3vlhf64.fsf@chateau.d.if> References: <505D9743.1020002@netfence.it> <86k3vlhf64.fsf@chateau.d.if>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/23/12 00:21, Ashish SHUKLA wrote: > Hi Andrea, > > I don't use GDB integration of Emacs to notice any breakage. Could you post > here (or on emacs-devel[1] list) about problems you're facing, and if > reproducible by others as well, then we can probably file a bug report on > Emacs bug tracker[2]. I'll post here, since I don't know whether this is a FreeBSD specific problem. The box is running 8.3/i386 (but on 9.0 it's the same). The problem is quite complex, meaning so many things are just screwed up that you end up wondering if this is production ready software. I'll try to explain with an example session, which I hope will show some of the bugs of the new version; I'm open to feedback in case something is not clear. %emacs & M-x gdb (I'm prompted with "gdb -i=mi" and just add the executable name). (I get "This version of GDB doesn't support non-stop mode. Turnig it off"; I don't know what this means, I just ignore it.) b main r (I get argc=Error accessing memory address 0x0: Bad address.) p argc (I get Error accessing memory address 0x0: Bad address.) (Ok, so I cannot look into a variable). frame (I'd expect to see the source, but I don't). C-x C-f and I open the source manually. (Positioned on the source line I want a breakpoint on) C-x Space (The dot appears grey, not red, as tough the source was not recognized; however the breakpoint seems to work). r (The program starts and stops at the first breakpoint; however I get no indication of this in the source window). n (Nothing happens, the pointer in the source does not move, in *gud* windows the same line is reported) n (Nothing happens, the pointer in the source does not move, in *gud* windows the same line is reported) n (Debugger segmentation fault: 11 (core dumped)) Ok, I give up with gdb from base and try gdb75 from ports. M-x gdb (I'm prompted with "gdb -i=mi", add the executable name and substitute "gdb" with "/usr/local/bin/gdb75"). b main r n (Things work better here; I get an *input/output* windows I cannot get rid of) c After a while C-c C-c (The program stops in "write" from the runtime outside my program) frame (gdb locks up) %kill gdb75 M-x gdb "The program is already being debugged" C-x C-k M-x gdb (I'm prompted with "gdb -i=mi", add the executable name and substitute "gdb" with "/usr/local/bin/gdb75"). (Ok this time) r After a while C-c C-c (The program stops in "read" from the runtime outside my program) (avoiding the use of "frame", which produced a lockup earlier) bt frame 7 (now in my program) I move to the next line and give C-x Space (nothing happens; from now on I cannot insert breakpoints this way) b foo.cxx:45 (manual insert of breakpoint works) fin fin fin fin fin fin n (program moves correctly to the next line) (I lose "(gdb)" prompt, so I have an hard time trying to tell what I wrote from what the debugger wrote; also if I leave the window for a while, when I'm back I have to guess whether the program is running or stopped) b 'func<tab' (gdb locks up; eventually emacs locks too and I have to quit it or kill it). This is of course only an example, but it shows most of the ways in which I found emacs24+gdb can fail or annoy. I suspect there are others. Since it cannot be pinpointed to a single bug, I guess either some version incompatibility or some wrong compilation option, but I really don't know where to look. > And, as for the security vulnerability which I forgot to fix for > editors/emacs23 (my fault, apologies), I'm testing a fix[3] in tinderbox, once > it builds fine, I'll commit it. Thanks for this. bye av.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?506305ED.6010705>