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 21:23:42 -0400
MIME-Version: 1.0
Subject: Mysterious gdb behavior.
Reply-to: derbyshire AT globalserve DOT net
Message-ID: <3D41BDDE.20054.4C6376DA@localhost>
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

Sometime recently (but *before* that last upgrade that botched things 
up) gdb apparently got tired of working decided to retire.

When run with an image, it used to work quite nicely. I used it to 
track down a crash a few months back; this proved to be caused by a 
DLL problem that was causing the program to jump at a trampoline and 
bounce off into never-never land. Nasty to track down that kind of 
problem without a debugger.

Well, now I have no debugger, and I've managed to fix about three 
core-dumping bugs since it quit working without it's help, but it's 
only a matter of time before I really truly *need* it working or the 
world will end.

Symptoms: gdb foo-executable-name brings up a normal window with the 
right source file open and the highlight on the main() function's 
start. You click the run icon in the upper left corner and...
nothing happens.
You click it again. You use the menu item. Nothing happens.
You see there's a breakpoint on the first line, remove it. Now 
something happens: the breakpoint magically reappears. But it doesn't 
run.
You go to the console and hit run and this time you actually get an 
error message instead of a silent failure:

Error: Error creating process <image path>, (error 193)

Then you look at the documentation. There's no documentation of the 
error codes.

This seems to mean we have 2 bugs and 1 "bug of omission" here.
Bug #1: It quits working for no good reason without anything having 
been changed in its configuration. That's just plain bad.
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!
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. This screwy error reporting, incidentally, being the 
Macintosh's sole UI defect, aside from lack of decent powerful 
options in general and decent free development tools in particular; 
"This application has unexpectedly quit because an error of type -53 
occurred" has to be the most awful thing I ever had the displeasure 
to see on a computer screen. No clue what's really wrong. No clue how 
to fix it. (Yes, my high school forced me to use a Mac. I still bear 
the psychological scars to this very day.)

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