Hi,
again some test failed because of segmentation fault and I’m wondering how to collect the information about it for the report.
In this case, it was crash of v.in.ogr called by script db.in.ogr, so I have absolutely no idea which process to hunt for except that it is a (grand) child of the test. It is not visible from the report:
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-10-20-07-00/report_for_nc_spm_08_grass7_nc/vector/v.what/test_vwhat_layers/index.html
I have the Ubuntu crash report dialog(s) but I would like to associate the information with the tests, so I need something which will recognize that there was a segmenation fault in one of the children and then it will collect the information.
I made a little progress on that except that I found that there are files in /var/crash which are somehow managed by some apport-* commands. Now I was able to get file
/var/crash/_opt_src_grass-trunk-tests_dist.x86_64-unknown-linux-gnu_bin_v.in.ogr.1000.crash
which is attached and contains following useful information:
v.in.ogr crashed with SIGSEGV in main()
v.in.ogr --q -o dsn=./data/table1.csv output=t1
v.what/test_vwhat_layers
SegvAnalysis
…
source … (0x000…00) not located in known VMA region (needed readable region)!
…
SegvReason
reading NULL VMA
Stacktrace
__strcmp_ssse3 in …/strcmp.S
in main()
If somebody has some ideas how to proceed or to which commands to look, please let me know.
Vaclav
(attachments)
_opt_src_grass-trunk-tests_dist.x86_64-unknown-linux-gnu_bin_v.in.ogr.1000.crash (6.33 KB)
On Mon, Oct 20, 2014 at 4:51 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
Hi,
again some test failed because of segmentation fault and I'm wondering how
to collect the information about it for the report.
In this case, it was crash of v.in.ogr called by script db.in.ogr, so I have
absolutely no idea which process to hunt for except that it is a (grand)
child of the test. It is not visible from the report:
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-10-20-07-00/report_for_nc_spm_08_grass7_nc/vector/v.what/test_vwhat_layers/index.html
...
v.in.ogr crashed with SIGSEGV in main()
v.in.ogr --q -o dsn=./data/table1.csv output=t1
v.what/test_vwhat_layers
...
Can you please add
db.connect -p
to the (local) test?
Maybe the driver is unset in the test case since a similar thing pops up here:
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-10-21-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/vector/v.what
/test_vwhat_layers/index.html
Just to be sure which driver is actually tried.
Markus
Hi,
2014-10-22 8:58 GMT+02:00 Markus Neteler <neteler@osgeo.org>:
v.in.ogr crashed with SIGSEGV in main()
v.in.ogr --q -o dsn=./data/table1.csv output=t1
v.what/test_vwhat_layers
...
Can you please add
db.connect -p
to the (local) test?
just wild guess, could be related to [1]? Martin
[1] http://trac.osgeo.org/grass/changeset/62325
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
On Wed, Oct 22, 2014 at 4:15 AM, Martin Landa <landa.martin@gmail.com>
wrote:
Hi,
2014-10-22 8:58 GMT+02:00 Markus Neteler <neteler@osgeo.org>:
>> v.in.ogr crashed with SIGSEGV in main()
>> v.in.ogr --q -o dsn=./data/table1.csv output=t1
>> v.what/test_vwhat_layers
> ...
>
> Can you please add
> db.connect -p
> to the (local) test?
just wild guess, could be related to [1]? Martin
[1] http://trac.osgeo.org/grass/changeset/62325
I though you are fixing it because of that. In fact I was looking at it at
that time but I was so glad that you committed the change because I was not
much successful.
Nevertheless, the test runs now, although I just expected the segmentation
fault to be fixed. (I don't know what caused the test to lead to the
segmentation fault in the first place.)
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-10-22-07-00/report_for_nc_spm_08_grass7_nc/vector/v.what/test_vwhat_layers/index.html
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa