NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/os/linux/23142

Text File | 1993-01-07 | 3.7 KB | 81 lines

Newsgroups: comp.os.linux
Path: sparky!uunet!uunet.ca!xenitec!mongrel!shrdlu!gdm
From: [e-mail] (Giles D Malet)
Subject: Re: [BUG?] Why does gdb affect the behaviour of many errors?
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: 3.141592653589793238462643383279502884197169399
Date: Thu, 7 Jan 1993 17:26:22 GMT
Message-ID: <[e-mail]>
Lines: 70

>[e-mail] (John Newnham) writes:
>>But surely an error should (generally, races excluded)
>>occur wether the process is running under a debugger or normally?

[e-mail] (H.J. Lu) writes:
>If you got the answer, please let me know. I had an X11 program of
>several thousand lines in C++, which was running fine on decstation.
>But on AT&T UNIX SVR3.2.2/386, it core-dumped. If I compiled it
>with -g, it ran ok. It drove me crazy.

The key is the -g option. As you well know, the program is thus complied
to include all kinds of info, such as variable names, line numbers,
etc etc, so that gdb can make it's displays luverly.

Say your problem is a daft pointer. Without the `-g' option, referencing
this pointer for a write could be destroying something important, such
as another pointer. When that second pointer is used, it now points to
code space or whatever, and causes a dump.

So, you do a -g. Now your daft pointer could well point to something
completely different, as the data area has been all shuffled around.
Perhaps it points into the space of a variable you have already used (in
initialisation ?) and will not use again, so clobbering it has no effect.
The program may now work perfectly because your pointer may be used in
something like `if ( *p != NULL )', and as it happens *p does not equal
NULL at that moment...

Of course the reverse can happen - you hit a problem at point X in your
program, then compile with -g, run gdb and suddenly hit a problem at
point A, long before getting anywhere near X :-)

So - when you finish your testing, do a final compile without -g,
and with -s, *and do another test run*, unless you want to embarrass
yourself later.

Hope that helps.

BTW, this sort of problem can occur in many ways - changing the length
of a (writable) string could cause a program to crash in a seemingly
completely unrelated place. (Thinks...) Say this string is finished
with, and your stray pointer is harmlessly destroying the end of it.
No problem. You then shorten the string, and just following it is the
storage space for another pointer....

Now don't you wish you had become a lumberjack ?

PREACH WARNING : This is why I am so against everyone so gaily compiling
with the -fwritable_strings option when it is in fact so rarely needed.
You are often just hiding bugs that will jump up and bite you in the
arse later when you least expect it.
The above error will be caught immediately without -fwrite...,
but be hidden by it. This is of course the whole purpose of non-writable
segments...

I have compiled almost every program on my system, including smail,
uucp, elm, c-news, some GNU stuff, inet stuff etc. Pretty well everything
except most of the `standard' stuff in /bin & /usr/bin that is found on
a root diskette. The *only* program that needed -fwritable-strings was
`fmt', a formatting program from the net that is more powerfull than
the usual one (it handles >lines) - it had a `char *p="something"' or
whatever it was in it, which I changed to something more respectable.
So now not one program on this machine needs -f666.

I don't run X.

Bye ! :-)

--
Giles D Malet                                             [e-mail]
Waterloo, Ont, Canada       [phone]       [e-mail]