* gdb broken inside emacs (again? still?)
@ 2011-11-09 21:44 Ryan Johnson
2011-11-09 22:32 ` Ken Brown
0 siblings, 1 reply; 6+ messages in thread
From: Ryan Johnson @ 2011-11-09 21:44 UTC (permalink / raw)
To: cygwin
Hi all,
Attempting to run gdb inside emacs with an executable file name argument
(with or without --annotate=3) causes it to seg fault (no surprise,
known issue). Running just `gdb' from emacs allows it to initialize, but
attempts to load a file or indeed perform any command hang until a
double-^C cancels the attempt (reporting "C-c C-cquit"). Ironically,
even `quit' hangs, so you have to use ^D to exit. Debugging anything
within emacs is thus completely impossible at this time. I've tried with
a home-compiled gdb (same version) with no better luck. I'm building an
emacs-23 from scratch, but I'm pretty sure I've already tried that
before, without any conclusive improvement.
I know this has come up before, and that it has been "resolved" before
for me and for others, but it keeps recurring (usually whenever I
actually need to debug something) and I can't find any reliable way to
make the problem go away.
Do the latest snapshots contain changes which should fix the problem?
I'm on an win7-64 system, running the 13 Oct dll snapshot, after a
rebaseall. Relevant package versions are below (setup.exe doesn't
advertize any newer ones):
> binutils 2.22.51-1
> gcc4 4.5.3-3
> gcc4-core 4.5.3-3
> gcc4-g++ 4.5.3-3
> gcc4-java 4.5.3-3
> gdb 7.3.50-2
> emacs 23.3-3
> emacs-X11 23.3-3
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdb broken inside emacs (again? still?)
2011-11-09 21:44 gdb broken inside emacs (again? still?) Ryan Johnson
@ 2011-11-09 22:32 ` Ken Brown
2011-11-09 23:08 ` Ryan Johnson
2011-11-09 23:59 ` Ryan Johnson
0 siblings, 2 replies; 6+ messages in thread
From: Ken Brown @ 2011-11-09 22:32 UTC (permalink / raw)
To: cygwin
On 11/9/2011 4:44 PM, Ryan Johnson wrote:
> Hi all,
>
> Attempting to run gdb inside emacs with an executable file name argument
> (with or without --annotate=3) causes it to seg fault (no surprise,
> known issue). Running just `gdb' from emacs allows it to initialize, but
> attempts to load a file or indeed perform any command hang until a
> double-^C cancels the attempt (reporting "C-c C-cquit"). Ironically,
> even `quit' hangs, so you have to use ^D to exit. Debugging anything
> within emacs is thus completely impossible at this time. I've tried with
> a home-compiled gdb (same version) with no better luck. I'm building an
> emacs-23 from scratch, but I'm pretty sure I've already tried that
> before, without any conclusive improvement.
>
> I know this has come up before, and that it has been "resolved" before
> for me and for others, but it keeps recurring (usually whenever I
> actually need to debug something) and I can't find any reliable way to
> make the problem go away.
>
> Do the latest snapshots contain changes which should fix the problem?
>
> I'm on an win7-64 system, running the 13 Oct dll snapshot, after a
> rebaseall. Relevant package versions are below (setup.exe doesn't
> advertize any newer ones):
>> binutils 2.22.51-1
>> gcc4 4.5.3-3
>> gcc4-core 4.5.3-3
>> gcc4-g++ 4.5.3-3
>> gcc4-java 4.5.3-3
>> gdb 7.3.50-2
>> emacs 23.3-3
>> emacs-X11 23.3-3
cgf has already stated that this will be fixed in the next release of
gdb; see
http://cygwin.com/ml/cygwin/2011-10/msg00564.html
In the meantime, can't you use gdb 7.3.50-1? If you also have problems
with that release, please send detailed instructions for reproducing the
problem (starting with emacs -Q).
Ken
P.S. If you're building your own emacs and using a Cygwin snapshot,
you'll need to apply my patch to fix the memory allocation problem that
we discussed a few months ago. You can get this by using setup.exe to
download the source for emacs-23.3-3.
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdb broken inside emacs (again? still?)
2011-11-09 22:32 ` Ken Brown
@ 2011-11-09 23:08 ` Ryan Johnson
2011-11-10 2:38 ` Ken Brown
2011-11-09 23:59 ` Ryan Johnson
1 sibling, 1 reply; 6+ messages in thread
From: Ryan Johnson @ 2011-11-09 23:08 UTC (permalink / raw)
To: cygwin
On 09/11/2011 5:32 PM, Ken Brown wrote:
> On 11/9/2011 4:44 PM, Ryan Johnson wrote:
>> Debugging anything within emacs is thus completely impossible at this
>> time.
>
> cgf has already stated that this will be fixed in the next release of
> gdb; see
>
> http://cygwin.com/ml/cygwin/2011-10/msg00564.html
>
Sorry, must have missed that one. Thanks for pointing me at it.
> In the meantime, can't you use gdb 7.3.50-1? If you also have
> problems with that release, please send detailed instructions for
> reproducing the problem (starting with emacs -Q).
No luck:
$ cygcheck -cd | grep gdb
gdb 7.3.50-1
libgdbm4 1.8.3-20
$ emacs -Q -nw
M-x gdb
Run gdb (like this): gdb
(gdb) quit
... long time passes...
C-c C-cQuit
(gdb) ^D
Debugger finished
> P.S. If you're building your own emacs and using a Cygwin snapshot,
> you'll need to apply my patch to fix the memory allocation problem
> that we discussed a few months ago. You can get this by using
> setup.exe to download the source for emacs-23.3-3.
That would explain why emacs-bootstrap.exe keeps hanging. I'll try
building from the patched source tree and see what happens.
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdb broken inside emacs (again? still?)
2011-11-09 22:32 ` Ken Brown
2011-11-09 23:08 ` Ryan Johnson
@ 2011-11-09 23:59 ` Ryan Johnson
1 sibling, 0 replies; 6+ messages in thread
From: Ryan Johnson @ 2011-11-09 23:59 UTC (permalink / raw)
To: cygwin
On 09/11/2011 5:32 PM, Ken Brown wrote:
> On 11/9/2011 4:44 PM, Ryan Johnson wrote:
>> Running just `gdb' from emacs allows it to initialize, but
>> attempts to load a file or indeed perform any command hang until a
>> double-^C cancels the attempt (reporting "C-c C-cquit"). Ironically,
>> even `quit' hangs, so you have to use ^D to exit. Debugging anything
>> within emacs is thus completely impossible at this time.
> cgf has already stated that this will be fixed in the next release of
> gdb; see
>
> http://cygwin.com/ml/cygwin/2011-10/msg00564.html
Hmm. After dwelling longer on the above post chain... I think cgf was
only talking about fixing the seg fault. Is this freezing somehow
related? I didn't think it was.
> P.S. If you're building your own emacs and using a Cygwin snapshot,
> you'll need to apply my patch to fix the memory allocation problem
> that we discussed a few months ago. You can get this by using
> setup.exe to download the source for emacs-23.3-3.
Built, but unfortunately no improvement in behavior by gdb. Is there
some possibility those cygwin-specific patches somehow are tied up in
this? The last time this came up a home-built emacs worked with
gdb-7.3.50-1.
As others have reported, gud-gdb can load and run binaries, but then
emacs doesn't sync up its output with source files any more...
BTW, I don't know if this has anything to do with anything, but `strace
gdb' from the command prompt or inside emacs reports an infinite stream
of seg faults:
> 25 1231358 [main] gdb 4112 __set_errno: void san::leave():277 val 14
> --- Process 4112, exception C0000005 at 6111AE63
> 71 1231429 [main] gdb 4112 exception::handle: In
> cygwin_except_handler exc 0xC0000005 at 0x6111AE63 sp 0x149C8F4
> 67 1231496 [main] gdb 4112 exception::handle: In
> cygwin_except_handler sig 11 at 0x6111AE63
> 82 1231578 [main] gdb 4112 exception::handle: In
> cygwin_except_handler calling 0x0
> 29 1231607 [main] gdb 4112 __set_errno: void san::leave():277 val 14
> --- Process 4112, exception C0000005 at 6111AE63
> 75 1231682 [main] gdb 4112 exception::handle: In
> cygwin_except_handler exc 0xC0000005 at 0x6111AE63 sp 0x149C8F4
> 28 1231710 [main] gdb 4112 exception::handle: In
> cygwin_except_handler sig 11 at 0x6111AE63
> 28 1231738 [main] gdb 4112 exception::handle: In
> cygwin_except_handler calling 0x0
^C kills the program, but attempting to type any other character hangs
gdb, strace, and the terminal for good measure.
Is gdb just known-unfriendly to strace?
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdb broken inside emacs (again? still?)
2011-11-09 23:08 ` Ryan Johnson
@ 2011-11-10 2:38 ` Ken Brown
2011-11-10 3:23 ` Ryan Johnson
0 siblings, 1 reply; 6+ messages in thread
From: Ken Brown @ 2011-11-10 2:38 UTC (permalink / raw)
To: cygwin
On 11/9/2011 6:08 PM, Ryan Johnson wrote:
> On 09/11/2011 5:32 PM, Ken Brown wrote:
>> On 11/9/2011 4:44 PM, Ryan Johnson wrote:
>>> Debugging anything within emacs is thus completely impossible at this
>>> time.
>>
>> cgf has already stated that this will be fixed in the next release of
>> gdb; see
>>
>> http://cygwin.com/ml/cygwin/2011-10/msg00564.html
>>
> Sorry, must have missed that one. Thanks for pointing me at it.
>
>> In the meantime, can't you use gdb 7.3.50-1? If you also have problems
>> with that release, please send detailed instructions for reproducing
>> the problem (starting with emacs -Q).
> No luck:
>
> $ cygcheck -cd | grep gdb
> gdb 7.3.50-1
> libgdbm4 1.8.3-20
> $ emacs -Q -nw
> M-x gdb
> Run gdb (like this): gdb
^^^^^^^^^
That's your problem. You've deleted `--annotate=3' from the prompt
emacs gave you. emacs-23 needs that to be there. M-x gdb works fine
for me like that, using both gdb 7.3.50-1 and 7.3.50-3 (which is now
available). I tested with Cygwin 1.7.9 as well as with the latest snapshot.
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdb broken inside emacs (again? still?)
2011-11-10 2:38 ` Ken Brown
@ 2011-11-10 3:23 ` Ryan Johnson
0 siblings, 0 replies; 6+ messages in thread
From: Ryan Johnson @ 2011-11-10 3:23 UTC (permalink / raw)
To: cygwin
On 09/11/2011 9:37 PM, Ken Brown wrote:
> On 11/9/2011 6:08 PM, Ryan Johnson wrote:
>> On 09/11/2011 5:32 PM, Ken Brown wrote:
>>> In the meantime, can't you use gdb 7.3.50-1? If you also have problems
>>> with that release, please send detailed instructions for reproducing
>>> the problem (starting with emacs -Q).
>> No luck:
>>
>> $ cygcheck -cd | grep gdb
>> gdb 7.3.50-1
>> libgdbm4 1.8.3-20
>> $ emacs -Q -nw
>> M-x gdb
>> Run gdb (like this): gdb
> ^^^^^^^^^
>
> That's your problem. You've deleted `--annotate=3' from the prompt
> emacs gave you. emacs-23 needs that to be there. M-x gdb works fine
> for me like that, using both gdb 7.3.50-1 and 7.3.50-3 (which is now
> available). I tested with Cygwin 1.7.9 as well as with the latest
> snapshot.
!!
That was it. Thanks a lot, and sorry for the bother.
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-11-10 3:23 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-09 21:44 gdb broken inside emacs (again? still?) Ryan Johnson
2011-11-09 22:32 ` Ken Brown
2011-11-09 23:08 ` Ryan Johnson
2011-11-10 2:38 ` Ken Brown
2011-11-10 3:23 ` Ryan Johnson
2011-11-09 23:59 ` Ryan Johnson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).