I had the same problem before. It is typical for bad string management, where uninitialized memory is written to or read from to just such an extent, that it works most of the time. When you run valgrind or gdb, the memory mapping of v.in.ascii will be slightly different and this might just allow it to get away with its dirty mem handling. In my case, running valgrind with options --leck-check=full succeeded to give me some additional hints about the culprit. Also, make sure to use the latest valgrind version. If that gets you nowhere, could you maybe attach your data (or part) of it to a Trac ticket, so we can make this bug "official" and others can get a chance to take a poke at it?
Ben Soeren Gebbert 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. > > Best regrads > Soeren > > 2009/9/9 Markus Neteler <[email protected] <mailto:[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 > <http://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 > <http://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 > <http://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 > <http://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 > <http://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 > <http://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 > <http://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 > <http://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] > <mailto:[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] > <mailto:[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] <mailto:[email protected]> > >> http://lists.osgeo.org/mailman/listinfo/grass-dev > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > grass-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Benjamin Ducke Senior Applications Support and Development Officer Oxford Archaeological Unit Limited Janus House Osney Mead OX2 0ES Oxford, U.K. Tel: +44 (0)1865 263 800 (switchboard) Tel: +44 (0)1865 980 758 (direct) Fax :+44 (0)1865 793 496 [email protected] ------ Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
