<div dir="ltr"><div><div><br><br>On Mon, May 18, 2015 at 7:50 AM, Sören Gebbert <<a href="mailto:soerengebbert@googlemail.com">soerengebbert@googlemail.com</a>> wrote:<br>><br>> Hi Vaclav,<br>> Many thanks for this report. This is really strange, i never run in<br>> such problems and cannot reproduce this (3h execution time) on AMD<br>> Phenom II with Ubuntu 12.04, AMD FX8350 with Ubuntu 14.04 and google<br>> cloud compute engine with Ubuntu 14.04 and debian.<br><br></div>It happens to me on some Dell with some Intel and Ubuntu 14.04. Note that it happens with the Italian Location, not NC SPM.<br><br>First, I though it is related to "RPC and lib/python/temporal/testsuite/test_doctests.py on MS Windows" (<a href="http://lists.osgeo.org/pipermail/grass-dev/2015-February/074037.html">http://lists.osgeo.org/pipermail/grass-dev/2015-February/074037.html</a>) or to lib/python/pygrass/vector/testsuite/test_doctest.py leaving processes behind* but it is a different test.<br><br></div><div>* I can't find any post about it. I would say I reported that but apparently not. Basically I find every day in process manager 5 processes `python -3 -tt lib/python/pygrass/vector/testsuite/test_doctest.py`. I run the tests 3 times (in 3 different locations). The processes are sleeping with pool_schedule_timeout. This one might be related to the "lib/python/pygrass/vector/testsuite/test_doctest.py SIGSEGV" (<a href="http://lists.osgeo.org/pipermail/grass-dev/2014-October/071393.html">http://lists.osgeo.org/pipermail/grass-dev/2014-October/071393.html</a>) where Vect_get_num_primitives(), Vect_line_prune() or most often Vect_get_num_db_links() segfaults. Perhaps the functions just cannot deal with maps with don't exist.<br><br>> However, on my machines (AMD Phenom II with Ubuntu 12.04, AMD FX8350<br>> with Ubuntu 14.04 ) the g.remove process segfaults most of the time<br>> when called from PyGRASS?? And i have no idea why.<br><br></div><div><div>I think I'm getting the same error. I was able to reproduce it on one machine with one particular compilation. Although I'm able to reproduce it repetitively (after make distclean) for some time already, it happens just with one particular svn dir and build. It does not happen on the same machine with different svn dir and build. I was not able to figure out what is the difference.<br></div><div><br></div><div>Thanks for looking into this,<br></div><div>Vaclav<br></div><div><br>> I will try to investigate this on different computers in my Institute.<br>><br>> Best regards<br>> Soeren<br>><br>> 2015-05-11 15:52 GMT+02:00 Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com">wenzeslaus@gmail.com</a>>:<br>> > Hi,<br>> ><br>> > when I run t.connect test test_distr_tgis_db_raster.py [0] in Piemonte<br>> > Location [1], it takes 3.5 hours to complete [2]. This is happening<br>> > constantly for a long time already [3]. There is nothing in the outputs<br>> > which would indicate anything like this. Any ideas?<br>> ><br>> > In case you wonder how different data influence the time, then you can see<br>> > run in NC SPM Location [4] and in an empty XY Location [5]. Also, similar<br>> > tests for 3D raster and vector data are fine [6, 7].<br>> ><br>> > Is somebody able to reproduce that behavior or determine why it is<br>> > happening?<br>> ><br>> > Thanks,<br>> > Vaclav<br>> ><br>> ><br>> > [0]<br>> > <a href="http://trac.osgeo.org/grass/browser/grass/trunk/temporal/t.connect/testsuite/test_distr_tgis_db_raster.py">http://trac.osgeo.org/grass/browser/grass/trunk/temporal/t.connect/testsuite/test_distr_tgis_db_raster.py</a><br>> > [1] <a href="http://grass.osgeo.org/download/sample-data/">http://grass.osgeo.org/download/sample-data/</a><br>> > [2]<br>> > <a href="http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/temporal/t.connect/test_distr_tgis_db_raster/index.html">http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/temporal/t.connect/test_distr_tgis_db_raster/index.html</a><br>> > [3]<br>> > <a href="http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-10-02-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/temporal/t.connect/test_distr_tgis_db_raster/index.html">http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-10-02-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/temporal/t.connect/test_distr_tgis_db_raster/index.html</a><br>> > [4]<br>> > <a href="http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_nc_spm_08_grass7_nc/temporal/t.connect/test_distr_tgis_db_raster/index.html">http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_nc_spm_08_grass7_nc/temporal/t.connect/test_distr_tgis_db_raster/index.html</a><br>> > [5]<br>> > <a href="http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_empty_xy_all/temporal/t.connect/test_distr_tgis_db_raster/index.html">http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_empty_xy_all/temporal/t.connect/test_distr_tgis_db_raster/index.html</a><br>> > [6]<br>> > <a href="http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/temporal/t.connect/test_distr_tgis_db_raster3d/index.html">http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/temporal/t.connect/test_distr_tgis_db_raster3d/index.html</a><br>> > [7]<br>> > <a href="http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/temporal/t.connect/test_distr_tgis_db_vector/index.html">http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/temporal/t.connect/test_distr_tgis_db_vector/index.html</a><br><br></div></div></div>