[GRASS-dev] Heisenbug in v.out.ascii with column parameter: segfault

GRASS GRASS developer
1

Hi,

I get a Heisenbug [1] when exporting points from v.out.ascii with attributes
(Scientific Linux, 64bit):

GRASS 6.4.0svn (patUTM32):~ > v.out.ascii phd_area_main_cities column=name
Segmentation fault

GRASS 6.4.0svn (patUTM32):~ > gdb v.out.ascii
GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
...
This GDB was configured as "x86_64-redhat-linux-gnu"...(no debugging
symbols found)
Using host libthread_db library "/lib64/libthread_db.so.1".

(gdb) r phd_area_main_cities column=name
Starting program:
/home/neteler/binaries/grass-6.4.0svn/bin/v.out.ascii
phd_area_main_cities column=name
(no debugging symbols found)
...
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 47548720613104 (LWP 7517)]
(no debugging symbols found)
[Detaching after fork from child process 7520. (Try `set detach-on-fork off'.)]
664070.15136424|5103723.69345589|1|Trento
680631.89931785|5152080.37972013|2|Bolzano - Bozen
748566.88848245|5114436.80436153|3|Belluno
753217.48877466|5062320.47156408|4|Treviso
783478.0559796|5095956.26859946|5|Pordenone
Program exited normally.

GRASS 6.4.0svn (patUTM32):~ > v.out.ascii phd_area_main_cities column=name
Segmentation fault

Yes, I didn't compile with -g because it is my production machine but
since it works in GDB...

Any idea how to debug this problem?

thanks
Markus

[1] http://en.wikipedia.org/wiki/Unusual_software_bug#Heisenbug

2

Hello,
try valgrind:

valgrind --tool=memcheck v.out.ascii phd_area_main_cities column=name

Sören

2009/9/9 Markus Neteler <neteler@osgeo.org>

Hi,

I get a Heisenbug [1] when exporting points from v.out.ascii with attributes
(Scientific Linux, 64bit):

GRASS 6.4.0svn (patUTM32):~ > v.out.ascii phd_area_main_cities column=name
Segmentation fault

GRASS 6.4.0svn (patUTM32):~ > gdb v.out.ascii
GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
…
This GDB was configured as “x86_64-redhat-linux-gnu”…(no debugging
symbols found)
Using host libthread_db library “/lib64/libthread_db.so.1”.

(gdb) r phd_area_main_cities column=name
Starting program:
/home/neteler/binaries/grass-6.4.0svn/bin/v.out.ascii
phd_area_main_cities column=name
(no debugging symbols found)
…
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 47548720613104 (LWP 7517)]
(no debugging symbols found)
[Detaching after fork from child process 7520. (Try `set detach-on-fork off’.)]
664070.15136424|5103723.69345589|1|Trento
680631.89931785|5152080.37972013|2|Bolzano - Bozen
748566.88848245|5114436.80436153|3|Belluno
753217.48877466|5062320.47156408|4|Treviso
783478.0559796|5095956.26859946|5|Pordenone
Program exited normally.

GRASS 6.4.0svn (patUTM32):~ > v.out.ascii phd_area_main_cities column=name
Segmentation fault

Yes, I didn’t compile with -g because it is my production machine but
since it works in GDB…

Any idea how to debug this problem?

thanks
Markus

[1] http://en.wikipedia.org/wiki/Unusual_software_bug#Heisenbug

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

3

Here we are:

GRASS 6.4.0svn (patUTM32):~ > valgrind --tool=memcheck v.out.ascii
phd_area_main_cities column=name
==26104== Memcheck, a memory error detector.
==26104== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==26104== Using LibVEX rev 1854, a library for dynamic binary translation.
==26104== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==26104== Using valgrind-3.3.1, a dynamic binary instrumentation framework.
==26104== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==26104== For more details, rerun with: -v
==26104==
==26104== Conditional jump or move depends on uninitialised value(s)
==26104== at 0x4E4F408: db_enlarge_string (in
/home/neteler/binaries/grass-6.4.0svn/lib/libgrass_dbmibase.6.4.0svn.so)
==26104== by 0x4E4F50C: set_string (in
/home/neteler/binaries/grass-6.4.0svn/lib/libgrass_dbmibase.6.4.0svn.so)
==26104== by 0x4E4FD39: db_copy_value (in
/home/neteler/binaries/grass-6.4.0svn/lib/libgrass_dbmibase.6.4.0svn.so)
==26104== by 0x54DC58D: db_select_value (in
/home/neteler/binaries/grass-6.4.0svn/lib/libgrass_dbmiclient.6.4.0svn.so)
==26104== by 0x40210E: bin_to_asc (in
/home/neteler/binaries/grass-6.4.0svn/bin/v.out.ascii)
==26104== by 0x402A79: main (in
/home/neteler/binaries/grass-6.4.0svn/bin/v.out.ascii)
==26104==
==26104== Conditional jump or move depends on uninitialised value(s)
==26104== at 0x4E4F417: db_enlarge_string (in
/home/neteler/binaries/grass-6.4.0svn/lib/libgrass_dbmibase.6.4.0svn.so)
==26104== by 0x4E4F50C: set_string (in
/home/neteler/binaries/grass-6.4.0svn/lib/libgrass_dbmibase.6.4.0svn.so)
==26104== by 0x4E4FD39: db_copy_value (in
/home/neteler/binaries/grass-6.4.0svn/lib/libgrass_dbmibase.6.4.0svn.so)
==26104== by 0x54DC58D: db_select_value (in
/home/neteler/binaries/grass-6.4.0svn/lib/libgrass_dbmiclient.6.4.0svn.so)
==26104== by 0x40210E: bin_to_asc (in
/home/neteler/binaries/grass-6.4.0svn/bin/v.out.ascii)
==26104== by 0x402A79: main (in
/home/neteler/binaries/grass-6.4.0svn/bin/v.out.ascii)
664070.15136424|5103723.69345589|1|Trento
680631.89931785|5152080.37972013|2|Bolzano - Bozen
748566.88848245|5114436.80436153|3|Belluno
753217.48877466|5062320.47156408|4|Treviso
783478.0559796|5095956.26859946|5|Pordenone
==26104==
==26104== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 5 from 1)
==26104== malloc/free: in use at exit: 20,632 bytes in 186 blocks.
==26104== malloc/free: 495 allocs, 309 frees, 46,512 bytes allocated.
==26104== For counts of detected errors, rerun with: -v
==26104== searching for pointers to 186 not-freed blocks.
==26104== checked 779,376 bytes.
==26104==
==26104== LEAK SUMMARY:
==26104== definitely lost: 13,863 bytes in 103 blocks.
==26104== possibly lost: 0 bytes in 0 blocks.
==26104== still reachable: 6,769 bytes in 83 blocks.
==26104== suppressed: 0 bytes in 0 blocks.
==26104== Rerun with --leak-check=full to see details of leaked memory.

Doesn't tell me too much... :frowning: I guess an extra trick is needed to include
DBMI checking.

Markus

On Wed, Sep 9, 2009 at 12:14 PM, Soeren
Gebbert<soerengebbert@googlemail.com> wrote:

Hello,
try valgrind:

valgrind --tool=memcheck v.out.ascii phd_area_main_cities column=name

Sören

2009/9/9 Markus Neteler <neteler@osgeo.org>

Hi,

I get a Heisenbug [1] when exporting points from v.out.ascii with
attributes
(Scientific Linux, 64bit):

GRASS 6.4.0svn (patUTM32):~ > v.out.ascii phd_area_main_cities column=name
Segmentation fault

GRASS 6.4.0svn (patUTM32):~ > gdb v.out.ascii
GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
...
This GDB was configured as "x86_64-redhat-linux-gnu"...(no debugging
symbols found)
Using host libthread_db library "/lib64/libthread_db.so.1".

(gdb) r phd_area_main_cities column=name
Starting program:
/home/neteler/binaries/grass-6.4.0svn/bin/v.out.ascii
phd_area_main_cities column=name
(no debugging symbols found)
...
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 47548720613104 (LWP 7517)]
(no debugging symbols found)
[Detaching after fork from child process 7520. (Try `set detach-on-fork
off'.)]
664070.15136424|5103723.69345589|1|Trento
680631.89931785|5152080.37972013|2|Bolzano - Bozen
748566.88848245|5114436.80436153|3|Belluno
753217.48877466|5062320.47156408|4|Treviso
783478.0559796|5095956.26859946|5|Pordenone
Program exited normally.

GRASS 6.4.0svn (patUTM32):~ > v.out.ascii phd_area_main_cities column=name
Segmentation fault

Yes, I didn't compile with -g because it is my production machine but
since it works in GDB...

Any idea how to debug this problem?

thanks
Markus

[1] http://en.wikipedia.org/wiki/Unusual_software_bug#Heisenbug
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

4

Hmmm, the bad thing is that the segfault disappear when using valgrind.
The uninitialised value report must not point to the root of the segfault.

To enable detailed information, grass must be compiled with debug information … .
I don’t know what to do.

Best regrads
Soeren

2009/9/9 Markus Neteler <neteler@osgeo.org>

Here we are:

GRASS 6.4.0svn (patUTM32):~ > valgrind --tool=memcheck v.out.ascii

phd_area_main_cities column=name

==26104== Memcheck, a memory error detector.
==26104== Copyright (C) 2002-2007, and GNU GPL’d, by Julian Seward et al.
==26104== Using LibVEX rev 1854, a library for dynamic binary translation.
==26104== Copyright (C) 2004-2007, and GNU GPL’d, by OpenWorks LLP.
==26104== Using valgrind-3.3.1, a dynamic binary instrumentation framework.
==26104== Copyright (C) 2000-2007, and GNU GPL’d, by Julian Seward et al.
==26104== For more details, rerun with: -v
==26104==
==26104== Conditional jump or move depends on uninitialised value(s)
==26104== at 0x4E4F408: db_enlarge_string (in
/home/neteler/binaries/grass-6.4.0svn/lib/libgrass_dbmibase.6.4.0svn.so)
==26104== by 0x4E4F50C: set_string (in
/home/neteler/binaries/grass-6.4.0svn/lib/libgrass_dbmibase.6.4.0svn.so)
==26104== by 0x4E4FD39: db_copy_value (in
/home/neteler/binaries/grass-6.4.0svn/lib/libgrass_dbmibase.6.4.0svn.so)
==26104== by 0x54DC58D: db_select_value (in
/home/neteler/binaries/grass-6.4.0svn/lib/libgrass_dbmiclient.6.4.0svn.so)
==26104== by 0x40210E: bin_to_asc (in
/home/neteler/binaries/grass-6.4.0svn/bin/v.out.ascii)
==26104== by 0x402A79: main (in
/home/neteler/binaries/grass-6.4.0svn/bin/v.out.ascii)
==26104==
==26104== Conditional jump or move depends on uninitialised value(s)
==26104== at 0x4E4F417: db_enlarge_string (in
/home/neteler/binaries/grass-6.4.0svn/lib/libgrass_dbmibase.6.4.0svn.so)
==26104== by 0x4E4F50C: set_string (in
/home/neteler/binaries/grass-6.4.0svn/lib/libgrass_dbmibase.6.4.0svn.so)
==26104== by 0x4E4FD39: db_copy_value (in
/home/neteler/binaries/grass-6.4.0svn/lib/libgrass_dbmibase.6.4.0svn.so)
==26104== by 0x54DC58D: db_select_value (in
/home/neteler/binaries/grass-6.4.0svn/lib/libgrass_dbmiclient.6.4.0svn.so)
==26104== by 0x40210E: bin_to_asc (in
/home/neteler/binaries/grass-6.4.0svn/bin/v.out.ascii)
==26104== by 0x402A79: main (in
/home/neteler/binaries/grass-6.4.0svn/bin/v.out.ascii)

664070.15136424|5103723.69345589|1|Trento
680631.89931785|5152080.37972013|2|Bolzano - Bozen
748566.88848245|5114436.80436153|3|Belluno
753217.48877466|5062320.47156408|4|Treviso
783478.0559796|5095956.26859946|5|Pordenone

==26104==
==26104== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 5 from 1)
==26104== malloc/free: in use at exit: 20,632 bytes in 186 blocks.
==26104== malloc/free: 495 allocs, 309 frees, 46,512 bytes allocated.
==26104== For counts of detected errors, rerun with: -v
==26104== searching for pointers to 186 not-freed blocks.
==26104== checked 779,376 bytes.
==26104==
==26104== LEAK SUMMARY:
==26104== definitely lost: 13,863 bytes in 103 blocks.
==26104== possibly lost: 0 bytes in 0 blocks.
==26104== still reachable: 6,769 bytes in 83 blocks.
==26104== suppressed: 0 bytes in 0 blocks.
==26104== Rerun with --leak-check=full to see details of leaked memory.

Doesn’t tell me too much… :frowning: I guess an extra trick is needed to include
DBMI checking.

Markus

On Wed, Sep 9, 2009 at 12:14 PM, Soeren
Gebbert<soerengebbert@googlemail.com> wrote:

Hello,
try valgrind:

valgrind --tool=memcheck v.out.ascii phd_area_main_cities column=name

Sören

2009/9/9 Markus Neteler <neteler@osgeo.org>

Hi,

I get a Heisenbug [1] when exporting points from v.out.ascii with
attributes
(Scientific Linux, 64bit):

GRASS 6.4.0svn (patUTM32):~ > v.out.ascii phd_area_main_cities column=name
Segmentation fault

GRASS 6.4.0svn (patUTM32):~ > gdb v.out.ascii
GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
…
This GDB was configured as “x86_64-redhat-linux-gnu”…(no debugging
symbols found)
Using host libthread_db library “/lib64/libthread_db.so.1”.

(gdb) r phd_area_main_cities column=name
Starting program:
/home/neteler/binaries/grass-6.4.0svn/bin/v.out.ascii
phd_area_main_cities column=name
(no debugging symbols found)
…
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 47548720613104 (LWP 7517)]
(no debugging symbols found)
[Detaching after fork from child process 7520. (Try `set detach-on-fork
off’.)]
664070.15136424|5103723.69345589|1|Trento
680631.89931785|5152080.37972013|2|Bolzano - Bozen
748566.88848245|5114436.80436153|3|Belluno
753217.48877466|5062320.47156408|4|Treviso
783478.0559796|5095956.26859946|5|Pordenone
Program exited normally.

GRASS 6.4.0svn (patUTM32):~ > v.out.ascii phd_area_main_cities column=name
Segmentation fault

Yes, I didn’t compile with -g because it is my production machine but
since it works in GDB…

Any idea how to debug this problem?

thanks
Markus

[1] http://en.wikipedia.org/wiki/Unusual_software_bug#Heisenbug

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

5

Soeren wrote:

Hmmm, the bad thing is that the segfault
disappear when using valgrind.
The uninitialised value report must not point to the root
of the segfault.

To enable detailed information, grass must be compiled with
debug information ... .

I don't know what to do.

run with "--verbose" and 'g.gisenv set="DEBUG=5"'

see also v.in.ascii column wish/bug + patch in trac bug list

https://trac.osgeo.org/grass/report/13

for tips on how to have valgrind check DB background process
too see http://grass.osgeo.org/wiki/bugs

is the datafile avail for testing?

Hamish

6

On Wed, Sep 9, 2009 at 6:48 PM, Hamish<hamish_b@yahoo.com> wrote:

run with "--verbose" and 'g.gisenv set="DEBUG=5"'

Benjamin:

running valgrind with options --leck-check=full

Right now the radio bridge to my office is down and I cannot
try (tomorrow).

see also v.in.ascii column wish/bug + patch in trac bug list

https://trac.osgeo.org/grass/report/13

Is https://trac.osgeo.org/grass/ticket/198 related? I see a patch
sleeping there...

for tips on how to have valgrind check DB background process
too see http://grass.osgeo.org/wiki/bugs

I tried with
http://grass.osgeo.org/wiki/Bugs#Using_Valgrind

but need to try harder.

is the datafile avail for testing?

Yes, attached now to
http://trac.osgeo.org/grass/ticket/746

Markus

(attachments)

phd_area_main_cities.tgz (1.04 KB)