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: a random backtrace while toying with gdb Date: Mon, 01 Jul 2024 15:33:57 +0300 Message-ID: <864j99fg0a.fsf@gnu.org> References: <87bk3jh8bt.fsf@localhost> <87wmm6rcv1.fsf@gmail.com> <86le2mhhsj.fsf@gnu.org> <875xtqramd.fsf@gmail.com> <86cynyhfsn.fsf@gnu.org> <87v81qp91g.fsf@gmail.com> <86tthafbix.fsf@gnu.org> <87plry6sv3.fsf@localhost> <86le2lfjqv.fsf@gnu.org> <87jzi5ibbe.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16072"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 01 14:34:57 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 1sOGFE-0003s7-6Y for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Jul 2024 14:34:56 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOGEN-0008Gn-H9; Mon, 01 Jul 2024 08:34:03 -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 1sOGEM-0008Fm-6x for emacs-devel@gnu.org; Mon, 01 Jul 2024 08:34:02 -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 1sOGEK-0005vK-Bt; Mon, 01 Jul 2024 08:34:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=+VV1S2EOGFxBw/Ybu5LTZaOA2WC5ubVQgnd/uQFNxLc=; b=B9oD1GOB82xI 71bogZhfnvHJksz3MLLCmmI/jWQ0nyVYuLGRCH5O348Y0qXsjlOt/rPt7YLHv5fYvNyWQW0GjG69h 2AXT3vg5NcPXSZC2J1Rfy1FtPNCBW0QuJM2RHnQUeU+a5kS63k5zpbkwAQEniB40vOaJ4kEjfNdlT OcdCFNt9mIuohnwxAgA/M5xB0PzkINy4ZabkA6mKz+BFbG1pMor6O7UZ+Bs60fiaBpOwVz/QkOGtT gK9kCaMdkC3FdiMeZ2ldBvyribGliAZHCNDrORVZWZcHeq4BkdjU40+mNcniZhqXRU6uOs96S74Jv FsDcb/t+apUxiKrrwKHNzg==; In-Reply-To: <87jzi5ibbe.fsf@localhost> (message from Ihor Radchenko on Mon, 01 Jul 2024 11:47:01 +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:321015 Archived-At: > From: Ihor Radchenko > Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com, > emacs-devel@gnu.org > Date: Mon, 01 Jul 2024 11:47:01 +0000 > > Eli Zaretskii writes: > > > As I wrote earlier, these last crashes happened when the only thread > > running was the Emacs main thread, and MPS code was called from that > > thread, as side effect of allocating memory (AFAIU). So the situation > > with multiple threads is not what we see here. > > May you point me to what in the backtrace is memory allocation? Here's the top of your original backtrace: > Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:443 > 443 { > (gdb) bt > #0 terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:443 > #1 0x00005555558634be in set_state (state=IGC_STATE_DEAD) at igc.c:179 > #2 igc_assert_fail (file=, line=, msg=) at igc.c:205 > #3 0x00005555558f1e19 in mps_lib_assert_fail (condition=0x555555943c4c "res == 0", line=126, file=0x555555943c36 "lockix.c") > at /home/yantar92/Dist/mps/code/mpsliban.c:87 > #4 LockClaim (lock=0x7fffe8000110) at /home/yantar92/Dist/mps/code/lockix.c:126 > #5 0x00005555558f204d in ArenaEnterLock (arena=0x7ffff7fbf000, recursive=0) at /home/yantar92/Dist/mps/code/global.c:576 > #6 0x000055555591aefe in ArenaEnter (arena=0x7ffff7fbf000) at /home/yantar92/Dist/mps/code/global.c:553 > #7 ArenaAccess (addr=0x7fffeb908758, mode=mode@entry=3, context=context@entry=0x7fffffff97d0) at /home/yantar92/Dist/mps/code/global.c:655 > #8 0x0000555555926202 in sigHandle (sig=, info=0x7fffffff9af0, uap=0x7fffffff99c0) at /home/yantar92/Dist/mps/code/protsgix.c:97 > #9 0x00007ffff3048050 in () at /lib64/libc.so.6 > #10 0x0000555555827385 in PSEUDOVECTORP (a=XIL(0x7fffeb90875d), code=9) at /home/yantar92/Git/emacs/src/lisp.h:1105 > #11 PROCESSP (a=XIL(0x7fffeb90875d)) at /home/yantar92/Git/emacs/src/process.h:212 > #12 XPROCESS (a=XIL(0x7fffeb90875d)) at /home/yantar92/Git/emacs/src/process.h:224 > #13 handle_child_signal (sig=sig@entry=17) at process.c:7660 > #14 0x000055555573b771 in deliver_process_signal (sig=17, handler=handler@entry=0x555555827200 ) at sysdep.c:1758 > #15 0x0000555555820647 in deliver_child_signal (sig=) at process.c:7702 > #16 0x00007ffff3048050 in () at /lib64/libc.so.6 > #17 0x000055555585f77b in fix_lisp_obj (ss=ss@entry=0x7fffffffa9a8, pobj=pobj@entry=0x7fffeee7ffe8) at igc.c:841 > #18 0x000055555586050d in fix_cons (ss=0x7fffffffa9a8, cons=0x7fffeee7ffe0) at igc.c:1474 > #19 dflt_scan_obj (ss=0x7fffffffa9a8, base_start=0x7fffeee7ffd8, base_limit=0x7fffeee80000, closure=0x0) at igc.c:1578 > #20 dflt_scanx (ss=ss@entry=0x7fffffffa9a8, base_start=, base_limit=0x7fffeee80000, closure=closure@entry=0x0) at igc.c:1658 > #21 0x00005555558613a3 in dflt_scan (ss=0x7fffffffa9a8, base_start=, base_limit=) at igc.c:1669 > #22 0x00005555558f163f in TraceScanFormat (limit=0x7fffeee80000, base=0x7fffeee7e000, ss=0x7fffffffa9a0) at /home/yantar92/Dist/mps/code/trace.c:1539 > #23 amcSegScan (totalReturn=0x7fffffffa99c, seg=0x7fffe845e4c8, ss=0x7fffffffa9a0) at /home/yantar92/Dist/mps/code/poolamc.c:1440 > #24 0x000055555591e7bc in traceScanSegRes (ts=ts@entry=1, rank=rank@entry=1, arena=arena@entry=0x7ffff7fbf000, seg=seg@entry=0x7fffe845e4c8) > at /home/yantar92/Dist/mps/code/trace.c:1205 > #25 0x000055555591e9ca in traceScanSeg (ts=1, rank=1, arena=0x7ffff7fbf000, seg=0x7fffe845e4c8) at /home/yantar92/Dist/mps/code/trace.c:1267 > #26 0x000055555591f3a4 in TraceAdvance (trace=trace@entry=0x7ffff7fbfaa8) at /home/yantar92/Dist/mps/code/trace.c:1728 > #27 0x000055555591faa4 in TracePoll > (workReturn=workReturn@entry=0x7fffffffab90, collectWorldReturn=collectWorldReturn@entry=0x7fffffffab8c, globals=globals@entry=0x7ffff7fbf008, collectWorldAllowed=) at /home/yantar92/Dist/mps/code/trace.c:1849 > #28 0x000055555591fceb in ArenaPoll (globals=globals@entry=0x7ffff7fbf008) at /home/yantar92/Dist/mps/code/global.c:745 > #29 0x00005555559200da in mps_ap_fill (p_o=p_o@entry=0x7fffffffad00, mps_ap=mps_ap@entry=0x7fffe80017f0, size=size@entry=24) > at /home/yantar92/Dist/mps/code/mpsi.c:1097 > #30 0x00005555558601ee in alloc_impl (size=24, type=IGC_OBJ_CONS, ap=0x7fffe80017f0) at igc.c:3330 > #31 0x000055555586023c in alloc (size=size@entry=16, type=type@entry=IGC_OBJ_CONS) at igc.c:3358 > #32 0x000055555586187a in igc_make_cons (car=XIL(0x133e0), cdr=XIL(0)) at igc.c:3385 > #33 0x000055555578e7de in Fcons (car=, cdr=) at alloc.c:2926 As you can see, it all started when we called Fcons, to produce a cons cell. That called igc_make_cons, which eventually called MPS memory-allocation stuff (starting from frame #29). MPS called us back (frame #21), and while in fix_lisp_obj, we got delivered SIGPROF, and attempted to access some memory that was evidently behind the barrier. The rest is history, because MPS kicked in and tried to take the arena lock the second time. There's no other thread anywhere in sight here, this all happens in the context of our own main (a.k.a. "Lisp") thread.