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

[Glynn Clements]

Markus Neteler wrote:

> GRASS 6.3.cvs (spearfish60):~/grass63/scripts > GRASS_RENDER_IMMEDIATE=TRUE gdb d.vect
> GNU gdb 6.3-8mdv2007.0 (Mandriva Linux release 2007.0)
> ...
> (gdb) run myroads_net col=red
> Starting program: /home/neteler/soft/63grass_cvsexp/dist.i686-pc-linux-gnu/bin/d.vect myroads_net col=red
> Reading symbols from shared object read from target memory...done.
> Loaded system supplied DSO at 0xbfffe000
> [Thread debugging using libthread_db enabled]
> [New Thread -1225832752 (LWP 14496)]
> PNG: GRASS_TRUECOLOR status: FALSE
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1225832752 (LWP 14496)]
> 0xb77e42d8 in fputs () from /lib/i686/libc.so.6
> (gdb) bt
> #0  0xb77e42d8 in fputs () from /lib/i686/libc.so.6
> #1  0xb7ec37a0 in print_error (
>     msg=0xbfde35a0 "PNG: collecting to  map.png,\n     GRASS_WIDTH=640, GRASS_HEIGHT=480", type=0)
>     at error.c:276
> #2  0xb7ec3ca5 in G_message (
>     msg=0xb7e637c8 "PNG: collecting to  %s,\n     GRASS_WIDTH=%d, GRASS_HEIGHT=%d") at error.c:112
> #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

> #2  0xb7ec3ca5 in G_message (
>     msg=0xb7e637c8 "PNG: collecting to  %s,\n     GRASS_WIDTH=%d, GRASS_HEIGHT=%d") at error.c:112

Huh? Where did the "file:" go?

> #3  0xb7e61c62 in PNG_Graph_set (argc=0, argv=0x0) at Graph_set.c:133

133	G_message("PNG: collecting to file: %s,\n     GRASS_WIDTH=%d, GRASS_HEIGHT=%d",
134		file_name, width, height);

It may be that this is just a problem with the way that you copied the
output into the message (in which case, use "script" and a text editor
and attach the output; if you're posting diagnostic output, it needs
to be *exact*).

Apart from that:

> #0  0xb77e42d8 in fputs () from /lib/i686/libc.so.6
> #1  0xb7ec37a0 in print_error (
>     msg=0xbfde35a0 "PNG: collecting to  map.png,\n     GRASS_WIDTH=640, GRASS_HEIGHT=480", type=0)
>     at error.c:276

276	    fprintf(stderr,"%s", prefix_std[type] );

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.

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