Re: changed dlopen flags in dynlib.c, gccemacs crash

[Philipp Stephani]

Am Sa., 11. Dez. 2021 um 19:10 Uhr schrieb Andrea Corallo <akrl@sdf.org>:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: hx <silent2600@gmail.com>
> >> Date: Sat, 11 Dec 2021 10:29:33 +0800
> >> Cc: Andrea Corallo <akrl@sdf.org>, emacs-devel <emacs-devel@gnu.org>
> >>
> >> git diff
> >> diff --git a/src/comp.c b/src/comp.c
> >> index 43feac6..2941f84 100644
> >> --- a/src/comp.c
> >> +++ b/src/comp.c
> >> @@ -5191,6 +5191,8 @@ DEFUN ("comp--register-lambda", 
> >> Fcomp__register_lambda,
> >> Scomp__register_lambda,
> >>     Lisp_Object maxarg, Lisp_Object type, Lisp_Object rest,
> >>     Lisp_Object comp_u)
> >>  {
> >> +  CHECK_CONS(rest);
> >> +
> >>    Lisp_Object doc_idx = FIRST (rest);
> >>    Lisp_Object intspec = SECOND (rest);
> >>    struct Lisp_Native_Comp_Unit *cu = XNATIVE_COMP_UNIT (comp_u);
> >> diff --git a/src/dynlib.c b/src/dynlib.c
> >> index a8c8843..362530b 100644
> >> --- a/src/dynlib.c
> >> +++ b/src/dynlib.c
> >> @@ -270,7 +270,8 @@ dynlib_close (dynlib_handle_ptr h)
> >>  dynlib_handle_ptr
> >>  dynlib_open (const char *path)
> >>  {
> >> -  return dlopen (path, RTLD_LAZY);
> >> +  // return dlopen (path, RTLD_LAZY);
> >> +  return dlopen (path, RTLD_LAZY|RTLD_GLOBAL);
> >>  }
> >>
> >>
> >> delete the eln-cache, execute with -nw -q in gdb, wait a few seconds:
> >> (gdb) bt
> >> #0  _dl_lookup_symbol_x (undef_name=0x555555e3814300 <error: Cannot access 
> >> memory at address
> >> 0x555555e3814300>, undef_map=0x555556059380, ref=0x7fffffffc1b8, 
> >> symbol_scope=0x555556059718,
> >> version=0x0, type_class=0, flags=2, skip_map=0x0) at dl-lookup.c:842
> >> #1  0x00007ffff4082b74 in do_sym (handle=<optimized out>, 
> >> name=0x555555e3814300 <error: Cannot
> >> access memory at address 0x555555e3814300>, who=0x55555580b073 
> >> <dynlib_sym+35>,
> >> vers=vers@entry=0x0, flags=flags@entry=2) at dl-sym.c:165
> >> #2  0x00007ffff408305d in _dl_sym (handle=<optimized out>, name=<optimized 
> >> out>, who=<optimized out>)
> >> at dl-sym.c:274
> >> #3  0x00007ffff5bdf3b4 in dlsym_doit (a=a@entry=0x7fffffffc3f0) at 
> >> dlsym.c:50
> >> #4  0x00007ffff4083260 in __GI__dl_catch_exception 
> >> (exception=exception@entry=0x7fffffffc390,
> >> operate=0x7ffff5bdf3a0 <dlsym_doit>, args=0x7fffffffc3f0) at 
> >> dl-error-skeleton.c:208
> >> #5  0x00007ffff408331f in __GI__dl_catch_error (objname=0x555555dab830, 
> >> errstring=0x555555dab838,
> >> mallocedp=0x555555dab828, operate=<optimized out>, args=<optimized out>) 
> >> at dl-error-skeleton.c:227
> >> #6  0x00007ffff5bdfa65 in _dlerror_run 
> >> (operate=operate@entry=0x7ffff5bdf3a0 <dlsym_doit>,
> >> args=args@entry=0x7fffffffc3f0) at dlerror.c:170
> >> #7  0x00007ffff5bdf41c in __dlsym (handle=<optimized out>, name=<optimized 
> >> out>) at dlsym.c:70
> >> #8  0x000055555580b073 in dynlib_sym (h=0x555556059380, 
> >> sym=0x555555e3814300 <error: Cannot
> >> access memory at address 0x555555e3814300>) at dynlib.c:280
> >> #9  0x0000555555809f63 in make_subr (symbol_name=0x555555e38153, 
> >> minarg=0x16, maxarg=0x16,
> >> c_name=0x555555e38153, type=0xfc30, doc_idx=0xba, intspec=0x0, 
> >> comp_u=0x555555df6d1d) at
> >> comp.c:5147
> >> #10 0x000055555580a156 in Fcomp__register_lambda (reloc_idx=0xa, 
> >> c_name=0x555555e38153,
> >> minarg=0x16, maxarg=0x16, type=0xfc30, rest=0x555555e17c03, 
> >> comp_u=0x555555df6d1d) at comp.c:5203
> >> #11 0x00007fffef0eed34 in late_top_level_run () at
> >> /home/silent/.emacs.d/eln-cache/28.0.90-8dcada16/cconv-3b1f1f98-cca24f72.eln
> >
> > So I think this is a manifestation of the issue that Andrea was
> > talking about: the way we produce native code is incompatible with
> > RTLD_GLOBAL.
> >
> > So at this point, I think this bug report should be treated as
> > "wishlist", i.e. a feature request: to support RTLD_GLOBAL in dynlib
> > with native-comp.  Andrea, is that feasible, and if so, what would it
> > entail?
>
> Hi Eli,
>
> yes, I think once we have verified the issue is what we suspect we could
> dlopen eln files as before and have RTLD_GLOBAL added for the other
> cases.

This thread is already quite old, but let me point out that
https://www.akkadia.org/drepper/dsohowto.pdf warns very strongly
against using RTLD_GLOBAL (section 1.5.4), and I don't see a strong
reason to not heed that warning. So I'd recommend removing RTLD_GLOBAL
again.