<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 26, 2015 at 6:09 AM, Maris Nartiss <span dir="ltr"><<a href="mailto:maris.gis@gmail.com" target="_blank">maris.gis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I can not repeat the issue with current trunk on ~AMD64 Gentoo.<br>
Please provide locale information; run g.remove under valgrind to see<br>
the source of memory corruption.<br></blockquote><div><br></div><div>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.<br><br></div><div>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.<br></div><div><br></div><div>I'm not sure if Soeren can repeat it in more direct way.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Māris.<br>
<div class=""><div class="h5"><br>
<br>
2015-06-25 3:47 GMT+03:00 Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com">wenzeslaus@gmail.com</a>>:<br>
><br>
><br>
> On Wed, Jun 24, 2015 at 9:29 AM, Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com">wenzeslaus@gmail.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Wed, Jun 24, 2015 at 3:12 AM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> wrote:<br>
>>><br>
>>> On Wed, Jun 24, 2015 at 9:06 AM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>><br>
>>> wrote:<br>
>>> > Hi,<br>
>>> ><br>
>>> > to my surprise I managed to generate a segfault using g.remove:<br>
>>><br>
>>> please disregard. Apparently a system update triggered this (no idea<br>
>>> how).<br>
>>> "make distclean" helped.<br>
>><br>
>><br>
>> Well, you are not the only one with the problem:<br>
>><br>
>> <a href="https://lists.osgeo.org/pipermail/grass-dev/2015-May/075083.html" rel="noreferrer" target="_blank">https://lists.osgeo.org/pipermail/grass-dev/2015-May/075083.html</a><br>
>><br>
>> I will have to try distclean, although I think I tried it several times<br>
>> before.<br>
>><br>
><br>
> I'm getting the same issues again. Now I actually see a buffer overflow:<br>
><br>
> *** buffer overflow detected ***: g.remove terminated<br>
> ======= Backtrace: =========<br>
> /lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7fc697b2b38f]<br>
> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7fc697bc2c9c]<br>
> /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7fc697bc1b60]<br>
> /lib/x86_64-linux-gnu/libc.so.6(+0x109069)[0x7fc697bc1069]<br>
> /lib/x86_64-linux-gnu/libc.so.6(_IO_default_xsputn+0xbc)[0x7fc697b3370c]<br>
> /lib/x86_64-linux-gnu/libc.so.6(_IO_vfprintf+0x26b0)[0x7fc697b043a0]<br>
> /lib/x86_64-linux-gnu/libc.so.6(__vsprintf_chk+0x84)[0x7fc697bc10f4]<br>
> /lib/x86_64-linux-gnu/libc.so.6(__sprintf_chk+0x7d)[0x7fc697bc104d]<br>
> /home/vpetras/dev/grass/trunk/dist.x86_64-unknown-linux-gnu/lib/<a href="http://libgrass_manage.7.1.svn.so" rel="noreferrer" target="_blank">libgrass_manage.7.1.svn.so</a>(M_do_remove+0<br>
> x2e8)[0x7fc6982e9148]<br>
> g.remove(main+0x68d)[0x401c5d]<br>
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fc697ad9ec5]<br>
> g.remove[0x401e3e]<br>
> ======= Memory map: ========<br>
> 00400000-00403000 r-xp 00000000 08:11 16127189<br>
> /home/vpetras/dev/grass/trunk/d<br>
> ist.x86_64-unknown-linux-gnu/bin/g.remove<br>
> 00602000-00603000 r--p 00002000 08:11 16127189<br>
> /home/vpetras/dev/grass/trunk/d<br>
> ist.x86_64-unknown-linux-gnu/bin/g.remove<br>
> 00603000-00604000 rw-p 00003000 08:11 16127189<br>
> /home/vpetras/dev/grass/trunk/d<br>
> ist.x86_64-unknown-linux-gnu/bin/g.remove<br>
> ...<br>
><br>
> It fails with a lot of tests but with many other it works. I'm not sure if<br>
> all errors are stack overflow but I could catch all output the a fine next<br>
> time.<br>
><br>
> Vaclav<br>
><br>
><br>
</div></div><div class=""><div class="h5">> _______________________________________________<br>
> grass-dev mailing list<br>
> <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</div></div></blockquote></div><br></div></div>