X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-bounces using -f
Date:	Fri, 04 Jan 2002 11:23:34 +0200
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	"Alex Oleynikov" <alex AT compuweigh DOT com>
Message-Id:	<9791-Fri04Jan2002112334+0200-eliz@is.elta.co.il>
X-Mailer:	emacs 21.1.50 (via feedmail 8 I) and Blat ver 1.8.9
CC:	djgpp AT delorie DOT com
In-reply-to:	<000d01c1949c$d798f820$1400a8c0@alex>
Subject:	Re: Strange RHIDE behavior
References:	<000d01c1949c$d798f820$1400a8c0 AT alex>
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> From: "Alex Oleynikov" <alex AT compuweigh DOT com>
> Date: Thu, 3 Jan 2002 16:23:08 -0500
> 
> The story is: any function, which has an argument named "search_cond"
> crashes when I try to step into it while debugging the application. The PC
> screen just goes black with a blinking cursor and I have to reboot it again.
> The strange thing is that stepping over the function works fine so does the
> executable, when it is run from DOS prompt.
> I tried all kinds of tricks to figure out where the problem hides, but only
> renaming the argument in the function's definition from "search_cond" to
> anything else helps the situation.

Is it possible that you have a global symbol (a variable or a
function) by the same name in that program, or in some library the
program calls?  What does the following GDB command print?

  (gdb) info address search_cond

Also, if you type "info variables" at GDB's prompt, does it mention
search_cond in the list it prints?

(I don't use RHIDE, so I don't know how to invoke the same commands
from RHIDE.  It might be a good idea to try to run the program under
GDB anyway, just to see if the same problem happens there.)

Also, what debug switch did you use to compile?  Was it -g, -gstabs,
or something else?

> I always used to think that compilers do
> not care how the function's arguments are named as soon as they have correct
> types, but apparently it is not so.

One known situation when it is not so is when you have a global
symbol by the same name.  Normally, a compiler should complain, but
sometimes it doesn't, because the code might look like doing some
legitimate business (e.g., you do have a right to pass functions as
arguments to other functions).

> Is there a hidden or system variable in DJGPP that has the same name and
> confuses the debugger?

If DJGPP has such variables, it's a bug: a library implementation
must not put any symbol with a global space into the program's
namespace, except (1) those symbols defined by the C Standard,
and (2) symbols which begin with two underscores or one underscore
and a capital letter.

In any case, I've just searched the entire source tree of the DJGPP
library, and didn't find anything by that name.

If the program is a C++ program, it's possible that the offending
symbol comes from some C++ class.

- Raw text -