From: Christoph Egger <Christoph_Egger@t-online.de>
  To  : Terry 'Mongoose' Hendrix <stu7440@westga.edu>
  Date: Sun, 11 Jul 1999 22:59:35 +0200 (MEST)

Re: hacking methods to find out bugs

On Sun, 11 Jul 1999 mongoose@ms241739.users.mindspring.com wrote:

> On Sun, 11 Jul 1999, Christoph Egger wrote:
> 
> >I'm the author of the 3DtoolKit-Library. About two weeks ago, I
> >restructured the headers. Since this, the screen is always blank, and the
> >programs using my libs crashs on sig 11 after exiting.
> 
> You changed the headers?  

Yes. But not the prototypes. I changed the structs. I want to achieve,
that the structs internally are unchanged, but externally used as void *
like libggi does. Although all compiles as expected, the screen is now
blank, and the programs using my lib crashs on sig 11 after exiting... :-(

> Remember you can only use prototypes in headers,
> you can't allocate memory or define functions there.  Also make sure
> you're not including a header more than once using #ifdefs.  Also make
> sure you've rm'ed all the old object files and aren't linking old objects
> that may have linked with the old headers...  rememer changing a header
> will not cause a standard Makefile to recompile ( unless you wrote a make
> dep script ).  I know this is common sesne stuff, but basics are
> overlooked sometimes.

I know that. I've already expierence in coding... :)
> 
> >Which hacking methods are known to find the bugs?
> 
> You can try using printfs and adding extra checking... for example always
> check if your buffers are allocated memory before using them.  ( This
> should alway be done, but it's a good example. )

This is the first thing, I am doing to find bugs. But I need hacking
methods to find mysterious bugs, i.e. in my lib there is a demo, which
displays to cubes. You can move and turn around you want. But when I stop
gpm - yes GPM - the cubes are behind you. When I start gpm again the cubes
are on the original place.

I've already done the experience, that I can't find those bugs with
printf's. I need really know-how about memory dumbing and many
many more...

> 
> The command gdb is the GNU debugger, it has "online" help as they say.  =)
> 
Hmm - I can't use gdb, because every time when I the debugged program
switches to graphic mode, I can't see, what gdb is doing... :(
I've already used xgdb and ddd, but when I try to debug library-internal
routines, both xgdb and ddd says, that there aren't any debugging-infos,
although I usually compile my lib with the gcc option -g3.

> I'm assuming you're new to linux not coding...  

Where do you want to know that? I am programming in C since 3 years. The
first 2 years only for DOS, but now... :)

> It helps to always keep backups so you can diff the last working version
> to find mistakes quickly!

I am friendly with patch and diff.
> 
> As the English transvestite comic says "ciao".

As you mean... :-)
> 
> 
> cheers,
> Terry
> 
> 
>  ---------------------------------------------------
> | BotShop     http://www.planetquake.com/botshop    |
> | Personal    http://www.westga.edu.com/~stu7440    |
> |                                                   |
> |         Alita is running linux 2.2.10             |
> 

Christoph Egger
E-Mail: Christoph_Egger@t-online.de