From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: changed dlopen flags in dynlib.c, gccemacs crash Date: Sun, 6 Mar 2022 15:32:14 +0100 Message-ID: References: <83tufjw848.fsf@gnu.org> <83lf0uuqaq.fsf@gnu.org> <83o85nr1mm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10979"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , hx , Emacs developers To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 06 15:33:24 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nQrwq-0002ed-Fa for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Mar 2022 15:33:24 +0100 Original-Received: from localhost ([::1]:50246 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nQrwp-0007bm-0L for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Mar 2022 09:33:23 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60612) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nQrvx-0006YW-K6 for emacs-devel@gnu.org; Sun, 06 Mar 2022 09:32:29 -0500 Original-Received: from [2607:f8b0:4864:20::c2f] (port=43562 helo=mail-oo1-xc2f.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nQrvv-0005ye-4n; Sun, 06 Mar 2022 09:32:28 -0500 Original-Received: by mail-oo1-xc2f.google.com with SMTP id 6-20020a4a0906000000b0031d7eb98d31so14881046ooa.10; Sun, 06 Mar 2022 06:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PQ/UIEiOB8nvN957rLjQjfZf/77N8Cx0+0H+rPb4z5s=; b=S1gvwYjIbEmE0zZQZigajY0s53tJIDSzJAKEqvC7QORcpDbbqpjoS80LE4i6AeDsD+ ReTcSv5qp+vhJkSOwRExNvowfs1kxAWhs3StoaBUt+ynSrZw2sI8hvxzIdLEVOp0pLxu ++QyufXt3KJSu4FZoBDgP6bXaLGHvj5DxG1ON1gmBzXz+dFZQs80yOqiHva2rRHpqYSb DD2gfhOKpD37uA0Ym9/r/+Fyq94viZP3x1zG5Kc3yCnGZnGkWEIeB7tVuGr4kR293O08 rfCZipj7v/feBaXttYw/JG5qAizkhlI3QZ0K+HUiKwueyYC6v5qTztySeWvSvqPeZrLI 1rxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PQ/UIEiOB8nvN957rLjQjfZf/77N8Cx0+0H+rPb4z5s=; b=TCzwq9Dt9Nhi9hjPph1RnKsiw5XtrVdSBWNHCh0TKxlx5ZTmDF3xtuc5D7m5Ki5RUE l+UUNJYaaUgZrPdbm83/KFmKMnQ1Ej8P6eFQwKYCAZICWyT47FhSEui8Dy9cIavgvLuP lM07xwHkYF+hAPeL2cRbSLzLmvDt9LlPekPEmpEtCUEbpTeDj03D9bs+EiezQ+DB2yrt dhxe3y0gnLTdMkYrwHkXQxFNssrUr/MBtEsAqvIwqJYW7VF2ZTbH44IP+69x0IPUsbbT CK4UgGkByqtRmGHfmd+yrMRrrXC/adghVDWq0FcYMVioEbQ6tK40C1xUdWPrGYdM4uRS G0+A== X-Gm-Message-State: AOAM533GzXxaFakxNTG15zl3qZJEcgAl4hIJhzhkyoAwzO3t5rlRIyZT yXRTVr58sL8LrRHVPHA7+ZRcDAAJY897FaSW07Q= X-Google-Smtp-Source: ABdhPJy4gRVNhi3OEM7Amrl3+2AckHFnMyyOHFXJz99Ixjf/+J7AWlQQFk1tGG6OxCPY+NfHL+pH5hNrZraX7hiQjMM= X-Received: by 2002:a05:6870:31c5:b0:d7:d5:5df with SMTP id x5-20020a05687031c500b000d700d505dfmr3387633oac.57.1646577145263; Sun, 06 Mar 2022 06:32:25 -0800 (PST) In-Reply-To: X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::c2f (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::c2f; envelope-from=p.stephani2@gmail.com; helo=mail-oo1-xc2f.google.com X-Spam_score_int: -3 X-Spam_score: -0.4 X-Spam_bar: / X-Spam_report: (-0.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, PDS_HP_HELO_NORDNS=0.659, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:286855 Archived-At: Am Sa., 11. Dez. 2021 um 19:10 Uhr schrieb Andrea Corallo : > > Eli Zaretskii writes: > > >> From: hx > >> Date: Sat, 11 Dec 2021 10:29:33 +0800 > >> Cc: Andrea Corallo , emacs-devel > >> > >> 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 >> 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=, name=0x555555e3814300 >> access memory at address 0x555555e3814300>, who=0x55555580b073 , > >> vers=vers@entry=0x0, flags=flags@entry=2) at dl-sym.c:165 > >> #2 0x00007ffff408305d in _dl_sym (handle=, name=, who=) > >> 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 , args=0x7fffffffc3f0) at dl-error-skeleton.c:208 > >> #5 0x00007ffff408331f in __GI__dl_catch_error (objname=0x555555dab830, errstring=0x555555dab838, > >> mallocedp=0x555555dab828, operate=, args=) at dl-error-skeleton.c:227 > >> #6 0x00007ffff5bdfa65 in _dlerror_run (operate=operate@entry=0x7ffff5bdf3a0 , > >> args=args@entry=0x7fffffffc3f0) at dlerror.c:170 > >> #7 0x00007ffff5bdf41c in __dlsym (handle=, name=) at dlsym.c:70 > >> #8 0x000055555580b073 in dynlib_sym (h=0x555556059380, sym=0x555555e3814300 >> 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.