GDB 4.16 dumps core with egcs-1.0

[Ronald Wahl]

On Tue, 13 Jan 1998, Raffaele Sena wrote:

> > 
> > Now I use pgcc-1.0.1 (based on egcs-1.0.1) and the bug still occurs. I
> > don't think that pgcc changes the init-code.
> > 
> 	Again, you should be able to get a working gdb by uncommenting
> 	the following lines in gdb-4.16/gdb/Makefile.in and
> 	rebuilding gdb:
> 
> 	Makefile.in: line 96
> 
> 	# To use your system malloc, uncomment MMALLOC_DISABLE.
> 	#MMALLOC_DISABLE = -DNO_MMALLOC
> 	# To use mmalloc but disable corruption checking, uncomment MMALLOC_CHECK
> 	#MMALLOC_CHECK = -DNO_MMALLOC_CHECK
> 
> 	Maybe you also want to comment out the previous lines, just to
> 	make sure.
> 
> 
> 	Also, I'm still not convinced egcs is responsible for the problem.
> 	Even if it calls malloc in the initial phase, when it's linked
> 	with the mmalloc package, all the standard allocation functions
> 	(malloc, free, calloc, realloc) are redefined to call the
> 	m-functions.
> [...] 

I found the problem. If I compile with my systems static readline library
I get the following:

...
/usr/lib/libreadline.a(shell.o): In function `savestring':
shell.o(.text+0x0): multiple definition of `savestring'
utils.o(.text+0x730): first defined here
ld: Warning: size of symbol `savestring' changed from 102 to 40 in shell.o
...

It seems that we have a symbol conflict which should be fixed in gdb. Now
I decided to use the static readline which comes with gdb. After linking
 the problem still occurs if I do link the libtermcap dynamically. Linking
it statically the bug don't show up. Linking gdb with my systems readline
(dynamic) and the static libtermcap also works. So the symbol conflict is
not the reason. The problem seems to be in libtermcap (memory leak?).

ron

-- 
\ Ronald Wahl --- rwa@informatik.tu-chemnitz.de   \
 \ WWW: http://www.tu-chemnitz.de/~row             \
  \ Talk: rwa@goliath.csn.tu-chemnitz.de            \
   \ PGP key available by finger to my email address \