[GRASS-dev] Heisenbug in v.out.ascii with column parameter:
segfault
Benjamin Ducke
benjamin.ducke at oxfordarch.co.uk
Wed Sep 9 08:28:37 EDT 2009
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 <neteler at osgeo.org <mailto:neteler at 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
> <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<soerengebbert at googlemail.com
> <mailto:soerengebbert at 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 at osgeo.org
> <mailto:neteler at 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 at lists.osgeo.org <mailto:grass-dev at lists.osgeo.org>
> >> http://lists.osgeo.org/mailman/listinfo/grass-dev
> >
> >
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> 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
benjamin.ducke at oxfordarch.co.uk
------
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.
More information about the grass-dev
mailing list