From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MPS make-thread Date: Sat, 22 Jun 2024 09:29:33 +0300 Message-ID: <86iky1jxrm.fsf@gnu.org> References: <87v823xvq1.fsf@localhost> <8634p6n7jd.fsf@gnu.org> <87tthm3gq2.fsf@gmail.com> <87sex6ags5.fsf@localhost> <87msne3flr.fsf@gmail.com> <87frt63dvt.fsf@gmail.com> <86o77ulgk8.fsf@gnu.org> <87zfre1p3r.fsf@gmail.com> <87zfreo5u6.fsf@localhost> <87plsa1n8k.fsf@gmail.com> <87wmmio3vq.fsf@localhost> <87jzii1hbs.fsf_-_@gmail.com> <8734p61evv.fsf@gmail.com> <87cyoa3w5d.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16873"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, eller.helmut@gmail.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 22 08:30:26 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 1sKuGX-00049B-EW for ged-emacs-devel@m.gmane-mx.org; Sat, 22 Jun 2024 08:30:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sKuFo-0000CR-IK; Sat, 22 Jun 2024 02:29:40 -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 1sKuFm-0000C7-H1 for emacs-devel@gnu.org; Sat, 22 Jun 2024 02:29:38 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sKuFl-0008TC-L5; Sat, 22 Jun 2024 02:29:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=t41MPDO5fxcarXEg2zXsee6kWs+W3hI+E9Fe5RnBb3A=; b=YqAa2wlVwmQ/oPrTeXzm 0VMPEZQ7HRd4B71jThJkkMILlrNfxC64I92wW+HjXoA86+l+v/Y3KrCa9NwVs1PsBxtbV5foUgxRK XT1oAtRfOWU52pSYCTLiR5BQUeDFnPSsdNRd/mHi00VVtcwbmvKtOpWBqb5Mx2gHKybHnBGzeCm6F 8HZosD/GSgn0cvaLFCzj74RmQY7B1HTPD+m5zBxt+JPwMzEpM/iHNjlCyAqVdnGdA+ittm0Pl1E40 EwqFXuSV8cFEIsyMlyFjr0d01PyEO9zrvsGScYYwHZLPrHJWfVTjguNQrxwZeHkYaFU02T4k6OPbA s8sKiCU3RlWCfw==; In-Reply-To: <87cyoa3w5d.fsf@localhost> (message from Ihor Radchenko on Fri, 21 Jun 2024 19:58:54 +0000) 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:320455 Archived-At: > From: Ihor Radchenko > Cc: Helmut Eller , Eli Zaretskii , > emacs-devel@gnu.org > Date: Fri, 21 Jun 2024 19:58:54 +0000 > > Gerd Möllmann writes: > > > Pushed, please check. > > Now, there is no crash when I run my code that creates threads, but > there is a crash soon after :( What did you run to get this? AFAIU, the recipe used batch mode, in which case there's no "soon after", because Emacs exits. I see in the backtrace Fdelete_process, so what process was that and how was it run? Running xbacktrace after "bt" should produce useful info by showing us the Lisp backtrace, so always try to do that (unless you know that "xbacktrace" crashes in the particular situation). And I think there's another problem here: > Thread 1 "emacs" received signal SIGABRT, Aborted. > 0x00007ffff58ae9fb in pthread_kill () from /lib64/libc.so.6 > (gdb) bt > #0 0x00007ffff58ae9fb in pthread_kill () at /lib64/libc.so.6 > #1 0x00007ffff58553d2 in raise () at /lib64/libc.so.6 > #2 0x00005555556bba66 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:481 > #3 0x00005555557b2ec9 in igc_assert_fail (file=, line=, msg=) at igc.c:158 > #4 0x000055555582fe29 in mps_lib_assert_fail (condition=0x55555588ff52 "res == 0", line=126, file=0x55555588ff3c "lockix.c") > at /home/yantar92/Dist/mps/code/mpsliban.c:87 > #5 LockClaim (lock=0x7fffe8000110) at /home/yantar92/Dist/mps/code/lockix.c:126 > #6 0x000055555583005d in ArenaEnterLock (arena=0x7ffff7fc2000, recursive=0) at /home/yantar92/Dist/mps/code/global.c:576 > #7 0x000055555585e09c in ArenaEnter (arena=0x7ffff7fc2000) at /home/yantar92/Dist/mps/code/global.c:553 > #8 mps_ap_fill (p_o=p_o@entry=0x7fffffffa490, mps_ap=mps_ap@entry=0x7fffe8001770, size=size@entry=24) at /home/yantar92/Dist/mps/code/mpsi.c:1094 > #9 0x00005555557b444c in alloc_impl (size=24, type=IGC_OBJ_CONS, ap=0x7fffe8001770) at igc.c:3159 > #10 0x00005555557b454a in alloc (size=size@entry=16, type=type@entry=IGC_OBJ_CONS) at igc.c:3177 > #11 0x00005555557b5f24 in igc_make_cons (car=car@entry=0x2, cdr=cdr@entry=0x0) at igc.c:3204 > #12 0x000055555571f922 in Fcons (cdr=0x0, car=0x2) at alloc.c:2926 > #13 list2 (arg1=arg1@entry=0x7f20, arg2=arg2@entry=0x2) at alloc.c:2978 > #14 0x000055555578913c in Fdelete_process (process=0x7fffae000ffd) at process.c:1124 > #15 0x00005555557916b0 in kill_buffer_processes (buffer=buffer@entry=0x0) at process.c:8289 > #16 0x00005555556bb797 in shut_down_emacs (sig=sig@entry=6, stuff=stuff@entry=0x0) at emacs.c:3140 > #17 0x00005555556bba2f in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:464 > #18 0x00005555557b2ec9 in igc_assert_fail (file=, line=, msg=) at igc.c:158 > #19 0x000055555584d2ae in mps_lib_assert_fail (condition=0x55555588c9ee "SigCheck Thread: thread", line=67, file=0x55555588ca06 "thix.c") > at /home/yantar92/Dist/mps/code/mpsliban.c:87 > #20 ThreadCheck (thread=0x7fff98184c40) at /home/yantar92/Dist/mps/code/thix.c:67 As you see, MPS hit an assertion violation, which causes us to call shut_down_emacs. shut_down_emacs does all kinds of cleanups and attempts to auto-save unsaved edits, but while doing so it could re-enter MPS, which happens here. Should we do something, like park the arena, early on in shut_down_emacs to allow the auto-saving and cleanups to run without crashing? Or maybe ignore (some) assertions that happen during the cleanup? Btw, is this the debug build of MPS or a production build? IOW, is the second assertion, in mps_lib_assert_fail, expected in a production build? AFAIU, that assertion is hit because we re-enter the arena, and its lock is already taken.