I just tried to build and run r.viewshed. When I build it, it seems to compile fine, but then latter in the make process, I saw this error go past:
MM error: limit =0B. allocating 16B. limit exceeded by 24B.
Assertion failed: (0), function operator new, file mm.cc, line 326.
However, after that, it does apparently complete the build and generate a binary. But, if I try to run the binary, I get exactly that error. Even just trying to get help:
r.viewshed -h
MM error: limit =0B. allocating 16B. limit exceeded by 24B.
Assertion failed: (0), function operator new, file mm.cc, line 326.
Abort trap
So, it seems that something is odd with build.
I am running on a Mac, using Kyngchaos binaries and modbuild. So, the make command I used is just:
make GRASS_HOME='/Users/dersh/Library/GRASS/6.4/modbuild' GRASS_APP='/Applications/GRASS-6.4.app'
Any thoughts or suggestions what might be going on with this?
I really am not sure if it is an issue with r.viewshed, GRASS, Mac version, mac building etc?
Thanks for any ideas.
--Adam
Adam Dershowitz, Ph.D., P.E. wrote:
I just tried to build and run r.viewshed. When I build it, it seems to
compile fine, but then latter in the make process, I saw this error go
past:
MM error: limit =0B. allocating 16B. limit exceeded by 24B.
Assertion failed: (0), function operator new, file mm.cc, line 326.
Any thoughts or suggestions what might be going on with this?
Something is trying to allocate memory before the memory manager
object has been initialised.
The order in which static objects are constructed is undefined. So if
a static object dynamically allocates memory in its constructor, it's
a matter of luck whether the memory manager object has been
constructed at that point.
Fortunately, the MM_register class doesn't actually need construction.
Unfortunately, the limit-checking mode is statically initialised to
"abort", then changed to "ignore" in the constructor.
This has (hopefully) been fixed in 7.0 with r38702, but the problem
remains in 6.x.
The fix involves changing line 443 of lib/iostream/mm.cc from:
MM_mode MM_register::register_new = MM_ABORT_ON_MEMORY_EXCEEDED;
to:
MM_mode MM_register::register_new = MM_IGNORE_MEMORY_EXCEEDED;
--
Glynn Clements <glynn@gclements.plus.com>
On Oct 10, 2011, at 12:51 AM, Glynn Clements wrote:
Adam Dershowitz, Ph.D., P.E. wrote:
I just tried to build and run r.viewshed. When I build it, it seems to
compile fine, but then latter in the make process, I saw this error go
past:
MM error: limit =0B. allocating 16B. limit exceeded by 24B.
Assertion failed: (0), function operator new, file mm.cc, line 326.
Any thoughts or suggestions what might be going on with this?
Something is trying to allocate memory before the memory manager
object has been initialised.
The order in which static objects are constructed is undefined. So if
a static object dynamically allocates memory in its constructor, it's
a matter of luck whether the memory manager object has been
constructed at that point.
Fortunately, the MM_register class doesn't actually need construction.
Unfortunately, the limit-checking mode is statically initialised to
"abort", then changed to "ignore" in the constructor.
This has (hopefully) been fixed in 7.0 with r38702, but the problem
remains in 6.x.
The fix involves changing line 443 of lib/iostream/mm.cc from:
MM_mode MM_register::register_new = MM_ABORT_ON_MEMORY_EXCEEDED;
to:
MM_mode MM_register::register_new = MM_IGNORE_MEMORY_EXCEEDED;
--
Thanks.
I assume that means 1) the only way to fix this is to recompile the grass iostream static library? (I have been using the binary of grass). 2) Will the same change work in 6.x? Or would the change potentially introduce other problems or be more complicated?
--Adam
Adam Dershowitz, Ph.D., P.E. wrote:
> This has (hopefully) been fixed in 7.0 with r38702, but the problem
> remains in 6.x.
>
> The fix involves changing line 443 of lib/iostream/mm.cc from:
>
> MM_mode MM_register::register_new = MM_ABORT_ON_MEMORY_EXCEEDED;
> to:
> MM_mode MM_register::register_new = MM_IGNORE_MEMORY_EXCEEDED;
I assume that means 1) the only way to fix this is to recompile the
grass iostream static library? (I have been using the binary of grass).
Yes. Or wait until someone back-ports the fix. Filing a bug report on
the tracker may help.
2) Will the same change work in 6.x? Or would the change potentially
introduce other problems or be more complicated?
The fix should work in 6.x. At the very least, it won't break
anything.
--
Glynn Clements <glynn@gclements.plus.com>
On Mon, Oct 10, 2011 at 5:38 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Adam Dershowitz, Ph.D., P.E. wrote:
> This has (hopefully) been fixed in 7.0 with r38702, but the problem
> remains in 6.x.
>
> The fix involves changing line 443 of lib/iostream/mm.cc from:
>
> MM_mode MM_register::register_new = MM_ABORT_ON_MEMORY_EXCEEDED;
> to:
> MM_mode MM_register::register_new = MM_IGNORE_MEMORY_EXCEEDED;
I assume that means 1) the only way to fix this is to recompile the
grass iostream static library? (I have been using the binary of grass).
Yes. Or wait until someone back-ports the fix. Filing a bug report on
the tracker may help.
Done in r48704,5. This line 443 is (was) a bit mysterious because the
default has been and still is MM_IGNORE_MEMORY_EXCEEDED, set in
unchanged line 47.
Markus M
Markus Metz wrote:
>> > This has (hopefully) been fixed in 7.0 with r38702, but the problem
>> > remains in 6.x.
>> >
>> > The fix involves changing line 443 of lib/iostream/mm.cc from:
>> >
>> > MM_mode MM_register::register_new = MM_ABORT_ON_MEMORY_EXCEEDED;
>> > to:
>> > MM_mode MM_register::register_new = MM_IGNORE_MEMORY_EXCEEDED;
>>
>> I assume that means 1) the only way to fix this is to recompile the
>> grass iostream static library? (I have been using the binary of grass).
>
> Yes. Or wait until someone back-ports the fix. Filing a bug report on
> the tracker may help.
Done in r48704,5. This line 443 is (was) a bit mysterious because the
default has been and still is MM_IGNORE_MEMORY_EXCEEDED, set in
unchanged line 47.
Right. MM_register::register_new is statically initialised at line 443
then modified at line 47 the first (and only) time that the
constructor is invoked (for the instance created at line 440).
The problem is that it's undefined as to when the constructor is
invoked relative to constructors for other statically-allocated
objects.
--
Glynn Clements <glynn@gclements.plus.com>