This is the mail archive of the
mailing list for the Cygwin project.
Re: Mysterious gdb behavior.
- From: "Paul Derbyshire" <derbyshire at globalserve dot net>
- To: cygwin at cygwin dot com
- Date: Fri, 26 Jul 2002 22:06:10 -0400
- Subject: Re: Mysterious gdb behavior.
- References: <3D41BDDE.20054.4C6376DA@localhost>
- Reply-to: derbyshire at globalserve dot net
On 26 Jul 2002 at 21:47, Christopher Faylor wrote:
> On Fri, Jul 26, 2002 at 09:23:42PM -0400, Paul Derbyshire wrote:
> >Bug #1: It quits working for no good reason without anything having
> >been changed in its configuration. That's just plain bad.
> I'm hard at work on this one. I haven't changed anything in days and
> gdb continues to work. I will try not changing anything over the
> weekend and see if gdb continues to work on Monday. I may just drop
> everything and not change anything in gdb's configuration for the next
> couple of weeks. Certainly if the mere act of not changing anything
> will eventually cause gdb to fail, I will eventually be able to duplicate
> and fix this problem. It will be hard to fix, though, since the act
> of fixing the problem will require changing gdb which would probably,
> by definition, cause it to work again anyway.
Very funny. It must have scrogged one of its own config files,
though, and I'm curious how that happened.
> >Bug #2: It fails silently rather than present a diagnostic in, say, a
> >dialog box under some circumstances. This is practically the #1 no-no
> >of UI design, guys!
> There are some situations where a configuration bug will cause gdb to
> fail silently. However, this is not, as you seem to assume, by design.
> It is just very hard to fix. The errors generally occur before tcl/tk
> component has initialized and gdb has no easy way to open a dialog box
> and display an error.
It can always dump the message to stdout so it appears in the bash
console. Anyway, this one's happening after it's already successfully
initialized the widget kit and displayed at least one window.
> This usually means that your tcl/tk installation is hosed. Either it
> has been moved, removed, or files are missing. The tcl installation
> will be in /usr/share/tcl8.x (where x varies depending on whether you
> are running the test version of gdb or not).
> If this is the case then 'gdb -nw' will continue to work, in case you
> want to debug gdb and see what's wrong.
Is that the command switch to use text instead of gui?
yep. And it's not a tcl problem. I ran gdb -nw <image name>, got
(gdb) prompt in console, put run, and got the same exact error
> Error 193 is a Windows API error. Specifically, it is
> ERROR_BAD_EXE_FORMAT. I thought the normal way to find this out was to
> type "net helpmsg 193" but that doesn't work on my W2K system.
I thought the normal way to find this out was to see the error
message displayed in plain English, decide you just had to know what
internal code number is used to represent it, and find it in the
source code of the app. :P
Now why is it suddenly complaining that perfectly good executables
are bad? Or if the executables really are bad, why the hell do they
*work* (at least, run and crash rather than fail to run at all) when
launched from bash? Bash and gdb presumably spawn processes in the
same way, however unix does that, and with the cygwin compatibility
layer between that and however Windows spawns processes.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html