On Sun, Dec 27, 2020 at 01:46:46PM +0100, Peter Kovacs wrote:
> On 26.12.20 20:45, Jim Jagielski wrote:
> > So there is for sure a bug in AOO41X, but why it only seems to affect macOS
> > BigSur is
> > unknown. It is this:
> >
> > > diff --git a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> > > b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> > > index f4d6c56..2ca9b8f 100644
> > > --- a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> > > +++ b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> > > @@ -195,7 +195,7 @@ VtableFactory::VtableFactory(): m_arena(
> > > rtl_arena_create(
> > > "bridges::cpp_uno::shared::VtableFactory",
> > > sizeof (void *), // to satisfy alignment requirements
> > > - 0, reinterpret_cast< rtl_arena_type * >(-1), allocExec,
> > > freeExec, 0))
> > > + 0, reinterpret_cast< rtl_arena_type * >(0), allocExec, freeExec,
> > > 0))
> > > {
> > > if (m_arena == 0) {
> > > throw std::bad_alloc();
> > I *think* this solves the issue, and a quick-and-dirty compilation seems to
> > indicate that, but
> > I will double check.
> >
> > The question is: Does this warrant a full 4.1.9 release for ALL platforms?
> > To my mind, it does.
My question is also: How has it possibly worked until today? :-)
> yes we should go for 4.1.9 because there is no other way to fix this
> quickly.
I also agree.
> Any one has any Idea what the rtl_arena_create
> <http://opengrok.openoffice.org/openoffice/s?refs=rtl_arena_create&project=trunk>does?
> It looks to me like some C-Style factory, but I have a hard time
> understanding the code.
>
> And so far I did not find an explanation for it.
I tried to look into it. I am not an expert of this low-level stuff,
but ``arena'''s seem to be an alternative to calling plain malloc(3)
and free(3). They support a minimum size ("quantum") and some sort of
caching, that I could not fully understand.
They are somewhat chained among each other (each arena has a
``source''), with the ``public'' base object being gp_default_arena [1]
and two ``private'' objects being gp_arena_arena and gp_machdep_arena
inside /trunk/main/sal/rtl/source/alloc_arena.c
gp_machdep_arena is the ``source'' for the others, and it is
responsible of the actual allocation using function
rtl_machdep_alloc() [2]. Under Unix it cals mmap(2). Under Win32 it
calls VirtualAlloc() and under OS/2 it calls valloc().
Incidentally, the choice of mmap(2) over malloc(3) should be for
performance reasons, see [3]. It's a new thing I learned today ;-)
File main/bridges/source/cpp_uno/shared/vtablefactory.cxx declares its
own allocation function [4] that enables execution from the allocated
buffers (if I understood correctly).
I hope this makes sense.
References:
1:
http://opengrok.openoffice.org/xref/trunk/main/sal/rtl/source/alloc_arena.h?r=514f4c20#126
2:
http://opengrok.openoffice.org/xref/trunk/main/sal/rtl/source/alloc_arena.c?r=509a48ff#1182
3: https://stackoverflow.com/questions/1739296/malloc-vs-mmap-in-c
4:
http://opengrok.openoffice.org/xref/trunk/main/bridges/source/cpp_uno/shared/vtablefactory.cxx?r=858958ab#77
--
Arrigo
http://rigo.altervista.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
