<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 26, 2015 at 2:37 PM, Sören Gebbert <span dir="ltr"><<a href="mailto:soerengebbert@googlemail.com" target="_blank">soerengebbert@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
may i suggest a patch to solve this issue?<br></blockquote><div><br></div><div>Sure!<br><br></div><div>I'm not sure if I can judge the path. However, sprintf is used a lot in GRASS, so I'm not sure if we can just replace it with other function without understanding what is the issue (at least I don't understand).<br><br></div><div>As for the magic number there, there is G_PATH_MAX or something, perhaps that would be more appropriate.<br></div><div><br></div><div>If the issue is length of the path, then I understand why it was happening for the tests - they use long Mapset names and possibly also map long map names.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<a href="http://pastebin.com/D8yautBh" rel="noreferrer" target="_blank">http://pastebin.com/D8yautBh</a><br>
<br>
Best regards<br>
Soeren<br>
<div class="HOEnZb"><div class="h5"><br>
2015-06-26 20:27 GMT+02:00 Sören Gebbert <<a href="mailto:soerengebbert@googlemail.com">soerengebbert@googlemail.com</a>>:<br>
> Hi,<br>
> here a traceback of a g.remove segfault that happens while testing<br>
> temporal modules:<br>
> <a href="http://pastebin.com/LDVKgEed" rel="noreferrer" target="_blank">http://pastebin.com/LDVKgEed</a><br>
><br>
> Seems to be in M_do_remove calling some sort of sprintf?? Maybe line<br>
> 102, since the colr2 buffer is only 50 chars in length ... however,<br>
> sprintf() function shouldn't be used at all.<br>
><br>
> Best regards<br>
> Soeren<br>
><br>
> 2015-06-26 16:11 GMT+02:00 Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com">wenzeslaus@gmail.com</a>>:<br>
>><br>
>><br>
>> On Fri, Jun 26, 2015 at 6:09 AM, Maris Nartiss <<a href="mailto:maris.gis@gmail.com">maris.gis@gmail.com</a>> wrote:<br>
>>><br>
>>> 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>
>><br>
>><br>
>> That's the hard part. I cannot run valgrind easily. I'm not getting the<br>
>> error when I execute it manually (at least not often enough). It is<br>
>> happening only with some part of tests for me. As I've written before, I<br>
>> originally haven't reported it at all because I'm getting with one copy of<br>
>> GRASS but not with the other on the same machine without being able to find<br>
>> any difference in between them. (Fortunately the copy which works is the one<br>
>> running the automated tests.) Only after Soeren and now Markus reported the<br>
>> same, I started to lean towards opinion that it is not a local issue.<br>
>><br>
>> As for valgrind, that's unfortunately a feature request for gunittest. Which<br>
>> is even more advanced then I expected because valgrind is not need for the<br>
>> tested module but just for a helper one, anyway, the testing framework<br>
>> should allow that.<br>
>><br>
>> I'm not sure if Soeren can repeat it in more direct way.<br>
>><br>
>>><br>
>>><br>
>>> Māris.<br>
>>><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>><br>
>>> > 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>><br>
>>> >> 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>
>>> ><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<br>
>>> > if<br>
>>> > all errors are stack overflow but I could catch all output the a fine<br>
>>> > next<br>
>>> > time.<br>
>>> ><br>
>>> > Vaclav<br>
>>> ><br>
>>> ><br>
>>> > _______________________________________________<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>
>><br>
>><br>
>><br>
>> _______________________________________________<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>