Opened 10 years ago

Closed 10 years ago

#746 closed defect (fixed)

v.out.ascii with column parameter: segfault

Reported by: neteler Owned by: grass-dev@…
Priority: normal Milestone: 6.4.0
Component: Vector Version: 6.4.0 RCs
Keywords: Cc:
CPU: x86-64 Platform: Linux

Description

I get a Heisenbug when exporting points from v.out.ascii with attributes (Scientific Linux 5, 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...

Sample location with small dataset attached.

Attachments (2)

utm32markus_location.tar.gz (1.9 KB) - added by neteler 10 years ago.
UTM32 location with related vector data set
v.out.ascii.diff (447 bytes) - added by neteler 10 years ago.
initialize value

Download all attachments as: .zip

Change History (9)

Changed 10 years ago by neteler

Attachment: utm32markus_location.tar.gz added

UTM32 location with related vector data set

comment:1 Changed 10 years ago by hamish

Hamish:

see also v.in.ascii column wish/bug + patch in trac bug list https://trac.osgeo.org/grass/report/13

Markus:

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

no sorry, I saw v.in.ascii not v.out.ascii. Nevermind.

ah, I can reproduce this on 64bit + CFLAGS=-g but not on 32bit + -g with gras 6.5svn.

hmph. 50% of the time it completes successfully. Sometimes I need to exit and restart GRASS to stir up the memory pool enough to get it to segfault again.

[...]
D1/1: Info->size = 159, Info->mtime = 1252533415
D1/1: coor size in head = 159, real coor file size= 159
D1/1: Vect_open_old(): vector opened on level 1
D1/1: Vect_read_dblinks(): map = phd_area_main_cities, mapset = markus
D1/1: dbln file: /home/hamish/grassdata/utm32/markus/vector/phd_area_main_cities/dbln
D1/1: dbln: 1 phd_area_main_cities cat $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ dbf
D1/1: field = 1 name = (null), table = phd_area_main_cities, key = cat, database = $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/, driver = dbf
D1/1: Dblinks read
D1/1: Vect_Rewind(): name = phd_area_main_cities
D1/1: Vect_get_field(): field = 1
D1/1: Vect_get_dblink(): link = 0
D1/1: Vect_Rewind(): name = phd_area_main_cities
Segmentation fault

ok, got it to fail with DEBUG=5:

[...]
D4/5: row 3
D4/5: eval_node node_type = 3
D4/5: eval_node node_type = 1
D4/5:     left = 2
D4/5:     left_dval = 4.000000
D4/5: eval_node node_type = 2
D4/5:     right = 2
D4/5:     right_dval = 1.000000
D4/5:     operator = 11
D4/5: condition = 0
D4/5: row 4
D4/5: eval_node node_type = 3
D4/5: eval_node node_type = 1
D4/5:     left = 2
D4/5:     left_dval = 5.000000
D4/5: eval_node node_type = 2
D4/5:     right = 2
D4/5:     right_dval = 1.000000
D4/5:     operator = 11
D4/5: condition = 0
D2/5: load_table_head(): tab = 0, /home/hamish/grassdata/utm32/markus/dbf//phd_area_main_cities.dbf
Segmentation fault

it seems to die on this in db_select_value():

if (count == 0)
    db_copy_value(val, value);

I'm guessing that *val has not been allocated any memory?

Hamish

comment:2 in reply to:  1 Changed 10 years ago by hamish

Replying to hamish:

it seems to die on this in db_select_value():

if (count == 0)
    db_copy_value(val, value);

I'm guessing that *val has not been allocated any memory?

in v.out.ascii/b2a.c bin_to_asc() there is

dbValue value;

but dbValue is a struct (see include/dbmi.h) which contains a dbString which contains char *string, which needs an alloc...

Hamish

comment:3 Changed 10 years ago by hamish

I get a bit more out of valgrind,

==28766== Conditional jump or move depends on uninitialised value(s)
==28766==    at 0x4C22D89: strlen (mc_replace_strmem.c:242)
==28766==    by 0x7356CB0: vfprintf (in /lib/libc-2.7.so)
==28766==    by 0x7357B5F: (within /lib/libc-2.7.so)
==28766==    by 0x7353435: vfprintf (in /lib/libc-2.7.so)
==28766==    by 0x52A8270: G_debug (debug.c:83)
==28766==    by 0x591A98F: db_select_value (select.c:230)
==28766==    by 0x402473: bin_to_asc (b2a.c:217)
==28766==    by 0x40310A: main (out.c:185)
==28766== 
==28766== Conditional jump or move depends on uninitialised value(s)
==28766==    at 0x4C22D98: strlen (mc_replace_strmem.c:242)
==28766==    by 0x7356CB0: vfprintf (in /lib/libc-2.7.so)
==28766==    by 0x7357B5F: (within /lib/libc-2.7.so)
==28766==    by 0x7353435: vfprintf (in /lib/libc-2.7.so)
==28766==    by 0x52A8270: G_debug (debug.c:83)
==28766==    by 0x591A98F: db_select_value (select.c:230)
==28766==    by 0x402473: bin_to_asc (b2a.c:217)
==28766==    by 0x40310A: main (out.c:185)
==28766== 
==28766== Syscall param write(buf) points to uninitialised byte(s)
==28766==    at 0x73D09F0: write (in /lib/libc-2.7.so)
==28766==    by 0x737E909: _IO_file_write (in /lib/libc-2.7.so)
==28766==    by 0x737E569: (within /lib/libc-2.7.so)
==28766==    by 0x737E84D: _IO_file_xsputn (in /lib/libc-2.7.so)
==28766==    by 0x7357C09: (within /lib/libc-2.7.so)
==28766==    by 0x7353435: vfprintf (in /lib/libc-2.7.so)
==28766==    by 0x52A8270: G_debug (debug.c:83)
==28766==    by 0x591A98F: db_select_value (select.c:230)
==28766==    by 0x402473: bin_to_asc (b2a.c:217)
==28766==    by 0x40310A: main (out.c:185)
==28766==  Address 0x7feffcc6a is on thread 1's stack
==28766== 
==28766== Conditional jump or move depends on uninitialised value(s)
==28766==    at 0x507E6BF: db_enlarge_string (string.c:113)
==28766==    by 0x507E657: set_string (string.c:92)
==28766==    by 0x507E588: db_set_string (string.c:35)
==28766==    by 0x507E8AA: db_copy_string (string.c:214)
==28766==    by 0x507F546: db_copy_value (value.c:319)
==28766==    by 0x591A9BB: db_select_value (select.c:235)
==28766==    by 0x402473: bin_to_asc (b2a.c:217)
==28766==    by 0x40310A: main (out.c:185)
==28766== 
==28766== Use of uninitialised value of size 8
==28766==    at 0x4C22DFC: strcpy (mc_replace_strmem.c:268)
==28766==    by 0x507E678: set_string (string.c:95)
==28766==    by 0x507E588: db_set_string (string.c:35)
==28766==    by 0x507E8AA: db_copy_string (string.c:214)
==28766==    by 0x507F546: db_copy_value (value.c:319)
==28766==    by 0x591A9BB: db_select_value (select.c:235)
==28766==    by 0x402473: bin_to_asc (b2a.c:217)
==28766==    by 0x40310A: main (out.c:185)
==28766== 
==28766== Invalid write of size 1
==28766==    at 0x4C22DFC: strcpy (mc_replace_strmem.c:268)
==28766==    by 0x507E678: set_string (string.c:95)
==28766==    by 0x507E588: db_set_string (string.c:35)
==28766==    by 0x507E8AA: db_copy_string (string.c:214)
==28766==    by 0x507F546: db_copy_value (value.c:319)
==28766==    by 0x591A9BB: db_select_value (select.c:235)
==28766==    by 0x402473: bin_to_asc (b2a.c:217)
==28766==    by 0x40310A: main (out.c:185)
==28766==  Address 0x7ffffffff is not stack'd, malloc'd or (recently) free'd
==28766== 
==28766== Process terminating with default action of signal 11 (SIGSEGV)
==28766==  Access not within mapped region at address 0x7FFFFFFFF
==28766==    at 0x4C22DFC: strcpy (mc_replace_strmem.c:268)
==28766==    by 0x507E678: set_string (string.c:95)
==28766==    by 0x507E588: db_set_string (string.c:35)
==28766==    by 0x507E8AA: db_copy_string (string.c:214)
==28766==    by 0x507F546: db_copy_value (value.c:319)
==28766==    by 0x591A9BB: db_select_value (select.c:235)
==28766==    by 0x402473: bin_to_asc (b2a.c:217)
==28766==    by 0x40310A: main (out.c:185)
664070.15136424|5103723.69345589|1
==28766== 
==28766== ERROR SUMMARY: 8 errors from 6 contexts (suppressed: 20 from 2)
==28766== malloc/free: in use at exit: 23,975 bytes in 131 blocks.
==28766== malloc/free: 292 allocs, 161 frees, 47,116 bytes allocated.
==28766== For counts of detected errors, rerun with: -v
==28766== searching for pointers to 131 not-freed blocks.
==28766== checked 2,826,664 bytes.
==28766== 
==28766== LEAK SUMMARY:
==28766==    definitely lost: 369 bytes in 16 blocks.
==28766==      possibly lost: 58 bytes in 1 blocks.
==28766==    still reachable: 23,548 bytes in 114 blocks.
==28766==         suppressed: 0 bytes in 0 blocks.
==28766== Rerun with --leak-check=full to see details of leaked memory.
Segmentation fault

Hamish

comment:4 in reply to:  1 ; Changed 10 years ago by glynn

Replying to hamish:

it seems to die on this in db_select_value():

if (count == 0)
    db_copy_value(val, value);

I'm guessing that *val has not been allocated any memory?

Various dbString functions expect the target value to have been initialised, but "value" is uninitialised. It needs to be initialised with:

    dbValue value = {0};

Alternatively, the string part alone can be initialised later with:

    db_init_string(&value.s);

comment:5 in reply to:  4 ; Changed 10 years ago by neteler

Replying to glynn:

Various dbString functions expect the target value to have been initialised, but "value" is uninitialised. It needs to be initialised with:

...

    db_init_string(&value.s);

Is attached patch ok?

Markus

Changed 10 years ago by neteler

Attachment: v.out.ascii.diff added

initialize value

comment:6 in reply to:  5 Changed 10 years ago by glynn

Replying to neteler:

Various dbString functions expect the target value to have been initialised, but "value" is uninitialised. It needs to be initialised with:

Is attached patch ok?

I suggest using an initialiser; try r39121.

comment:7 Changed 10 years ago by neteler

Resolution: fixed
Status: newclosed

Thanks, seems to help. Backported. Closing.

Note: See TracTickets for help on using tickets.