[GRASS-dev] G7.0.svn: g.remove segfault

[Sören Gebbert]

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 <wenzeslaus at gmail.com>:
>
>
> On Fri, Jun 26, 2015 at 6:09 AM, Maris Nartiss <maris.gis at gmail.com> 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 <wenzeslaus at gmail.com>:
>> >
>> >
>> > On Wed, Jun 24, 2015 at 9:29 AM, Vaclav Petras <wenzeslaus at gmail.com>
>> > wrote:
>> >>
>> >>
>> >>
>> >> On Wed, Jun 24, 2015 at 3:12 AM, Markus Neteler <neteler at osgeo.org>
>> >> wrote:
>> >>>
>> >>> On Wed, Jun 24, 2015 at 9:06 AM, Markus Neteler <neteler at osgeo.org>
>> >>> 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
>> > 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