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 <[email protected]> > 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... :( I guess an extra trick is needed to include > DBMI checking. > > Markus > > On Wed, Sep 9, 2009 at 12:14 PM, Soeren > Gebbert<[email protected]> wrote: > > Hello, > > try valgrind: > > > > valgrind --tool=memcheck v.out.ascii phd_area_main_cities column=name > > > > Sören > > > > 2009/9/9 Markus Neteler <[email protected]> > >> > >> 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 > >> [email protected] > >> http://lists.osgeo.org/mailman/listinfo/grass-dev > > > > >
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
