[GRASS-dev] more d.vect-kills-x0

GRASS GIS GRASS GIS developer
1

Hi,

revisiting this bug report:
http://intevation.de/rt/webrt?serial_num=5263&display=History

I discovered that this sequence:

# in spearfish:

g.region rast=roads -a
r.thin roads out=roads_thin
r.to.vect -v input=roads_thin output=roads_thin_vect_cat feature=line

g.region n=4922490 s=4921260 e=600300 w=598620 res=30 -a
d.rast roads_thin
d.vect -c roads_thin_vect_cat

kills the X monitor (the last line).

Running it like this:
GRASS_RENDER_IMMEDIATE=TRUE gdb d.vect
(gdb) r -c roads_thin_vect_cat
Starting program: /home/neteler/soft/63grass_cvsexp/dist.i686-pc-linux-gnu/bin/d.vect -c roads_thin_vect_cat
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xbfffe000
[Thread debugging using libthread_db enabled]
[New Thread -1229416752 (LWP 12291)]
PNG: GRASS_TRUECOLOR status: FALSE
PNG: collecting to map.png,
GRASS_WIDTH=640, GRASS_HEIGHT=480
Program exited normally.

doesn't kill it any more. Running it without RENDER_IMMEDIATE,
it fails:

Program received signal SIGPIPE, Broken pipe.
[Switching to Thread -1229146416 (LWP 12411)]
0xbfffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xbfffe410 in __kernel_vsyscall ()
#1 0xb78e9b93 in write () from /lib/i686/libc.so.6
#2 0xb7f521e0 in flushout () at rem_io.c:58
#3 0xb7f52221 in _send_char (achar=0xbf9f4258 "") at rem_io.c:81
#4 0xb7f5228c in _send_char_array (num=4, achar=Variable "achar" is not available.
) at rem_io.c:92
#5 0xb7f522f1 in _send_int (anint=0xbf9f4258) at rem_io.c:109
#6 0xb7f533ed in REM_polydots_abs (xarray=0x80ca878, yarray=0x80ca888, number=0) at rem_proto.c:253
#7 0xb7f50659 in R_polydots_abs (xarray=0x80ca878, yarray=0x80ca888, number=0) at com_proto.c:232
#8 0xb7fdee2f in D_polydots_clip (x=0x80ca390, y=0x80ca528, n=1) at draw2.c:469
#9 0x0804f817 in plot1 (Map=0xbf9f6614, type=31, area=1, Clist=0x806e438, color=0xbf9f6af1,
    fcolor=0xbf9f6aee, chcat=0, Symb=0x806e4e0, size=8, id_flag=0, table_colors_flag=0, cats_color_flag=1,
    rgb_column=0x8050c4a "GRASSRGB", default_width=0, width_column=0x0, width_scale=1) at plot1.c:473
#10 0x0804e650 in main (argc=3, argv=0xbf9f6bb4) at main.c:654

[this time everything should be copied here]

BTW: I recompiled from scratch.
GRASS_TRUECOLOR status: FALSE as last time.

Markus

2

Markus Neteler wrote:

revisiting this bug report:
http://intevation.de/rt/webrt?serial_num=5263&display=History

I discovered that this sequence:

# in spearfish:

g.region rast=roads -a
r.thin roads out=roads_thin
r.to.vect -v input=roads_thin output=roads_thin_vect_cat feature=line

g.region n=4922490 s=4921260 e=600300 w=598620 res=30 -a
d.rast roads_thin
d.vect -c roads_thin_vect_cat

kills the X monitor (the last line).

I can reproduce this.

plot1() calls D_polydots_clip() with n==1. If the point is outside the
clip region, D_polydots_clip() calls R_polydots_abs() with number==0.
For the default COM_Polydots_{abs,rel}() implementations, this is a
no-op, but XDRIVER does:

  cur_x = xpnts[number - 1].x;
  cur_y = xpnts[number - 1].y;

xpnts is NULL (a zero-byte malloc() may return NULL), hence XDRIVER
segfaults and dies.

AFAICT, XDRIVER has always had this bug, but nothing ever tried to
draw zero dots before D_polydots_clip() was added.

I've added a test to XDRIVER's polydots/polyline/polygon
functions, which appears to fix the problem.

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

3

On Wed, May 09, 2007 at 10:02:08PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> revisiting this bug report:
> http://intevation.de/rt/webrt?serial_num=5263&display=History
>
> I discovered that this sequence:
>
> # in spearfish:
>
> g.region rast=roads -a
> r.thin roads out=roads_thin
> r.to.vect -v input=roads_thin output=roads_thin_vect_cat feature=line
>
> g.region n=4922490 s=4921260 e=600300 w=598620 res=30 -a
> d.rast roads_thin
> d.vect -c roads_thin_vect_cat
>
> kills the X monitor (the last line).

I can reproduce this.

plot1() calls D_polydots_clip() with n==1. If the point is outside the
clip region, D_polydots_clip() calls R_polydots_abs() with number==0.
For the default COM_Polydots_{abs,rel}() implementations, this is a
no-op, but XDRIVER does:

  cur_x = xpnts[number - 1].x;
  cur_y = xpnts[number - 1].y;

xpnts is NULL (a zero-byte malloc() may return NULL), hence XDRIVER
segfaults and dies.

AFAICT, XDRIVER has always had this bug, but nothing ever tried to
draw zero dots before D_polydots_clip() was added.

I've added a test to XDRIVER's polydots/polyline/polygon
functions, which appears to fix the problem.

Thanks, now it works.

Markus