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

[Росен Матев]

Hi all,

First of all, thanks Hamish for the helpful responses.
I was looking into the lib/linkm sources and I'm confused. Either the
library is pretty messy or I'm overlooking something. This linked list
manager should be rewritten. Luckily it is used in quite a few places
in GRASS. Please take a look at list_new() [1] and link__get_next(),
link__set_next() [2]. And then see how the list is used in [3].

[1] http://download.osgeo.org/grass/grass6_progman/new_8c-source.html#l00012
[2] http://download.osgeo.org/grass/grass6_progman/linkm_2next_8c-source.html
[3] http://download.osgeo.org/grass/grass6_progman/Vlib_2poly_8c-source.html#l00180

Regards,
Rosen Matev

On Fri, Sep 12, 2008 at 5:29 AM, Hamish <hamish_b at yahoo.com> wrote:
> Росен Матев 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
>
>
>
>