On Sun, Feb 03, 2019 at 05:58:02PM -0900, Phil Rulon wrote:
> In order to make it work right the loader will have to keep track of each
> heap address in the DSO and determine if it is also referenced elsewhere.
> The only other option is to maintain separate heaps for each DSO and a
> global heap
On Sun, Jan 20, 2019 at 11:29:29AM +0100, Marc Balmer wrote:
>
>
> > Am 20.01.2019 um 11:14 schrieb Kamil Rytarowski :
> >
> > On 20.01.2019 11:03, Martin Husemann wrote:
> >> On Sun, Jan 20, 2019 at 10:32:43AM +0100, Kamil Rytarowski wrote:
> >>> I find it as workaround of our libc behavior.
>
> Am 20.01.2019 um 11:14 schrieb Kamil Rytarowski :
>
> On 20.01.2019 11:03, Martin Husemann wrote:
>> On Sun, Jan 20, 2019 at 10:32:43AM +0100, Kamil Rytarowski wrote:
>>> I find it as workaround of our libc behavior.
>>
>> I disagree, there is no clean way to implement the call-on-dlclose
>>
On 20.01.2019 11:03, Martin Husemann wrote:
> On Sun, Jan 20, 2019 at 10:32:43AM +0100, Kamil Rytarowski wrote:
>> I find it as workaround of our libc behavior.
>
> I disagree, there is no clean way to implement the call-on-dlclose
> semantics (i.e. it needs disgusting ld.elf_so hacks and layer vi
On Sun, Jan 20, 2019 at 10:32:43AM +0100, Kamil Rytarowski wrote:
> I find it as workaround of our libc behavior.
I disagree, there is no clean way to implement the call-on-dlclose
semantics (i.e. it needs disgusting ld.elf_so hacks and layer violations).
But maybe we should document the __cxa_at
On 20.01.2019 10:19, Marc Balmer wrote:
>
>
>> Am 20.01.2019 um 10:14 schrieb Martin Husemann :
>>
>> On Sun, Jan 20, 2019 at 10:06:33AM +0100, Marc Balmer wrote:
>>> Why are atexit handlers run after dlclosing loaded libraries? That sounds
>>> wrong to me, but is there a reason?
>>
>> They are
> Am 20.01.2019 um 10:14 schrieb Martin Husemann :
>
> On Sun, Jan 20, 2019 at 10:06:33AM +0100, Marc Balmer wrote:
>> Why are atexit handlers run after dlclosing loaded libraries? That sounds
>> wrong to me, but is there a reason?
>
> They are run at exit(1) time, the application (or in thi
On Sun, Jan 20, 2019 at 10:06:33AM +0100, Marc Balmer wrote:
> Why are atexit handlers run after dlclosing loaded libraries? That sounds
> wrong to me, but is there a reason?
They are run at exit(1) time, the application (or in this case library)
is responsible of removing them if it dlclose()s
> Am 04.01.2019 um 19:29 schrieb Valery Ushakov :
>
> On Wed, Dec 26, 2018 at 09:44:53 -0900, Phil Rulon wrote:
>
>> msd$ /usr/bin/lua -v test.lua
>> Lua 5.3.3 Copyright (C) 1994-2016 Lua.org, PUC-Rio
>> table
>> function
>> [1] Segmentation fault (core dumped) /usr/bin/lua -v test.lua
>>
In article <20190104182924.gd23...@pony.stderr.spb.ru>,
Valery Ushakov wrote:
>
>When atexit handlers are run when main returns the dlclose has already
>yanked the function that was registered to run. With explicit
>os.exit() the exit happens while the libs are still loaded, so it
>works ok.
I
On Wed, Dec 26, 2018 at 09:44:53 -0900, Phil Rulon wrote:
> msd$ /usr/bin/lua -v test.lua
> Lua 5.3.3 Copyright (C) 1994-2016 Lua.org, PUC-Rio
> table
> function
> [1] Segmentation fault (core dumped) /usr/bin/lua -v test.lua
>
> msd$ gdb -q /usr/bin/lua lua.core
> Reading symbols from /usr/bi
Over the last few days, an unusual issue has come to light. If a lua
module loads Xlib and makes calls into it lua is returning a boolean value
instead of a table. This is happening with lua 5.3.4 from pkgsrc. If the
core lua5.3.3 is used the module will load properly but segfault at program
exi
12 matches
Mail list logo
