[GRASS-dev] lib/python/pygrass/vector/testsuite/test_doctest.py SIGSEGV

[Vaclav Petras]

On Mon, Oct 13, 2014 at 10:26 AM, Vaclav Petras <wenzeslaus at gmail.com>
wrote:

>
>
> On Tue, Sep 23, 2014 at 1:44 PM, Vaclav Petras <wenzeslaus at gmail.com>
> wrote:
>
>>
>>
>> On Mon, Sep 22, 2014 at 9:53 AM, Vaclav Petras <wenzeslaus at gmail.com>
>> wrote:
>>
>>>
>>> On Wed, Sep 17, 2014 at 9:22 AM, Vaclav Petras <wenzeslaus at gmail.com>
>>> 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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20141028/4d7e8b41/attachment-0001.html>