(gdb) bt #0 0x00007ffff70e35e9 in raise () from /lib64/libc.so.6 #1 0x00007ffff70e4cf8 in abort () from /lib64/libc.so.6 #2 0x00007ffff7123dd7 in __libc_message () from /lib64/libc.so.6 #3 0x00007ffff71bba07 in __fortify_fail () from /lib64/libc.so.6 #4 0x00007ffff71b9bd0 in __chk_fail () from /lib64/libc.so.6 #5 0x00007ffff71b90f9 in _IO_str_chk_overflow () from /lib64/libc.so.6 #6 0x00007ffff71274bc in __GI__IO_default_xsputn () from /lib64/libc.so.6 #7 0x00007ffff70f8f49 in vfprintf () from /lib64/libc.so.6 #8 0x00007ffff71b9188 in __vsprintf_chk () from /lib64/libc.so.6 #9 0x00007ffff71b90dd in __sprintf_chk () from /lib64/libc.so.6 #10 0x00007ffff7bd8cfb in sprintf (__fmt=0x7ffff7bd95e6 "colr2/%s",
__s=0x7fffffffc360
"colr2/modis_lst_reconstructed_europe_cooling_warmj\275\367\377\177")
at /usr/include/bits/stdio2.h:33 #11 M_do_remove (n=n@entry=0, old=0x655f00
"modis_lst1km2005.spring_warming") at do_remove.c:102 #12 0x00000000004022be in main (argc=<optimized out>, argv=<optimized
out>) at main.c:250
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.
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.
Māris.
2015-06-25 3:47 GMT+03:00 Vaclav Petras <wenzeslaus@gmail.com>:
On Wed, Jun 24, 2015 at 9:29 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Wed, Jun 24, 2015 at 3:12 AM, Markus Neteler <neteler@osgeo.org> wrote:
On Wed, Jun 24, 2015 at 9:06 AM, Markus Neteler <neteler@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.
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.
On Fri, Jun 26, 2015 at 6:09 AM, Maris Nartiss <maris.gis@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@gmail.com>:
>
>
> On Wed, Jun 24, 2015 at 9:29 AM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:
>>
>>
>>
>> On Wed, Jun 24, 2015 at 3:12 AM, Markus Neteler <neteler@osgeo.org>
wrote:
>>>
>>> On Wed, Jun 24, 2015 at 9:06 AM, Markus Neteler <neteler@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@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
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@gmail.com>:
On Fri, Jun 26, 2015 at 6:09 AM, Maris Nartiss <maris.gis@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@gmail.com>:
>
>
> On Wed, Jun 24, 2015 at 9:29 AM, Vaclav Petras <wenzeslaus@gmail.com>
> wrote:
>>
>>
>>
>> On Wed, Jun 24, 2015 at 3:12 AM, Markus Neteler <neteler@osgeo.org>
>> wrote:
>>>
>>> On Wed, Jun 24, 2015 at 9:06 AM, Markus Neteler <neteler@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@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
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@gmail.com>:
On Fri, Jun 26, 2015 at 6:09 AM, Maris Nartiss <maris.gis@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@gmail.com>:
>
>
> On Wed, Jun 24, 2015 at 9:29 AM, Vaclav Petras <wenzeslaus@gmail.com>
> wrote:
>>
>>
>>
>> On Wed, Jun 24, 2015 at 3:12 AM, Markus Neteler <neteler@osgeo.org>
>> wrote:
>>>
>>> On Wed, Jun 24, 2015 at 9:06 AM, Markus Neteler <neteler@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@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
On Fri, Jun 26, 2015 at 2:37 PM, Sören Gebbert <soerengebbert@googlemail.com
wrote:
Hi,
may i suggest a patch to solve this issue?
Sure!
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).
As for the magic number there, there is G_PATH_MAX or something, perhaps
that would be more appropriate.
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.
2015-06-26 20:27 GMT+02:00 Sören Gebbert <soerengebbert@googlemail.com>:
> 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@gmail.com>:
>>
>>
>> On Fri, Jun 26, 2015 at 6:09 AM, Maris Nartiss <maris.gis@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@gmail.com>:
>>> >
>>> >
>>> > On Wed, Jun 24, 2015 at 9:29 AM, Vaclav Petras <wenzeslaus@gmail.com
>
>>> > wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Wed, Jun 24, 2015 at 3:12 AM, Markus Neteler <neteler@osgeo.org>
>>> >> wrote:
>>> >>>
>>> >>> On Wed, Jun 24, 2015 at 9:06 AM, Markus Neteler <neteler@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@lists.osgeo.org
>>> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>>
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
2015-06-26 21:03 GMT+02:00 Vaclav Petras <wenzeslaus@gmail.com>:
On Fri, Jun 26, 2015 at 2:37 PM, Sören Gebbert
<soerengebbert@googlemail.com> wrote:
Hi,
may i suggest a patch to solve this issue?
Sure!
Ok, i will commit the patch.
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).
All sprintf calls in GRASS should be replaced by G_snprintf() because
sprintf is by design unsafe and the result of many buffer overflows
and eventually exploits. sprintf does not check the size of the target
buffer but G_snprintf does (if used correctly).
As for the magic number there, there is G_PATH_MAX or something, perhaps
that would be more appropriate.
Yes, it would.
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.
The length is one issue, but sprintf causes the segfault by writing
more than 50 chars if G_mapset() returns long mapset names as in case
of the temporary generated test mapsets.
2015-06-26 20:27 GMT+02:00 Sören Gebbert <soerengebbert@googlemail.com>:
> 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@gmail.com>:
>>
>>
>> On Fri, Jun 26, 2015 at 6:09 AM, Maris Nartiss <maris.gis@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@gmail.com>:
>>> >
>>> >
>>> > On Wed, Jun 24, 2015 at 9:29 AM, Vaclav Petras
>>> > <wenzeslaus@gmail.com>
>>> > wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Wed, Jun 24, 2015 at 3:12 AM, Markus Neteler <neteler@osgeo.org>
>>> >> wrote:
>>> >>>
>>> >>> On Wed, Jun 24, 2015 at 9:06 AM, Markus Neteler
>>> >>> <neteler@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@lists.osgeo.org
>>> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>>
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
On Fri, Jun 26, 2015 at 3:54 PM, Sören Gebbert <soerengebbert@googlemail.com
wrote:
>> may i suggest a patch to solve this issue?
>
>
> Sure!
Ok, i will commit the patch.
>
> 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).
All sprintf calls in GRASS should be replaced by G_snprintf() because
sprintf is by design unsafe and the result of many buffer overflows
and eventually exploits. sprintf does not check the size of the target
buffer but G_snprintf does (if used correctly).
> As for the magic number there, there is G_PATH_MAX or something, perhaps
> that would be more appropriate.
Yes, it would.
When I said "G_PATH_MAX or something" I meant that you should check me not
commit without even compiling the code Fixed in r65525 after
compilation and tests*.
Fixed in r65525 after