From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.bugs Subject: bug#34655: 26.1.92; Segfault in module with --module-assertions Date: Sun, 17 Mar 2019 23:52:55 +0000 Message-ID: <87va0h12js.fsf@tcd.ie> References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="159851"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 34655@debbugs.gnu.org, p.stephani2@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 18 00:54:17 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h5fbb-000fQ4-Jx for geb-bug-gnu-emacs@m.gmane.org; Mon, 18 Mar 2019 00:54:15 +0100 Original-Received: from localhost ([127.0.0.1]:33344 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5fbZ-000824-B6 for geb-bug-gnu-emacs@m.gmane.org; Sun, 17 Mar 2019 19:54:13 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60791) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5fbQ-00081x-BM for bug-gnu-emacs@gnu.org; Sun, 17 Mar 2019 19:54:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h5fbP-0003cY-7a for bug-gnu-emacs@gnu.org; Sun, 17 Mar 2019 19:54:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34317) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h5fbO-0003cR-Tj for bug-gnu-emacs@gnu.org; Sun, 17 Mar 2019 19:54:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h5fbO-0007jy-Hv for bug-gnu-emacs@gnu.org; Sun, 17 Mar 2019 19:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Basil L. Contovounesios" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Mar 2019 23:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34655 X-GNU-PR-Package: emacs Original-Received: via spool by 34655-submit@debbugs.gnu.org id=B34655.155286679129696 (code B ref 34655); Sun, 17 Mar 2019 23:54:02 +0000 Original-Received: (at 34655) by debbugs.gnu.org; 17 Mar 2019 23:53:11 +0000 Original-Received: from localhost ([127.0.0.1]:47861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5faY-0007it-KH for submit@debbugs.gnu.org; Sun, 17 Mar 2019 19:53:10 -0400 Original-Received: from mail-ed1-f51.google.com ([209.85.208.51]:34286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5faW-0007iZ-Ub for 34655@debbugs.gnu.org; Sun, 17 Mar 2019 19:53:09 -0400 Original-Received: by mail-ed1-f51.google.com with SMTP id a16so12009823edn.1 for <34655@debbugs.gnu.org>; Sun, 17 Mar 2019 16:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=0zpeSc4DC1PqQ45iyNnWxaaZR4XczT+tiAOIBtkVNCw=; b=But7g/dq2BTRzf3/s89I4/39EEFUldSPA40MrfNfKiaOm5r6PWaWuXv0kylF3MTt8M /G0iyEK3y++ZSDXUb7ZgIcice0jlWmJpkLmrTJOnzORQFcvpI1UqDo6KWvbiFGjtEq4Z ytPJT2gTe2qSD60m3dUCUIBEfcQOp9bj3zwGhzldP3LMY3U6OX2VHz2CFbuCInoUhEcp 12GqwgA5VoN2S8jpeOkaHZ3cH3GaI8X05PbSI9OdOXrxvA4rqO4A2G4aTfByZTEl5h3n ccLJLpMx3t1YerlQ1K31XK4SVBfKAbdw5xh5CTIxnkXP1uLGeEhv7PdzsW45rcyOIhRX MpOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=0zpeSc4DC1PqQ45iyNnWxaaZR4XczT+tiAOIBtkVNCw=; b=Ku8xgl9RV2KBLqX+28ykCW5/PKIc16z2HXkE5WOH2d9IPFwMsbRrcq1+TyBsvbF2l0 eQhs8C0pmIJb+uq9wgk1NNataUzBnNt2bf53ECZYYweGu58s7VF416Rsq2A8X5Q61RuJ S2Wvo5mmdjTj5WVVYs7FggSvx+5D1bgnpl0CvjNPoVjhxw0E6ngejsg8vWuUJoP92f51 yi9V3Q7t6cOLh2h6Ob8pAObFc4oaql8kEKoAC/2dUsudXD7N8PeLQhHaRdM9nt/cmXnb k5w/0kCT6dI41U/EF3FZ6yeDhFaj3kaFIuQ9ISWgrxyrKMb3Y09ZqXyZ8nwetOGS8k57 wHWg== X-Gm-Message-State: APjAAAVQ2/RQBwLRxZ+JqxH5oucfGb9dU5JzFXyvn92q/FbGtRQw55+q +S4T+dY2emf73EZEJDjHJkgQiw== X-Google-Smtp-Source: APXvYqx6PgVUoWUL12JemWgnHnvZJC83zOgsrCFbGeKHd/dBPk4cGNQcYZ+QqR1rZ1DrJZfIlreVnw== X-Received: by 2002:a17:906:1182:: with SMTP id n2mr9049666eja.35.1552866782987; Sun, 17 Mar 2019 16:53:02 -0700 (PDT) Original-Received: from localhost ([2a02:8084:20e2:c380:20c2:134e:4f3a:683a]) by smtp.gmail.com with ESMTPSA id i9sm2447915edl.65.2019.03.17.16.53.01 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sun, 17 Mar 2019 16:53:02 -0700 (PDT) In-Reply-To: <83lg1dwhse.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 17 Mar 2019 19:08:01 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:156442 Archived-At: Eli Zaretskii writes: >> From: "Basil L. Contovounesios" >> Cc: <34655@debbugs.gnu.org>, Philipp Stephani >> Date: Sun, 17 Mar 2019 16:38:58 +0000 >>=20 >> These reveal that value_to_lisp eventually returns a corrupted string, >> but I don't know why. > > Did you try to identify the code which causes the corruption, i.e. the > data is valid before that code runs, and invalid after that? If not, > can you try? The way to do that is by painstakingly stepping through > the code while examining the relevant data, possibly with help of > watchpoints and displays set up by the GDB "display" command. The patch adding assertions to emacs-module.c narrows the problematic code to lines 123--127 of the dynamic module[1]: if (rp_lisp_string (env, &file, nbuf) && rp_funcall (env, &dir, "directory-name-p", 1, &dir) && env->is_not_nil (env, dir)) /* Return directory name when given one =C3=A0 la Ffile_truename. = */ rp_funcall (env, &file, "file-name-as-directory", 1, &file); [1]: https://gitlab.com/basil-conto/realpath/blob/master/realpath.c#L123-127 On line 123, 'file' is set to an Emacs string created from the C string 'nbuf' ('rp_lisp_string' wraps 'module_make_string' along with a nonlocal exit check, and similarly 'rp_funcall' wraps 'module_funcall'). On line 127, 'file' is passed to 'file-name-as-directory'. The assertions added to 'module_make_string' and 'lisp_to_value' never fail, suggesting the string returned by them is fine (though the assertions in 'lisp_to_value' only target intermediate Lisp_Objects, not the returned emacs_value). The assertion added to 'value_to_lisp' via 'module_funcall', OTOH, does fail. I'll see if I can step through this, though I'm not yet sure how I'll distinguish the problematic call to the module function from the hundreds of unproblematic ones before it. There's probably a way to teach GDB how to inspect emacs_values which I'm not yet familiar with. >> I've seen comments in src/fileio.c referring to string-relocation >> during GC; could this be at play here? > > It could be, if your module code holds onto C pointers to Lisp string > data while Emacs runs parts of the interpreter which could GC. Does > that happen anywhere in your code or in the code involved in > module-assertions? I can't speak for emacs-module.c (I haven't yet understood how Vmodule_environments and its save pointers work), but the only exchange between C and Lisp strings in my code is via the module API, i.e. module_make_string and module_copy_string_contents. I would hope the API and its opaque emacs_value type make it difficult for such issues to arise. >> Either way, do you have any suggestions on how to proceed? > > See above. > > I tried at the time to reproduce your problem, and failed. But I did > that on Windows, where I needed to replace the non-existent realpath > by an equivalent function, so it's not a faithful reproduction. I > will see if I can find time to look at this on a GNU machine, unless > someone beats me to it. Replacing 'canonicalize_file_name' with 'strdup' still reproduces the issue for me. Perhaps increasing the number of calls to realpath-truename from 1000 to 5000 will also help. >> 8. bt full >> 9. f 2 >> 10. p p >> 11. pr [#] >> 12. xpr > > Why did you expect 'p' to be a valid Lisp object? It's actually a > pointer to a Lisp object, i.e. try > > (gdb) p *p > (gdb) xpr Oops, that was a thinko. The only difference is GDB reports XIL(...) instead of (Lisp_Object *), though. Thank you for your help, I'll report more as time allows. --=20 Basil