From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: MPS: Win64 testers? Date: Thu, 22 Aug 2024 19:14:51 +0000 Message-ID: <877cc88j4p.fsf@protonmail.com> References: <87bk1k8mzd.fsf@protonmail.com> <861q2gs8xu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22201"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sebastian@sebasmonia.com, kien.n.quang@gmail.com, emacs-devel@gnu.org, yantar92@posteo.net To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 23 07:29:52 2024 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 1shMrv-0005e6-TU for ged-emacs-devel@m.gmane-mx.org; Fri, 23 Aug 2024 07:29:52 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1shMr7-00006V-0Y; Fri, 23 Aug 2024 01:29:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1shDGv-0007zP-4h for emacs-devel@gnu.org; Thu, 22 Aug 2024 15:15:01 -0400 Original-Received: from mail-40134.protonmail.ch ([185.70.40.134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1shDGs-0006zo-Qb for emacs-devel@gnu.org; Thu, 22 Aug 2024 15:15:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1724354095; x=1724613295; bh=lpvfm639F7KbEPMlMc3ScCOJUC2I8xu3WtPKj62GU84=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=xWtNP8Jdxqu2xnuWV/ndGQwIv2XhZqtWRpEGb4Lu2VdhwJYD3T2IqPnlSd5aJTB93 fF3ZQ9SVIVpAtfHMcRdCXw2bQ+e4R5Zl/QRhDbKujsDqd57GDbSdUdgoRRN5hPiWEm WF4+QVMfR5R2LumRN+Z3mXQaDmTHF4J/AA9Twf+W9fPXEaRwKKBdvOTK+TWUHfTnRn sIfc28Lb6cnWqLuQGJXhd0TBnfv8yM0ECzTTZvMJrIbevTveiETRWCZMsO5PiSW4tp GHWB96Glw8h7q5l2CInuRlSvoagjCjpmG2gYMQl2Uv+eZq3LnpmKMwTgRT3TSx9d6g XKGY7c3IVQCtw== In-Reply-To: <861q2gs8xu.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: dda84c1841b1b8fc2c6bbeb9e680f06fad3d1b7e Received-SPF: pass client-ip=185.70.40.134; envelope-from=pipcet@protonmail.com; helo=mail-40134.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_FROM=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 23 Aug 2024 01:28:46 -0400 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:323064 Archived-At: "Eli Zaretskii" writes: >> Date: Thu, 22 Aug 2024 17:51:38 +0000 >> From: Pip Cet >> Cc: Quang Kien Nguyen , Eli Zaretskii , emacs-devel@gnu.org, Ihor Radchenko >> >> > I was running this version today: >> > >> > https://github.com/kiennq/emacs-build/releases/tag/v31.305.20240819.47= 94ea5 >> > >> > Had two different crashes, hope that these backtraces are more useful >> > (thanks again to Pip and Ihor for their help) >> >> Thank you, that's very useful. Indeed, it looks like the >> Windows-specific code hands off a pointer to MPS-managed memory to >> GNUTLS to use as a cookie, while other OSes use an FD number cast to an >> intptr_t cast to void *. > I meant this code in gnutls.c: if (proc->gnutls_initstage < GNUTLS_STAGE_TRANSPORT_POINTERS_SET) { # ifdef WINDOWSNT /* On W32 we cannot transfer socket handles between different runtime =09 libraries, so we tell GnuTLS to use our special push/pull =09 functions. */ gnutls_transport_set_ptr2 (state, =09=09=09=09 (gnutls_transport_ptr_t) proc, =09=09=09=09 (gnutls_transport_ptr_t) proc); gnutls_transport_set_push_function (state, &emacs_gnutls_push); gnutls_transport_set_pull_function (state, &emacs_gnutls_pull); # else /* This is how GnuTLS takes sockets: as file descriptors passed =09 in. For an Emacs process socket, infd and outfd are the =09 same but we use this two-argument version for clarity. */ gnutls_transport_set_ptr2 (state, =09=09=09=09 (void *) (intptr_t) proc->infd, =09=09=09=09 (void *) (intptr_t) proc->outfd); if (proc->is_non_blocking_client) =09gnutls_transport_set_errno_function (state, =09=09=09=09=09 emacs_gnutls_nonblock_errno); # endif proc->gnutls_initstage =3D GNUTLS_STAGE_TRANSPORT_POINTERS_SET; } That hands a pointer to 'proc' to gnutls, and if 'proc' subsequently moves, emacs_gnutls_push or emacs_gnutls_pull will try to dereference a stale pointer. > You are talking about this line in emacs_gnutls_pull: > > emacs_gnutls_transport_set_errno (process->gnutls_state, > errno =3D=3D EWOULDBLOCK ? EAGAIN : e= rrno); > > which causes us to call GnuTLS thusly: > > gnutls_transport_set_errno (state, err); > > is that right? > Does this mean we will have to audit all our calls to > external libraries and make sure we never pass to them any part of any > Lisp object? That's a tough requirement; it's very easy to miss some > such use, which then triggers segfaults. Am I missing something? Synchronous calls do not need to be changed, only asynchronous callbacks that currently use a pointer to a Lisp object as their cookie. > Btw, I tried using EWW in my MinGW MPS build, and it didn't crash. Is > it possible to have a reproducible recipe for this? I'll try coming up with one, though that's probably just going to mean adding (igc-collect) after the gnutls handshake somewhere in the Lisp code. By the way, I fully agree more debugging information would be helpful. Pip