GNU bug report logs -
#46256
[feature/native-comp] AOT eln files ignored if run from build tree
Previous Next
Full log
View this message in rfc822 format
On Mon, Mar 8, 2021 at 10:14 AM Andrea Corallo <akrl <at> sdf.org> wrote:
> Hi Pip,
>
> thanks for the analysis, I'm not sure I followed 100% so I'll repeat to
> make sure we are on the same page, please correct me in case.
Thanks for that!
> IIUC (and make sense to me) the issue is that we are leaving two pointer
> pointing to the same handle: One is in the CU_2 allocated by
> 'Fnative_elisp_load' and later discarded by 'load_comp_unit' when
> reloading the same filename. The other is the original CU_1 created the
> first time this filename was loaded.
>
> When CU_2 will be GC'ed because discarded we'll get the problem because
> we'll dlclose the handle. Is this correct?
CU_1 is GC'ed first. CU_2, for whatever reason, isn't GC'ed in the same cycle.
> In case isn't the attached curing the issue as well?
I don't think so. The problem is that we have an invalid Lisp_Object
in the shared library, not that we're calling dlclose() too often..
Again, there's no real cost to fixing this: at best, we avoid a
catastrophic use-after-free. At worst, we nulled out a word of memory
only for it to be unmapped a moment later, no harm done.
> PS I couldn't reproduce using the lisp reproducer both on my 64bit both
> on my 32bit system (I left it looping for a while), is that reproducer
> working for you?
Have you modified dynlib_open() to leak the shared object? That's what
I think might be happening for Eli, so it makes sense to test with a
double dlopen() call, as I did.
FWIW, I suspect the reproducer should crash with your patch applied,
but I can't test right now :-)
Thanks
Pip
This bug report was last modified 4 years and 130 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.