[GRASS-dev] Re: Testing needed for v.buffer2

[Hamish]

Росен Матев wrote:
> My mentor Wolf and I are experiencing problems with the new buffer
> module. For some certain input it works well on my system but doesn't
> finish at all on Wolf's. We need some help to figure out what's
> happening. Here are the details:
>
> 1) checkout https://svn.osgeo.org/grass/grass-addons/vector/v.buffer2
> and compile the module

now compiles cleanly- cheers!

> 2) set DEBUG=3

ok,
 g.gisenv set="DEBUG=3"


> 3) run "v.buffer2 input=busroute11 output=busroute11_buf distance=31",
> where busroute11 is a map from nc_spm
> (distances < 31.3 are problematic, 32 is fine on Wolf's system)

I get the same, 31.4 and up are fine and take <1 sec to complete.
I notice this is when the sliver along parallel paths of Western Blvd.
first opens up.

v.buffer2 input=busroute11 output=busroute11_buf31 \
  distance=31 2> br11_buf31.txt

[wait wait wait]
 ^C

> 4) say whether the module finishes ok,  and send your debug output in
> case it didn't finish

Less than 31 never completes. Log attached.

> (on my machine it takes ~15 seconds for the module to finish
> outputting the debug info)

It will be much faster if you redirect it to a file versus displaying it
on the terminal. Some terms like gnome-terminal are very slow. xterm and
rxvt will be much faster but still not as fast as writing to a file.
  v.buffer2 ... 2> logfile.txt

Use "tee" if you want to see it both in the terminal & saved to a file:
  v.buffer2 ... 2>&1 | tee logfile.txt


I was curious to see where it was getting stuck, and so I threw it into
gdb (by way of kdbg):

kdbg `which v.buffer2`
Execution -> Arguments -> "input=busroute11 output=..."
Run
whiz bang whirl ... freeze
Execution -> Break
Execution -> Step Into
   .... link_dispose() in lib/linkm/dispose.c
Execution -> Step out
   .... destroy_links() in lib/vector/Vlib/poly.c

and if you step through from there it is stuck in the destroy_links()
loop.

if you go to View->Locals and expand the *tmp struct you will see as
you step along that *p and *tmp just bounce around in an endless circle
between two memory valid addresses, so it never reaches NULL.

The x value for those two are 638631.01569480076 and 637951.01569479937


Hamish



      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: br11_buf31.txt.gz
Type: application/x-gzip
Size: 13351 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20080911/68aff437/br11_buf31.txt-0001.gz