Re: [oi-dev] mapfile and RESERVE_SEGMENT or CAPABILITY

[Richard Lowe]

It's been so long I honestly don't remember right now, but it or V look
right (ignoring the documentation, for now).  You should be able to check
it was created using elfdump -p

-- Rich

On Mon, Aug 9, 2021, 01:34 Carsten Grzemba via oi-dev <
oi-dev@openindiana.org> wrote:

>
>
> Am 08.08.21 23:46 schrieb *Richard Lowe * :
>
> We haven't added RESERVE_SEGMENT yet, though it would be fairly easy to do
> I think.
> You can do the same thing in the v1 syntax though, using the ?E flag to
> say it's empty.
>
> --
>
> I try to translate the mapfile version 2 to version 1
> version 2;
>
> RESERVE_SEGMENT spidermonkey_reserve {
> VADDR = 0x8000;
> SIZE = 0x7fff;
>  };
>
> Is the following correct in version = 1?
>
> spidermonkey_reserve = LOAD A0x8000 L0x7fff ?E;
>
> The documentation mentions virtual_address (V) is not usabel for userland
> bins but alligment (A) seems to have an other meaning here.
> I am wrong?
> --
> Carsten
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev
>
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] libmapmalloc and libumem

[Toomas Soome via oi-dev]

> On 8. Aug 2021, at 11:46, s...@pandora.be  wrote:
> 
> 
> When I compiled OpenSmalltalk on OpenIndiana, initially it seemed to work but 
> there were sometimes malloc() errors, pointing to some form of memory 
> corruption.
> 
> The names of the OpenSmalltalk packages are cog-spur and stack-spur.
> 
> Those are also the names that the principal developer of OpenSmalltalk (Eliot 
> Miranda) also uses.
> 
> Both cog-spur and stack-spur were sometimes working fine for a while, then 
> crashing either without error message or with some malloc error.
> 
> I ran cog-spur and stack-spur under valgrind, a tool to debug malloc, but 
> valgrind did not find a problem.
> 
> Fortunately I discovered a while ago that OpenIndiana has multiple malloc() 
> libraries.
> 
> Since I link against libmapmalloc, a malloc() implementation that only uses 
> mmap() and not brk() or sbrk() , the situation is much better.
> 
> The packages are now much more stable and I have not seen a malloc() error 
> any longer although that these are hard to reproduce problems.
> 
> Perhaps I should be using libumem instead of libmapmalloc.
> 
> Has anyone recommendations on perhaps preference for libumem on OI instead of 
> libmapmalloc ?
> 
> David Stes

libumem does provide more tools to diagnose memory management issues.

rgds,
toomas
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev