[GRASS-dev] d.vect kills d.mon

[Glynn Clements]

Glynn Clements wrote:

> > GRASS 6.3.cvs (spearfish60):~/grass63/scripts > GRASS_RENDER_IMMEDIATE=TRUE gdb d.vect

> > PNG: GRASS_TRUECOLOR status: FALSE

I missed this at first. After setting GRASS_TRUECOLOR=FALSE, I managed
to reproduce this and find the problem.

> I can't think of anything except for memory corruption. But:
> 
> > #3  0xb7e61c62 in PNG_Graph_set (argc=0, argv=0x0) at Graph_set.c:133
> > #4  0xb7e57351 in COM_Graph_set (argc=0, argv=0x0) at Graph.c:7
> > #5  0xb7e5869e in LIB_init (drv=0xb7e64f40, argc=0, argv=0x0) at init.c:79
> > #6  0xb7e6ad92 in LOC_open_driver () at loc_io.c:67
> > #7  0xb7e6a014 in R_open_driver () at com_io.c:180
> > #8  0x0804d7f5 in main (argc=3, argv=0xbfde6774) at main.c:375
> 
> 375	if (R_open_driver() != 0)
> 
> This is still really early, not long after G_parser() has returned. I
> can't see how anything in the actual d.vect code could cause this. 
> And, if it's a problem with the display architecture, I would expect
> it to affect a lot more than just d.vect.

It's due to a combination of factors:

1. Both libpngdriver and d.vect define variables named "palette".
2. GRASS_TRUECOLOR=FALSE initialises the wrong "palette" variable
(libpngdriver's is 256*4 bytes, d.vect's is only 16*4 bytes).
3. stdio structures reside shortly after d.vect's palette variable,
so when libpngdriver overflows it, stdio variables get corrupted.

IOW, it's only luck that it hasn't happened before.

The crash disappears if the library is built with -Wl,-Bsymbolic,
which causes libraries to bind to their own variable definitions
rather than allowing them to be overriden by the executable.

That should probably be the default. Relying upon libraries' global
variables not conflicting with those of an executable is bound to be
unreliable.

I can make that change to the Linux section of SC_CONFIG_CFLAGS in
aclocal.m4. It's already the default on Windows (you have to go to
some trouble to export symbols from the executable into a DLL). That
just leaves the sections for MacOSX, plus a couple of dozen platforms
which we pretend to support but don't really (i.e. all of the
commercial Unices).

-- 
Glynn Clements <glynn at gclements.plus.com>