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 <[EMAIL PROTECTED]> 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 > > > >
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
