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.