This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Mysterious gdb behavior.


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.

>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.

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.

>Bug of omission: The feature that most certainly should be there that
>translates internal error numbers into meaningful diagnostic messages
>isn't implemented.  It's just not reasonable to present the end user
>with "(error 193)".  Even when the end user is definitely a programmer.
>He knows his own code's error numbers by heart, most likely, but
>someone else's code's error numbers are as cryptic to him as anyone
>else.

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.

cgf
--
Please do not send me personal email with cygwin questions.
Use the resources at http://cygwin.com/ .

--
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]