Hi, here a traceback of a g.remove segfault that happens while testing temporal modules: http://pastebin.com/LDVKgEed
Seems to be in M_do_remove calling some sort of sprintf?? Maybe line 102, since the colr2 buffer is only 50 chars in length ... however, sprintf() function shouldn't be used at all. Best regards Soeren 2015-06-26 16:11 GMT+02:00 Vaclav Petras <[email protected]>: > > > On Fri, Jun 26, 2015 at 6:09 AM, Maris Nartiss <[email protected]> wrote: >> >> I can not repeat the issue with current trunk on ~AMD64 Gentoo. >> Please provide locale information; run g.remove under valgrind to see >> the source of memory corruption. > > > That's the hard part. I cannot run valgrind easily. I'm not getting the > error when I execute it manually (at least not often enough). It is > happening only with some part of tests for me. As I've written before, I > originally haven't reported it at all because I'm getting with one copy of > GRASS but not with the other on the same machine without being able to find > any difference in between them. (Fortunately the copy which works is the one > running the automated tests.) Only after Soeren and now Markus reported the > same, I started to lean towards opinion that it is not a local issue. > > As for valgrind, that's unfortunately a feature request for gunittest. Which > is even more advanced then I expected because valgrind is not need for the > tested module but just for a helper one, anyway, the testing framework > should allow that. > > I'm not sure if Soeren can repeat it in more direct way. > >> >> >> Māris. >> >> >> 2015-06-25 3:47 GMT+03:00 Vaclav Petras <[email protected]>: >> > >> > >> > On Wed, Jun 24, 2015 at 9:29 AM, Vaclav Petras <[email protected]> >> > wrote: >> >> >> >> >> >> >> >> On Wed, Jun 24, 2015 at 3:12 AM, Markus Neteler <[email protected]> >> >> wrote: >> >>> >> >>> On Wed, Jun 24, 2015 at 9:06 AM, Markus Neteler <[email protected]> >> >>> wrote: >> >>> > Hi, >> >>> > >> >>> > to my surprise I managed to generate a segfault using g.remove: >> >>> >> >>> please disregard. Apparently a system update triggered this (no idea >> >>> how). >> >>> "make distclean" helped. >> >> >> >> >> >> Well, you are not the only one with the problem: >> >> >> >> https://lists.osgeo.org/pipermail/grass-dev/2015-May/075083.html >> >> >> >> I will have to try distclean, although I think I tried it several times >> >> before. >> >> >> > >> > I'm getting the same issues again. Now I actually see a buffer overflow: >> > >> > *** buffer overflow detected ***: g.remove terminated >> > ======= Backtrace: ========= >> > /lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7fc697b2b38f] >> > /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7fc697bc2c9c] >> > /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7fc697bc1b60] >> > /lib/x86_64-linux-gnu/libc.so.6(+0x109069)[0x7fc697bc1069] >> > /lib/x86_64-linux-gnu/libc.so.6(_IO_default_xsputn+0xbc)[0x7fc697b3370c] >> > /lib/x86_64-linux-gnu/libc.so.6(_IO_vfprintf+0x26b0)[0x7fc697b043a0] >> > /lib/x86_64-linux-gnu/libc.so.6(__vsprintf_chk+0x84)[0x7fc697bc10f4] >> > /lib/x86_64-linux-gnu/libc.so.6(__sprintf_chk+0x7d)[0x7fc697bc104d] >> > >> > /home/vpetras/dev/grass/trunk/dist.x86_64-unknown-linux-gnu/lib/libgrass_manage.7.1.svn.so(M_do_remove+0 >> > x2e8)[0x7fc6982e9148] >> > g.remove(main+0x68d)[0x401c5d] >> > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fc697ad9ec5] >> > g.remove[0x401e3e] >> > ======= Memory map: ======== >> > 00400000-00403000 r-xp 00000000 08:11 16127189 >> > /home/vpetras/dev/grass/trunk/d >> > ist.x86_64-unknown-linux-gnu/bin/g.remove >> > 00602000-00603000 r--p 00002000 08:11 16127189 >> > /home/vpetras/dev/grass/trunk/d >> > ist.x86_64-unknown-linux-gnu/bin/g.remove >> > 00603000-00604000 rw-p 00003000 08:11 16127189 >> > /home/vpetras/dev/grass/trunk/d >> > ist.x86_64-unknown-linux-gnu/bin/g.remove >> > ... >> > >> > It fails with a lot of tests but with many other it works. I'm not sure >> > if >> > all errors are stack overflow but I could catch all output the a fine >> > next >> > time. >> > >> > Vaclav >> > >> > >> > _______________________________________________ >> > 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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
