Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: "Paul Derbyshire" <derbyshire AT globalserve DOT net>
To: cygwin AT cygwin DOT com
Date: Fri, 26 Jul 2002 22:06:10 -0400
MIME-Version: 1.0
Subject: Re: Mysterious gdb behavior.
Reply-to: derbyshire AT globalserve DOT net
Message-ID: <3D41C7D2.30094.4C8A5635@localhost>
In-reply-to: <20020727014743.GA5707@redhat.com>
References: <3D41BDDE DOT 20054 DOT 4C6376DA AT localhost>
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

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?
(tries it)
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 
message.

> 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
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/