On Mon, Oct 13, 2014 at 10:26 AM, Vaclav Petras <[email protected]> wrote:
> > > On Tue, Sep 23, 2014 at 1:44 PM, Vaclav Petras <[email protected]> > wrote: > >> >> >> On Mon, Sep 22, 2014 at 9:53 AM, Vaclav Petras <[email protected]> >> wrote: >> >>> >>> On Wed, Sep 17, 2014 at 9:22 AM, Vaclav Petras <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> doctest for pygrass.vector are crashing with segmentation fault in >>>> Vect_gen_num_db_links() function. >>>> >>>> ... >>>> >>>> Unfortunately, the segfault is not visible in test report, output just >>>> ends. The return code of all -11, does this mean something? Do you know how >>>> to get the info which is available to system crash handler (which contains >>>> "crashed with SIGSEGV", function name and even call stack)? >>>> >>>> I got the crash report again, now with >>> >>> test_doctest.py crashed with SIGSEGV in Vect_line_prune() >>> >>> in piemonte_utf32_wgs84_grass7 location. >>> >>> Now again segmentation fault in Vect_get_num_db_links(). There were some >> details about "target" and "source", not sure if really useful but it would >> be great to have a way to obtain this info. >> >> > This error is still present. The tests expects to run in NC basic location > but it runs in full one, so the map names are slightly different. So, it > should fail but to with segmentation fault. > > Just to provide an update, there is some randomness, now the segmentation fault is in Vect_get_num_primitives(). Anyway, now I noticed that there are some processes still alive after the > tests ended. All have status "Sleeping" and each uses about 20 MB of > memory, waiting channel is "poll_schedule_timeout", all are "python ... > /path/to/pygrass/vector/testsuite/test_doctest.py". Now I have 5 processes > for each day. I'm not completely sure about their times, 3 are from one > hour and 2 from another. I run all tests 3 times (in different locations). > I was not make sense out of the times and process count but it is highly > probable that it relates to the segmentation fault since it is the same > file. > > If you have some ideas about the processes, please share. It would be good > if somebody could test it. > > To run the test use > > python test_doctest.py > > in `lib/python/pygrass/vector/testsuite` directory and NC sample location > (you can try both basic and full). > > To run the test as a part of all other tests use > > python -m grass.gunittest.main --location nc_spm_grass7 --location-type nc > > in GRASS session in GRASS source code top directory (it will use current > session and GISDBASE/grassdata). > > > Vaclav > > > > http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-10-13-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/lib/python/pygrass/vector/test_doctests/index.html > > http://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html#testing-with-gunittest-package-in-general > > http://grass.osgeo.org/grass71/manuals/libpython/gunittest_running_tests.html > > >> Again, the info is only in system crash report dialog. It is even not >>> visible in the report: >>> >>> >>> http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-09-22-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/lib/python/pygrass/vector/test_doctests/index.html >>> >>> If somebody has a experience with getting these reports or information >>> about process segmentation fault, please let me know. >>> >>> Vaclav >>> >>> >> >
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
