From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 26 13:35:36 2024 Received: (at submit) by debbugs.gnu.org; 26 Nov 2024 18:35:36 +0000 Received: from localhost ([127.0.0.1]:52360 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tG0PO-00014w-D6 for submit@debbugs.gnu.org; Tue, 26 Nov 2024 13:35:36 -0500 Received: from lists.gnu.org ([209.51.188.17]:43108) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tG0PK-00014e-OU for submit@debbugs.gnu.org; Tue, 26 Nov 2024 13:35:33 -0500 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 1tG0PD-0001bw-RQ for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2024 13:35:25 -0500 Received: from relayout02-q02.e.movistar.es ([86.109.101.152]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tG0P7-00053R-QH for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2024 13:35:23 -0500 Received: from relayout02-redir.e.movistar.es (relayout02-redir.e.movistar.es [86.109.101.202]) by relayout02-out.e.movistar.es (Postfix) with ESMTP id 4XyWTL3rfYzhZ0l for ; Tue, 26 Nov 2024 19:35:02 +0100 (CET) Received: from sky (125.red-83-37-187.dynamicip.rima-tde.net [83.37.187.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout02.e.movistar.es (Postfix) with ESMTPSA id 4XyWTK5cfFzdclZ for ; Tue, 26 Nov 2024 19:35:01 +0100 (CET) From: =?utf-8?Q?=C3=93scar_Fuentes?= To: bug-gnu-emacs@gnu.org Subject: 31.0.50; igc: assertion failed in buffer.c X-Debbugs-Cc: Date: Tue, 26 Nov 2024 19:35:00 +0100 Message-ID: <87serdu9m3.fsf@telefonica.net> MIME-Version: 1.0 Content-Type: text/plain X-TnetOut-Country: IP: 83.37.187.125 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout02 X-TnetOut-MsgID: 4XyWTK5cfFzdclZ.A1520 X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: oscarfv@telefonica.net X-TnetOut-Watermark: 1733250902.31985@gZ9xIWrCaG8l5JFmv/5JKw X-Spam-Status: No Received-SPF: pass client-ip=86.109.101.152; envelope-from=oscarfv@telefonica.net; helo=relayout02-q02.e.movistar.es X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) While editing a .dart file with lsp-mode. gdb) bt full #0 terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../emacs/src/emacs.c:433 #1 0x00005555559038cf in set_state (state=IGC_STATE_DEAD) at ../../emacs/src/igc.c:858 old_state = IGC_STATE_USABLE #2 0x0000555555902f3e in igc_assert_fail (file=0x555555a47782 "buffer.c", line=579, msg=0x555555a4a157 "size > 0") at ../../emacs/src/igc.c:209 #3 0x00005555559c1384 in mps_lib_assert_fail (condition=0x555555a4a157 "size > 0", line=579, file=0x555555a47782 "buffer.c") at /home/oscar/dev/other/mps/code/mpsliban.c:87 #4 BufferFill (pReturn=pReturn@entry=0x7fffffff9988, buffer=buffer@entry=0x7fffe8000578, size=size@entry=0) at /home/oscar/dev/other/mps/code/buffer.c:579 res = pool = base = 0x7fff93f2f7d0 limit = 0x1 next = #5 0x00005555559f2da0 in amcSegFix (seg=0x7fffb820d070, ss=0x7fffffff9fc0, refIO=0x7fffffff99d0) at /home/oscar/dev/other/mps/code/poolamc.c:1633 clientQ = arena = 0x7ffff7fbf000 pool = amc = res = format = 0x7fffe8000388 headerSize = 0 --Type for more, q to quit, c to continue without paging-- ref = base = newRef = newBase = 0x7fff8a259f28 length = 0 buffer = 0x7fffe8000578 gen = grey = toSeg = ti = trace = #6 0x0000555555990b8c in _mps_fix2 (mps_ss=0x7fffffff9fc8, mps_ref_io=0x7fffffff9a10) at /home/oscar/dev/other/mps/code/trace.c:1433 ss = 0x7fffffff9fc0 ref = 0x7fff93f2f7d0 chunk = 0x7fff84000000 i = tract = seg = res = #7 0x0000555555903cac in fix_lisp_obj (ss=0x7fffffff9fc8, pobj=0x7fff89f0e000) at ../../emacs/src/igc.c:998 res = 32767 client = 0x7fff93f2f7d0 base = 0x7fff93f2f7d0 p = 0x7fff89f0e000 --Type for more, q to quit, c to continue without paging-- word = 140735675561940 tag = 4 _ss = 0x7fffffff9fc8 _mps_zs = 22 _mps_ufs = 549755846664 _mps_wt = 32768 _mps_w = 133143986160 #8 0x0000555555904160 in fix_array (ss=0x7fffffff9fc8, array=0x7fff89f0e000, n=6) at ../../emacs/src/igc.c:1233 res = 30 i = 0 _ss = 0x7fffffff9fc8 _mps_zs = 22 _mps_ufs = 549755813896 _mps_wt = _mps_w = 133143986160 #9 0x000055555590674b in fix_vectorlike (ss=0x7fffffff9fc8, v=0x7fff89f0dff0) at ../../emacs/src/igc.c:1974 res = 32767 size = 6 _ss = 0x7fffffff9fc8 _mps_zs = 22 _mps_ufs = 549755813896 _mps_wt = _mps_w = 133143986160 #10 0x0000555555908d53 in fix_vector (ss=0x7fffffff9fc8, v=0x7fff89f0dff0) --Type for more, q to quit, c to continue without paging-- at ../../emacs/src/igc.c:2646 obj_ = 0x7fff89f0dff0 res = 0 _ss = 0x7fffffff9fc8 _mps_zs = 22 _mps_ufs = 549755813896 _mps_wt = _mps_w = 133143986160 #11 0x00005555559061d4 in dflt_scan_obj (ss=0x7fffffff9fc8, base_start=0x7fff89f0dff0, base_limit=0x7fff89f0f000, closure=0x0) at ../../emacs/src/igc.c:1888 obj_ = 0x7fff89f0dff0 res = 0 base = 0x7fff89f0dff0 client = 0x7fff89f0dff0 header = 0x7fff89f0dff0 _ss = 0x7fffffff9fc8 _mps_zs = 22 _mps_ufs = 549755813896 _mps_wt = _mps_w = 133143986160 #12 0x0000555555906619 in dflt_scanx (ss=0x7fffffff9fc8, base_start=0x7fff89f0d000, base_limit=0x7fff89f0f000, closure=0x0) at ../../emacs/src/igc.c:1951 res = 0 base = 0x7fff89f0dff0 --Type for more, q to quit, c to continue without paging-- _ss = 0x7fffffff9fc8 _mps_zs = 22 _mps_ufs = 549755813896 _mps_wt = _mps_w = 133143986160 #13 0x00005555559066b8 in dflt_scan (ss=0x7fffffff9fc8, base_start=0x7fff89f0d000, base_limit=0x7fff89f0f000) at ../../emacs/src/igc.c:1962 res = 0 _ss = 0x7fffffff9fc8 _mps_zs = 22 _mps_ufs = 0 _mps_wt = _mps_w = 133143986160 #14 0x00005555559c25bf in TraceScanFormat (limit=0x7fff89f0f000, base=0x7fff89f0d000, ss=0x7fffffff9fc0) at /home/oscar/dev/other/mps/code/trace.c:1539 #15 amcSegScan (totalReturn=0x7fffffff9fbc, seg=0x7fffb82b3340, ss=0x7fffffff9fc0) at /home/oscar/dev/other/mps/code/poolamc.c:1440 base = 0x7fff89f0d000 limit = 0x7fff89f0f000 format = 0x7fffe8000388 pool = amc = res = buffer = 0x5555559bf6d8 --Type for more, q to quit, c to continue without paging-- #16 0x00005555559ee4f9 in traceScanSegRes (ts=ts@entry=1, rank=rank@entry=1, arena=arena@entry=0x7ffff7fbf000, seg=seg@entry=0x7fffb82b3340) at /home/oscar/dev/other/mps/code/trace.c:1205 ssStruct = { sig = 1368771141, ss_s = { _zs = 22, _w = 133143986160, _ufs = 549755813896 }, arena = 0x7ffff7fbf000, formatScan = 0x555555906660 , areaScan = 0x555555980ca0 , areaScanClosure = 0x7ffff7fbf000, fix = 0x555555982120 , fixClosure = 0x0, traces = 1, rank = 1, wasMarked = 0, fixedSummary = 0, scannedSize = 8192 } ss = 0x7fffffff9fc0 wasTotal = 1 white = 133143986160 res = --Type for more, q to quit, c to continue without paging-- #17 0x00005555559ee6ea in traceScanSeg (ts=1, rank=1, arena=0x7ffff7fbf000, seg=0x7fffb82b3340) at /home/oscar/dev/other/mps/code/trace.c:1267 res = #18 0x00005555559ef0c4 in TraceAdvance (trace=trace@entry=0x7ffff7fbfaa8) at /home/oscar/dev/other/mps/code/trace.c:1728 res = seg = 0x7fffb82b3340 rank = 1 arena = oldWork = newWork = #19 0x00005555559ef754 in TracePoll (workReturn=workReturn@entry=0x7fffffffa198, collectWorldReturn=collectWorldReturn@entry=0x7fffffffa194, globals=globals@entry=0x7ffff7fbf008, collectWorldAllowed=) at /home/oscar/dev/other/mps/code/trace.c:1849 trace = 0x7ffff7fbfaa8 arena = 0x7ffff7fbf000 oldWork = 21021000 newWork = work = endWork = 21201780 #20 0x00005555559ef94b in ArenaPoll (globals=globals@entry=0x7ffff7fbf008) at /home/oscar/dev/other/mps/code/global.c:745 arena = 0x7ffff7fbf000 start = 127960946 worldCollected = 0 --Type for more, q to quit, c to continue without paging-- moreWork = workWasDone = 1 tracedWork = 188224 #21 0x00005555559efce7 in mps_ap_fill (p_o=0x7fffffffa320, mps_ap=0x7fffe8001980, size=24) at /home/oscar/dev/other/mps/code/mpsi.c:1097 _sc = { jumpBuffer = {{ __jmpbuf = {140737085708576, 7934441737627226205, 140737488341000, 140737488346136, 93825011090592, 93824998081432, 7934441737587380317, 4272113373193949277}, __mask_was_saved = 0, __saved_mask = { __val = {8589988184, 140735675617355, 53592, 93824998129552, 46912143837648, 8, 1216, 140735675620139, 53592, 93825011044696, 53592, 93824998129552, 8, 24, 140737488331504, 93824996095173} } }} } buf = 0x7fffe8001920 arena = 0x7ffff7fbf000 p = 0xd158 res = #22 0x000055555590b0c2 in alloc_impl (size=24, type=IGC_OBJ_CONS, ap=0x7fffe8001980) at ../../emacs/src/igc.c:3802 res = 21845 p = 0x0 #23 0x000055555590b1b4 in alloc (size=24, type=IGC_OBJ_CONS) at ../../emacs/src/igc.c:3830 #24 0x000055555590b267 in igc_make_cons (car=XIL(0x2aaa95ab49d0), cdr=XIL(0x7fffeccdc75c)) --Type for more, q to quit, c to continue without paging-- at ../../emacs/src/igc.c:3859 cons = 0x0 #25 0x00005555558022c0 in Fcons (car=XIL(0x2aaa95ab49d0), cdr=XIL(0x7fffeccdc75c)) at ../../emacs/src/alloc.c:2955 #26 0x0000555555842ced in funcall_lambda (fun=XIL(0x7fff93f3e2a5), nargs=1, arg_vector=0x7fffffffa5d8) at ../../emacs/src/eval.c:3324 arg = XIL(0x7fffeccdc75c) next = XIL(0x2aaa95ab49d0) syms_left = XIL(0x7fffec95ce6b) lexenv = XIL(0x7fffc0fb14cb) count = { bytes = 1152 } i = 1 optional = false rest = false previous_rest = false val = XIL(0) #27 0x0000555555841da2 in funcall_general (fun=XIL(0x7fff93f3e2a5), numargs=1, args=0x7fffffffa5d8) at ../../emacs/src/eval.c:3050 original_fun = XIL(0x7fff93f3e2a5) #28 0x0000555555842064 in Ffuncall (nargs=2, args=0x7fffffffa5d0) at ../../emacs/src/eval.c:3099 count = { bytes = 1120 } val = XIL(0) --Type for more, q to quit, c to continue without paging-- #29 0x0000555555854850 in mapcar1 (leni=15, vals=0x7fffffffa660, fn=XIL(0x7fff93f3e2a5), seq=XIL(0x7fff93f3e44b)) at ../../emacs/src/fns.c:3373 dummy = XIL(0) i = 12 tail = XIL(0x7fff93f3e56b) #30 0x0000555555854fde in Fmapcar (function=XIL(0x7fff93f3e2a5), sequence=XIL(0x7fff93f3e44b)) at ../../emacs/src/fns.c:3493 sa_avail = 16264 sa_count = { bytes = 1120 } leni = 15 args = 0x7fffffffa660 nmapped = 140737488332592 ret = XIL(0x555555839828) #31 0x0000555555840b20 in eval_sub (form=XIL(0x7fffeded0a33)) at ../../emacs/src/eval.c:2607 i = 2 maxargs = 2 args_left = XIL(0) numargs = 2 original_fun = XIL(0x2aaa6a8789a0) original_args = XIL(0x7fffeded0cab) count = { bytes = 1088 } --Type for more, q to quit, c to continue without paging-- fun = XIL(0x5555566b7265) val = XIL(0x7fffffffa800) funcar = XIL(0) argvals = {XIL(0x7fff93f3e2a5), XIL(0x7fff93f3e44b), XIL(0x2420000026600), XIL(0x2440000027000), XIL(0x555556ae8628), XIL(0x7ffff76dc739), XIL(0x555556738000), XIL(0)} #32 0x000055555583ceb5 in Flet (args=XIL(0x7fffedecf953)) at ../../emacs/src/eval.c:1084 temps = 0x7fffffffa870 tem = XIL(0x5555566b47a5) lexenv = XIL(0x135584a4ab) elt = XIL(0x7fffeded0283) count = { bytes = 1088 } argnum = 0 sa_avail = 16368 sa_count = { bytes = 1088 } varlist = XIL(0x7fffeded029b) varlist_len = 2 nvars = 2 #33 0x0000555555840798 in eval_sub (form=XIL(0x7fffedecf2cb)) at ../../emacs/src/eval.c:2555 args_left = XIL(0x7fffedecf953) numargs = 2 original_fun = XIL(0xe1c0) original_args = XIL(0x7fffedecf953) --Type for more, q to quit, c to continue without paging-- count = { bytes = 1056 } fun = XIL(0x5555566b47a5) val = XIL(0x7fffb61b20b0) funcar = XIL(0x555555af3f90) argvals = {XIL(0x1ffffa9d0), XIL(0), XIL(0x7fff93f3d04b), XIL(0xd158), XIL(0x5555558179e4), XIL(0x555555af3f90), XIL(0x7fffffffa9e0), XIL(0x555555817afb)} #34 0x000055555583b494 in Fprogn (body=XIL(0x7fffedecf2e3)) at ../../emacs/src/eval.c:443 form = XIL(0x7fffedecf2cb) val = XIL(0) #35 0x000055555583d0a8 in Flet (args=XIL(0x7fffedecddfb)) at ../../emacs/src/eval.c:1113 temps = 0x7fffffffaa90 tem = XIL(0) lexenv = XIL(0x7fff93f3d04b) elt = XIL(0x2aaa97797290) count = { bytes = 1024 } argnum = 1 sa_avail = 16376 sa_count = { bytes = 1024 } varlist = XIL(0) varlist_len = 1 --Type for more, q to quit, c to continue without paging-- nvars = 1 #36 0x0000555555840798 in eval_sub (form=XIL(0x7fffedecd043)) at ../../emacs/src/eval.c:2555 args_left = XIL(0x7fffedecddfb) numargs = 3 original_fun = XIL(0xe1c0) original_args = XIL(0x7fffedecddfb) count = { bytes = 992 } fun = XIL(0x5555566b47a5) val = XIL(0x555555848d14) funcar = XIL(0x7fffffffac10) argvals = {XIL(0x7fffffffad80), XIL(0x555555981480), XIL(0x555556738000), XIL(0), XIL(0), XIL(0x7fffffffabe0), make_fixnum(23456248831157), XIL(0)} #37 0x0000555555840a3e in eval_sub (form=XIL(0x7fffede44f43)) at ../../emacs/src/eval.c:2592 i = 0 maxargs = 1 args_left = XIL(0x7fffede4724b) numargs = 1 original_fun = XIL(0x2aaa6a87dd60) original_args = XIL(0x7fffede4724b) count = { bytes = 960 } fun = XIL(0x5555566b6cc5) val = XIL(0x7fffffffad30) --Type for more, q to quit, c to continue without paging-- funcar = XIL(0) argvals = {XIL(0x7fffe8011458), XIL(0x7fffffffada8), XIL(0x5555559813c0), XIL(0x5555559813e0), XIL(0x7fffffffad98), XIL(0x7fffffffaea0), XIL(0x555556738000), XIL(0)} #38 0x0000555555842835 in apply_lambda (fun=XIL(0x7fffbc35adc5), args=XIL(0x7fffede44c4b), count=...) at ../../emacs/src/eval.c:3216 i = 0 arg_vector = 0x7fffffffada0 tem = XIL(0x7fffede44f43) sa_avail = 16368 sa_count = { bytes = 960 } numargs = 2 args_left = XIL(0x7fffede44f5b) #39 0x0000555555840d36 in eval_sub (form=XIL(0x7fffede4495b)) at ../../emacs/src/eval.c:2651 original_fun = XIL(0x2aaa961a0fa8) original_args = XIL(0x7fffede44c4b) count = { bytes = 928 } fun = XIL(0x7fffbc35adc5) val = XIL(0x7fffb61b20b0) funcar = XIL(0x555555af3f90) argvals = {XIL(0x184183dd0), XIL(0), XIL(0x7fffec29f443), XIL(0xd158), XIL(0x5555558179e4), XIL(0x555555af3f90), XIL(0x7fffffffaee0), XIL(0x555555817afb)} #40 0x000055555583b494 in Fprogn (body=XIL(0)) at ../../emacs/src/eval.c:443 --Type for more, q to quit, c to continue without paging-- form = XIL(0x7fffede4495b) val = XIL(0) #41 0x0000555555842f49 in funcall_lambda (fun=XIL(0x7fffede44245), nargs=0, arg_vector=0x7fffffffb020) at ../../emacs/src/eval.c:3356 syms_left = XIL(0) lexenv = XIL(0x7fffec29f443) count = { bytes = 896 } i = 0 optional = false rest = false previous_rest = false val = XIL(0x23) #42 0x000055555584289b in apply_lambda (fun=XIL(0x7fffede44245), args=XIL(0), count=...) at ../../emacs/src/eval.c:3221 arg_vector = 0x7fffffffb020 tem = XIL(0x219770bee0) sa_avail = 16384 sa_count = { bytes = 896 } numargs = 0 args_left = XIL(0) #43 0x0000555555840d36 in eval_sub (form=XIL(0x7fffede43b9b)) at ../../emacs/src/eval.c:2651 original_fun = XIL(0x2aaa9770bee0) --Type for more, q to quit, c to continue without paging-- original_args = XIL(0) count = { bytes = 864 } fun = XIL(0x7fffede44245) val = XIL(0x7fff93f3cfc0) funcar = make_fixnum(23456248816738) argvals = {XIL(0x7fffffffb150), XIL(0x55555584f9f5), XIL(0x7fff93f3cfdb), XIL(0x2aaa961dc2d8), XIL(0x555556738000), XIL(0), XIL(0), XIL(0x7fff93f3cfc3)} #44 0x000055555583cac0 in FletX (args=XIL(0x7fffec978b93)) at ../../emacs/src/eval.c:1021 li = { tortoise = XIL(0x7fffec978c13), max = 2, n = 0, q = 2 } var = XIL(0x2aaa9a427760) val = XIL(0x7fffffffb250) elt = XIL(0x7fffede43543) lexenv = XIL(0x7fff93f3d01b) count = { bytes = 864 } varlist = XIL(0x7fffec978c13) #45 0x0000555555840798 in eval_sub (form=XIL(0x7fffec978b33)) at ../../emacs/src/eval.c:2555 args_left = XIL(0x7fffec978b93) --Type for more, q to quit, c to continue without paging-- numargs = 2 original_fun = XIL(0xe1f8) original_args = XIL(0x7fffec978b93) count = { bytes = 832 } fun = XIL(0x5555566b4745) val = XIL(0x5555567504a0) funcar = XIL(0x7fffffffdc18) argvals = {XIL(0x7ffff7fbf000), XIL(0x5555559e601c), XIL(0x18), XIL(0x7fffe80003f8), XIL(0x7fffffffb398), XIL(0x7ffff7fbf000), XIL(0x7fffe8000110), XIL(0x7fffffffc808)} #46 0x000055555583b34d in Fif (args=XIL(0x7fffec978a53)) at ../../emacs/src/eval.c:398 cond = XIL(0x38) #47 0x0000555555840798 in eval_sub (form=XIL(0x7fffec9789cb)) at ../../emacs/src/eval.c:2555 args_left = XIL(0x7fffec978a53) numargs = 3 original_fun = XIL(0xc6a0) original_args = XIL(0x7fffec978a53) count = { bytes = 800 } fun = XIL(0x5555566b40e5) val = make_fixnum(23456249031744) funcar = XIL(0x7fffffffb4b0) argvals = {XIL(0x7fffffffb470), make_fixnum(23456249023624), XIL(0x5b4ad3), XIL(0x18), XIL(0x300000018), XIL(0x7fff93f3d018), XIL(0x18), XIL(0x1)} --Type for more, q to quit, c to continue without paging-- #48 0x000055555583b494 in Fprogn (body=XIL(0)) at ../../emacs/src/eval.c:443 form = XIL(0x7fffec9789cb) val = XIL(0) #49 0x000055555583ccb0 in FletX (args=XIL(0x7fffec97874b)) at ../../emacs/src/eval.c:1046 var = XIL(0x2aaa96240a98) val = XIL(0x38) elt = XIL(0x7fffec978a3b) lexenv = XIL(0x7fffec29f443) count = { bytes = 768 } varlist = XIL(0) #50 0x0000555555840798 in eval_sub (form=XIL(0x7fffec978693)) at ../../emacs/src/eval.c:2555 args_left = XIL(0x7fffec97874b) numargs = 2 original_fun = XIL(0xe1f8) original_args = XIL(0x7fffec97874b) count = { bytes = 736 } fun = XIL(0x5555566b4745) val = XIL(0x55555669b880) funcar = XIL(0x7fffffffb670) argvals = {XIL(0x7fffffffb650), XIL(0x7fffe8001980), XIL(0x300000000), XIL(0x18), XIL(0x555556738000), XIL(0), XIL(0), XIL(0x2e0)} #51 0x000055555583de53 in internal_lisp_condition_case --Type for more, q to quit, c to continue without paging-- (var=XIL(0), bodyform=XIL(0x7fffec978693), handlers=XIL(0x7fffec9786ab)) at ../../emacs/src/eval.c:1544 clause = XIL(0x7fffec978763) condition = XIL(0x7fff93f3cf7b) c = 0x7fffefb28298 clauses_volatile = 0x7fffffffb6f0 pcl = 0x7fffffffb6f8 oldhandlerlist = 0x7fffec0289e8 clausenb = 2 success_handler = XIL(0) clauses = 0x7fffffffb6f0 var_volatile = XIL(0) val = XIL(0x7fffffffb7a0) handler_body = XIL(0x555556deab60) count = { bytes = 736 } #52 0x000055555583d951 in Fcondition_case (args=XIL(0x7fffec9783d3)) at ../../emacs/src/eval.c:1443 var = XIL(0) bodyform = XIL(0x7fffec978693) handlers = XIL(0x7fffec9786ab) #53 0x0000555555840798 in eval_sub (form=XIL(0x7fffec9781b3)) at ../../emacs/src/eval.c:2555 args_left = XIL(0x7fffec9783d3) numargs = 3 original_fun = XIL(0x6f20) original_args = XIL(0x7fffec9783d3) --Type for more, q to quit, c to continue without paging-- count = { bytes = 704 } fun = XIL(0x5555566b4a45) val = XIL(0x7fffb61b20b0) funcar = XIL(0x555555af3f90) argvals = {XIL(0x193f3cea3), XIL(0), XIL(0x7fffec29f443), XIL(0xd158), XIL(0x5555558179e4), XIL(0x555555af3f90), XIL(0x7fffffffb8f0), XIL(0x555555817afb)} #54 0x000055555583b494 in Fprogn (body=XIL(0)) at ../../emacs/src/eval.c:443 form = XIL(0x7fffec9781b3) val = XIL(0) #55 0x0000555555842f49 in funcall_lambda (fun=XIL(0x7fffec977e75), nargs=0, arg_vector=0x7fffffffba30) at ../../emacs/src/eval.c:3356 syms_left = XIL(0) lexenv = XIL(0x7fffec29f443) count = { bytes = 672 } i = 0 optional = false rest = false previous_rest = false val = make_fixnum(34910567923712) #56 0x000055555584289b in apply_lambda (fun=XIL(0x7fffec977e75), args=XIL(0), count=...) at ../../emacs/src/eval.c:3221 arg_vector = 0x7fffffffba30 --Type for more, q to quit, c to continue without paging-- tem = XIL(0x219623fc48) sa_avail = 16384 sa_count = { bytes = 672 } numargs = 0 args_left = XIL(0) #57 0x0000555555840d36 in eval_sub (form=XIL(0x7fffec977a23)) at ../../emacs/src/eval.c:2651 original_fun = XIL(0x2aaa9623fc48) original_args = XIL(0) count = { bytes = 640 } fun = XIL(0x7fffec977e75) val = XIL(0x4590) funcar = XIL(0x7fffffffbb80) argvals = {XIL(0x280), XIL(0x280), XIL(0x555556738000), XIL(0), XIL(0), XIL(0x7fffffffbb50), make_fixnum(23456248831157), XIL(0xffffbb60)} #58 0x0000555555840a3e in eval_sub (form=XIL(0x7fffec976bfb)) at ../../emacs/src/eval.c:2592 i = 2 maxargs = 3 args_left = XIL(0x7fffec97776b) numargs = 3 original_fun = XIL(0x2aaa958f80b0) original_args = XIL(0x7fffec977003) count = { --Type for more, q to quit, c to continue without paging-- bytes = 608 } fun = XIL(0x5555566ab025) val = XIL(0) funcar = XIL(0x555555af3f90) argvals = {XIL(0x7fffed4cb0ad), XIL(0x4590), XIL(0x7fff93f3cf63), XIL(0xd158), XIL(0x5555558179e4), XIL(0x555555af3f90), XIL(0x7fffffffbc90), XIL(0x555555817afb)} #59 0x000055555583b494 in Fprogn (body=XIL(0)) at ../../emacs/src/eval.c:443 form = XIL(0x7fffec976bfb) val = XIL(0) #60 0x000055555583d0a8 in Flet (args=XIL(0x7fffec97615b)) at ../../emacs/src/eval.c:1113 temps = 0x7fffffffbd40 tem = make_fixnum(0) lexenv = XIL(0x7fff93f3cf63) elt = XIL(0x7fffec976be3) count = { bytes = 576 } argnum = 2 sa_avail = 16368 sa_count = { bytes = 576 } varlist = XIL(0) varlist_len = 2 nvars = 2 --Type for more, q to quit, c to continue without paging-- #61 0x0000555555840798 in eval_sub (form=XIL(0x7fffec975e3b)) at ../../emacs/src/eval.c:2555 args_left = XIL(0x7fffec97615b) numargs = 3 original_fun = XIL(0xe1c0) original_args = XIL(0x7fffec97615b) count = { bytes = 544 } fun = XIL(0x5555566b47a5) val = XIL(0x7ffff7fbf000) funcar = XIL(0x7fffec975e23) argvals = {XIL(0x7ffff7fbf000), XIL(0x7fffbe437045), XIL(0x7fffe0a702c0), XIL(0x7ffff7fbf658), XIL(0x7ffff7fbf000), XIL(0x5555559e601c), XIL(0x7fffb817a3a8), XIL(0x5555559ed408)} #62 0x000055555583b494 in Fprogn (body=XIL(0x7fffec975e53)) at ../../emacs/src/eval.c:443 form = XIL(0x7fffec975e3b) val = XIL(0) #63 0x000055555583b4c4 in prog_ignore (body=XIL(0x7fffec975b23)) at ../../emacs/src/eval.c:454 #64 0x000055555583d111 in Fwhile (args=XIL(0x7fffec975683)) at ../../emacs/src/eval.c:1134 test = XIL(0x7fffec975b0b) body = XIL(0x7fffec975b23) #65 0x0000555555840798 in eval_sub (form=XIL(0x7fffec9751f3)) at ../../emacs/src/eval.c:2555 args_left = XIL(0x7fffec975683) numargs = 3 original_fun = XIL(0x2aaa95906448) original_args = XIL(0x7fffec975683) count = { --Type for more, q to quit, c to continue without paging-- bytes = 512 } fun = XIL(0x5555566b4805) val = XIL(0x7fffb61b20b0) funcar = XIL(0x555555af3f90) argvals = {XIL(0x1ffffc060), XIL(0), XIL(0x7fff93f3cea3), XIL(0xd158), XIL(0x5555558179e4), XIL(0x555555af3f90), XIL(0x7fffffffc070), XIL(0x555555817afb)} #66 0x000055555583b494 in Fprogn (body=XIL(0)) at ../../emacs/src/eval.c:443 form = XIL(0x7fffec9751f3) val = XIL(0) #67 0x000055555583d0a8 in Flet (args=XIL(0x7fffec974853)) at ../../emacs/src/eval.c:1113 temps = 0x7fffffffc120 tem = XIL(0) lexenv = XIL(0x7fff93f3cea3) elt = XIL(0x2aaa9623dad0) count = { bytes = 480 } argnum = 3 sa_avail = 16360 sa_count = { bytes = 480 } varlist = XIL(0) varlist_len = 3 nvars = 3 --Type for more, q to quit, c to continue without paging-- #68 0x0000555555840798 in eval_sub (form=XIL(0x7fffec974333)) at ../../emacs/src/eval.c:2555 args_left = XIL(0x7fffec974853) numargs = 2 original_fun = XIL(0xe1c0) original_args = XIL(0x7fffec974853) count = { bytes = 448 } fun = XIL(0x5555566b47a5) val = XIL(0x7fffffffc2a0) funcar = XIL(0) argvals = {XIL(0x7fff93f3cdd3), XIL(0x7fff93f3cd73), XIL(0x7fff93f3cdd3), XIL(0x7fff93f3cd73), XIL(0), make_fixnum(1000000000000), XIL(0x555556738000), XIL(0)} #69 0x000055555583b494 in Fprogn (body=XIL(0)) at ../../emacs/src/eval.c:443 form = XIL(0x7fffec974333) val = XIL(0) #70 0x000055555583b36f in Fif (args=XIL(0x7fffec973573)) at ../../emacs/src/eval.c:399 cond = XIL(0) #71 0x0000555555840798 in eval_sub (form=XIL(0x7fffec973133)) at ../../emacs/src/eval.c:2555 args_left = XIL(0x7fffec973573) numargs = 3 original_fun = XIL(0xc6a0) original_args = XIL(0x7fffec973573) count = { bytes = 416 } --Type for more, q to quit, c to continue without paging-- fun = XIL(0x5555566b40e5) val = XIL(0x7fffb61b20b0) funcar = XIL(0x555555af3f90) argvals = {XIL(0x1ffffc400), XIL(0), XIL(0x7fffec29f443), XIL(0xd158), XIL(0x5555558179e4), XIL(0x555555af3f90), XIL(0x7fffffffc430), XIL(0x555555817afb)} #72 0x000055555583b494 in Fprogn (body=XIL(0)) at ../../emacs/src/eval.c:443 form = XIL(0x7fffec973133) val = XIL(0) #73 0x0000555555842f49 in funcall_lambda (fun=XIL(0x7fffec9726bd), nargs=0, arg_vector=0x7fffffffc818) at ../../emacs/src/eval.c:3356 syms_left = XIL(0) lexenv = XIL(0x7fffec29f443) count = { bytes = 384 } i = 0 optional = false rest = false previous_rest = false val = XIL(0x555555ae8398) #74 0x0000555555841da2 in funcall_general (fun=XIL(0x7fffec9726bd), numargs=0, args=0x7fffffffc818) at ../../emacs/src/eval.c:3050 original_fun = XIL(0x2aaa9623a0a0) #75 0x0000555555842064 in Ffuncall (nargs=1, args=0x7fffffffc810) at ../../emacs/src/eval.c:3099 count = { bytes = 352 --Type for more, q to quit, c to continue without paging-- } val = make_fixnum(0) #76 0x000055555584112d in Fapply (nargs=2, args=0x7fffffffc810) at ../../emacs/src/eval.c:2724 i = 140736340922707 funcall_nargs = 56 funcall_args = 0x0 spread_arg = XIL(0) fun = XIL(0x2aaa9623a0a0) sa_avail = 16384 sa_count = { bytes = 352 } numargs = 0 retval = XIL(0x567d38e0) #77 0x00005555558425ee in funcall_subr (subr=0x5555566b4ce0 , numargs=2, args=0x7fffffffc810) at ../../emacs/src/eval.c:3190 maxargs = -2 fun = XIL(0x555555839828) #78 0x0000555555841d56 in funcall_general (fun=XIL(0x5555566b4ce5), numargs=2, args=0x7fffffffc810) at ../../emacs/src/eval.c:3046 original_fun = XIL(0x48a0) #79 0x0000555555842064 in Ffuncall (nargs=3, args=0x7fffffffc808) at ../../emacs/src/eval.c:3099 count = { bytes = 320 } val = make_fixnum(23456248827543) --Type for more, q to quit, c to continue without paging-- #80 0x00007fffe0a652c9 in F74696d65722d6576656e742d68616e646c6572_timer_event_handler_0 () at /home/oscar/dev/emacs/igc-debug/src/../native-lisp/31.0.50-25e6c268/preloaded/timer-3ee7cfd9-faf18a90.eln #81 0x0000555555842394 in funcall_subr (subr=0x7fffec024b60, numargs=1, args=0x7fffffffc9c8) at ../../emacs/src/eval.c:3167 argbuf = {XIL(0x7fffec024b65), XIL(0x7fffffffc8b0), XIL(0x555556738000), XIL(0), XIL(0), XIL(0x13ffffc8d0), XIL(0x7fffec024b65), XIL(0x7fffffffc8e0)} a = 0x7fffffffc9c8 maxargs = 1 fun = XIL(0x555555839828) #82 0x0000555555841d56 in funcall_general (fun=XIL(0x7fffec024b65), numargs=1, args=0x7fffffffc9c8) at ../../emacs/src/eval.c:3046 original_fun = XIL(0x150e0) #83 0x0000555555842064 in Ffuncall (nargs=2, args=0x7fffffffc9c0) at ../../emacs/src/eval.c:3099 count = { bytes = 224 } val = XIL(0x150e0) #84 0x000055555576e3e2 in timer_check_2 (timers=XIL(0x7fff93f3c8cb), idle_timers=XIL(0x7fff93f3c95b)) at ../../emacs/src/keyboard.c:4820 count = { bytes = 192 } old_deactivate_mark = XIL(0) chosen_timer = XIL(0x7fffbe437045) timer = XIL(0x7fffbe437045) --Type for more, q to quit, c to continue without paging-- idle_timer = XIL(0x7fffedd1d0c5) ripe = true timer_ripe = true idle_timer_ripe = true difference = { tv_sec = 0, tv_nsec = 527695107 } timer_difference = { tv_sec = 0, tv_nsec = 527695107 } idle_timer_difference = { tv_sec = 0, tv_nsec = 511956257 } now = { tv_sec = 1732645572, tv_nsec = 273958132 } idleness_now = { tv_sec = 0, tv_nsec = 636956257 } #85 0x000055555576e527 in timer_check () at ../../emacs/src/keyboard.c:4885 nexttime = { --Type for more, q to quit, c to continue without paging-- tv_sec = 93824995782329, tv_nsec = 363641187 } timers = XIL(0x7fff93f3c8b3) idle_timers = XIL(0x7fff93f3c943) tem = XIL(0) #86 0x00005555558c556b in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at ../../emacs/src/process.c:5433 old_timers_run = 5142 process_skipped = false wrapped = true channel_start = 21 child_fd = 13 last_read_channel = 20 channel = 21 nfds = 1 Available = { fds_bits = {0 } } Writeok = { fds_bits = {0 } } check_write = true check_delay = 2 no_avail = false --Type for more, q to quit, c to continue without paging-- xerrno = 11 proc = XIL(0x7fffec0a9005) timeout = { tv_sec = 29, tv_nsec = 363641187 } end_time = { tv_sec = 1732645601, tv_nsec = 637403875 } timer_delay = { tv_sec = 0, tv_nsec = 75496097 } got_output_end_time = { tv_sec = 0, tv_nsec = -1 } wait = TIMEOUT got_some_output = 111340 prev_wait_proc_nbytes_read = 0 retry_for_async = false count = { bytes = 160 } now = { --Type for more, q to quit, c to continue without paging-- tv_sec = 1732645572, tv_nsec = 273762688 } #87 0x00005555555b3552 in sit_for (timeout=make_fixnum(30), reading=true, display_option=1) at ../../emacs/src/dispnew.c:6362 sec = 30 nsec = 0 do_display = true curbuf_eq_winbuf = true nbytes = 21845 #88 0x0000555555769966 in read_char (commandflag=1, map=XIL(0x7fff93a23273), prev_event=XIL(0), used_mouse_menu=0x7fffffffd41f, end_time=0x0) at ../../emacs/src/keyboard.c:2937 tem0 = XIL(0xca90) timeout = 30 count1 = { bytes = 128 } delay_level = 4 buffer_size = 54 c = XIL(0) local_getcjmp = {{ __jmpbuf = {0, 7934441734953357405, 0, 140737488346136, 140737354125312, 93824998081432, 7934441734561189981, 4272114679796584541}, __mask_was_saved = 0, __saved_mask = { --Type for more, q to quit, c to continue without paging-- __val = {93824996094498, 5850328, 24, 12884901912, 140735670268528, 24, 1, 140737488343728, 93824996126978, 0, 140737085708672, 17179857584, 24, 140735670268528, 1451047136, 17179857616} } }} save_jump = {{ __jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = { __val = {0 } } }} tem = XIL(0x7fffffffd130) save = XIL(0x7fffb61b20b5) previous_echo_area_message = XIL(0) also_record = XIL(0) reread = false recorded = false polling_stopped_here = false orig_kboard = 0x555556924ec0 jmpcount = { bytes = 128 } c_volatile = XIL(0) #89 0x000055555577c969 in read_key_sequence (keybuf=0x7fffffffd5d0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false, disable_text_conversion_p=false) --Type for more, q to quit, c to continue without paging-- at ../../emacs/src/keyboard.c:10763 interrupted_kboard = 0x555556924ec0 interrupted_frame = 0x7fffe341bca0 key = XIL(0xd430) used_mouse_menu = false echo_local_start = 0 last_real_key_start = 0 keys_local_start = 0 new_binding = XIL(0x7fffffffd538) count = { bytes = 96 } t = 0 echo_start = 0 keys_start = 0 current_binding = XIL(0x7fff93a23273) first_unbound = 31 mock_input = 0 used_mouse_menu_history = {false } fkey = { parent = XIL(0x7fffe3147cc3), map = XIL(0x7fffe3147cc3), start = 0, end = 0 } keytran = { --Type for more, q to quit, c to continue without paging-- parent = XIL(0x7fffec00127b), map = XIL(0x7fffec00127b), start = 0, end = 0 } indec = { parent = XIL(0x7fffe3147cab), map = XIL(0x7fffe3147cab), start = 0, end = 0 } shift_translated = false delayed_switch_frame = XIL(0) original_uppercase = XIL(0) original_uppercase_position = -1 disabled_conversion = false starting_buffer = 0x7fffb61b20b0 fake_prefixed_keys = XIL(0) first_event = XIL(0) second_event = XIL(0) #90 0x000055555576522c in command_loop_1 () at ../../emacs/src/keyboard.c:1435 cmd = XIL(0x2aaa95abfe00) keybuf = {XIL(0x12a98), make_fixnum(107), XIL(0x7fffffffd660), XIL(0x55555581ba01), XIL(0x200000038), XIL(0), XIL(0), XIL(0xd158), XIL(0x7fffe3a959e4), XIL(0x7fffe3a959cb), XIL(0x7fffe3a959cb), XIL(0xd158), XIL(0x555555af3f90), XIL(0x7fffe1886988), XIL(0), XIL(0x555556745158), make_fixnum(23456248779936), XIL(0), XIL(0x7fffffffd6f0), XIL(0x55555581c579), XIL(0x7fffe188698d), XIL(0x256dea900), XIL(0), --Type for more, q to quit, c to continue without paging-- XIL(0xd158), XIL(0x555555af3f90), XIL(0x7fffe15c1c23), XIL(0x7fffe1de517b), XIL(0), XIL(0x7fffffffd730), XIL(0xd158)} i = 1 last_pt = 12041 prev_modiff = 19844 prev_buffer = 0x7fffb61b20b0 #91 0x000055555583e13b in internal_condition_case (bfun=0x555555764dfd , handlers=XIL(0xa8), hfun=0x55555576427b ) at ../../emacs/src/eval.c:1618 val = XIL(0x15460) c = 0x7fffe2a52120 #92 0x00005555557649c3 in command_loop_2 (handlers=XIL(0xa8)) at ../../emacs/src/keyboard.c:1174 val = XIL(0x15460) #93 0x000055555583d581 in internal_catch (tag=XIL(0x15460), func=0x555555764999 , arg=XIL(0xa8)) at ../../emacs/src/eval.c:1297 val = XIL(0x5555557610c0) c = 0x7fffe2a51fe8 #94 0x0000555555764955 in command_loop () at ../../emacs/src/keyboard.c:1152 #95 0x0000555555763d1d in recursive_edit_1 () at ../../emacs/src/keyboard.c:760 count = { bytes = 32 } val = XIL(0x7fffffffd950) #96 0x0000555555763f49 in Frecursive_edit () at ../../emacs/src/keyboard.c:843 count = { --Type for more, q to quit, c to continue without paging-- bytes = 0 } buffer = XIL(0) #97 0x000055555575f83e in main (argc=1, argv=0x7fffffffdc08) at ../../emacs/src/emacs.c:2646 stack_bottom_variable = 0x7fffffffda40 old_argc = 1 dump_file = 0x0 no_loadup = false junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x0 original_pwd = 0x0 dump_mode = 0x0 skip_args = 0 temacs = 0x0 attempt_load_pdump = true only_version = false rlim = { rlim_cur = 10022912, rlim_max = 18446744073709551615 } lc_all = 0x0 sockfd = -1 module_assertions = false Lisp Backtrace: --Type for more, q to quit, c to continue without paging-- 0x93f3e2a0 PVEC_CLOSURE "mapcar" (0xffffa7a0) "let" (0xffffa9f0) "let" (0xffffac00) "reverse" (0xffffad30) "string-join" (0xffffaef0) "mini-echo-concat-segments" (0xffffb020) "let*" (0xffffb320) "if" (0xffffb490) "let*" (0xffffb680) "condition-case" (0xffffb900) "mini-echo-build-info" (0xffffba30) "overlay-put" (0xffffbca0) "let" (0xffffbec0) "while" (0xffffc080) "let" (0xffffc2a0) "if" (0xffffc440) "mini-echo-update" (0xffffc818) "apply" (0xffffc810) "timer-event-handler" (0xffffc9c8) In GNU Emacs 31.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version 1.18.2) of 2024-11-25 built on sky Repository revision: fad5e872ca05e45afa42ad5fc77b6890c051e4a6 Repository branch: scratch/igc Windowing system distributor 'The X.Org Foundation', version 11.0.12101014 System Description: Debian GNU/Linux trixie/sid Configured using: 'configure CPPFLAGS=-I/home/oscar/lib/mps/include LDFLAGS=-L/home/oscar/lib/mps/lib --with-native-compilation --with-tree-sitter --without-toolkit-scroll-bars --with-x-toolkit=lucid --with-modules --without-imagemagick --with-mps=yes --enable-checking=yes,glyphs --enable-check-lisp-object-type 'CFLAGS=-O0 -g3'' Configured features: CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBOTF LIBSELINUX LIBXML2 MODULES MPS NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG SECCOMP SOUND SQLITE3 THREADS TIFF TREE_SITTER WEBP X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB Important settings: value of $LANG: es_ES.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: fancy-compilation-mode: t global-git-commit-mode: t pulsar-global-mode: t pulsar-mode: t evil-owl-mode: t evil-paredit-mode: t evil-local-mode: t mini-echo-mode: t global-hide-mode-line-mode: t hide-mode-line-mode: t pdf-occur-global-minor-mode: t TeX-PDF-mode: t key-chord-mode: t paredit-mode: t display-fill-column-indicator-mode: t vertico-multiform-mode: t marginalia-mode: t vertico-mode: t window-highlight-mode: t which-key-mode: t global-anzu-mode: t anzu-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t window-divider-mode: t minibuffer-regexp-mode: t column-number-mode: t line-number-mode: t indent-tabs-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /home/oscar/elisp/singles/flx hides /home/oscar/.emacs.d/elpa/flx-20240205.356/flx /home/oscar/elisp/magit/lisp/magit-section hides /home/oscar/.emacs.d/elpa/magit-section-20241122.1431/magit-section /home/oscar/elisp/singles/avy hides /home/oscar/.emacs.d/elpa/avy-20241101.1357/avy /home/oscar/elisp/singles/which-key hides /home/oscar/dev/emacs/emacs/lisp/which-key /home/oscar/elisp/singles/transient hides /home/oscar/dev/emacs/emacs/lisp/transient /home/oscar/.emacs.d/elpa/ef-themes-1.9.0/theme-loaddefs hides /home/oscar/dev/emacs/emacs/lisp/theme-loaddefs Features: (solarized-selenized-dark-theme solarized-palettes solarized solarized-faces company-posframe posframe ispell shadow sort mail-extr emacsbug vertico-directory mule-util fussy meteo-radar flycheck lp0-ts-mode lp0-mode symbol-overlay company-ctags find-file company-fuzzy ht company aggressive-indent deft org-noter org-element org-persist xdg org-id org-element-ast inline avl-tree org-protocol org-capture org-refile org-crypt hl-todo etags-select etags fileloop generator xref fancy-compilation ffap orgit org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src sh-script smie executable ob-comint org-pcomplete org-list org-footnote org-faces org-entities noutline outline ob-emacs-lisp ob-core ob-eval org-cycle org-table ol org-fold org-fold-core org-keys oc org-loaddefs org-version org-compat org-macs magit-bookmark git-rebase magit-extras magit-sparse-checkout magit-gitignore magit-ediff ediff magit-subtree magit-patch magit-submodule magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit magit-repos magit-apply magit-wip magit-log magit-diff smerge-mode diff git-commit magit-core magit-autorevert autorevert filenotify magit-margin magit-transient magit-process with-editor shell pcomplete magit-mode transient magit-git magit-base which-func vc-git files-x vc-dispatcher magit-section benchmark cursor-sensor pulsar pulse evil-textobj-tree-sitter-core treesit evil-owl buffer-flip evil-paredit evil-anzu evil evil-keybindings evil-integration evil-maps evil-commands evil-digraphs reveal evil-jumps evil-command-window evil-types evil-search evil-ex evil-macros evil-repeat evil-states evil-core evil-common rect evil-vars mini-echo mini-echo-segments hide-mode-line wgrep grep ag vc-svn find-dired s dash pdf-occur ibuf-ext ibuffer ibuffer-loaddefs tablist tablist-filter semantic/wisent/comp semantic/wisent semantic/wisent/wisent semantic/util-modes semantic/util semantic semantic/tag semantic/lex semantic/fw mode-local find-func cedet pdf-isearch let-alist pdf-misc imenu pdf-tools cus-edit cus-load pdf-view bookmark jka-compr pdf-cache pdf-info tq pdf-util format-spec pdf-macs image-mode exif preview reporter desktop frameset latex latex-flymake flymake project compile comint ansi-osc ansi-color tex-ispell tex-style tex dbus xml crm texmathp auctex key-chord comp comp-cstr warnings comp-run comp-common cmake-mode paredit-menu paredit edmacro kmacro server yasnippet lisp-mnt cl-extra help-mode psvn wid-edit log-edit message sendmail yank-media puny rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log diff-mode track-changes pp elp ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init ediff-util dired dired-loaddefs display-fill-column-indicator vertico-multiform marginalia vertico flx-rs-core flx-rs flx window-highlight color face-remap nord-theme goto-chg avy rx ring highlight-parentheses ws-butler which-key diminish cl anzu easy-mmode thingatpt tmr pcase compat solar cal-dst cal-menu calendar cal-loaddefs finder-inf advice auctex-autoloads tex-site casual-calc-autoloads casual-lib-autoloads color-theme-sanityinc-tomorrow-autoloads company-posframe-autoloads company-autoloads consult-ag-autoloads consult-flycheck-autoloads consult-lsp-autoloads consult-org-roam-autoloads consult-project-extra-autoloads consult-todo-autoloads deadgrep-autoloads ef-themes-autoloads embark-consult-autoloads consult-autoloads embark-autoloads evil-textobj-tree-sitter-autoloads flutter-autoloads flycheck-autoloads fussy-autoloads flx-autoloads hl-todo-autoloads hotfuzz-autoloads hyperstitional-themes-autoloads lsp-dart-autoloads dart-mode-autoloads dap-mode-autoloads bui-autoloads lsp-docker-autoloads lsp-treemacs-autoloads lsp-ui-autoloads lsp-mode-autoloads f-autoloads marginalia-autoloads markdown-mode-autoloads org-roam-autoloads magit-section-autoloads emacsql-autoloads pdf-tools-autoloads pomm-autoloads alert-autoloads log4e-autoloads gntp-autoloads shackle-autoloads spinner-autoloads symbol-overlay-autoloads tablist-autoloads treemacs-autoloads cfrs-autoloads posframe-autoloads ht-autoloads hydra-autoloads lv-autoloads pfuture-autoloads ace-window-autoloads avy-autoloads s-autoloads info dash-autoloads vertico-autoloads vundo-autoloads wgrep-ag-autoloads wgrep-deadgrep-autoloads wgrep-autoloads yaml-autoloads yeetube-autoloads package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs icons password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo x-toolkit xinput2 x multi-tty move-toolbar make-network-process native-compile mps emacs) Memory information: ((conses 24 0 0) (symbols 56 0 0) (strings 40 0 0) (string-bytes 1 0) (vectors 24 0) (vector-slots 8 0 0) (floats 24 0 0) (intervals 64 0 0) (buffers 1000 0)) From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 27 01:55:42 2024 Received: (at 74547) by debbugs.gnu.org; 27 Nov 2024 06:55:42 +0000 Received: from localhost ([127.0.0.1]:58086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tGBxe-0004HZ-8L for submit@debbugs.gnu.org; Wed, 27 Nov 2024 01:55:42 -0500 Received: from mail-wr1-f53.google.com ([209.85.221.53]:58830) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tGBxa-0004HM-5u for 74547@debbugs.gnu.org; Wed, 27 Nov 2024 01:55:40 -0500 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-382442b7d9aso4884300f8f.1 for <74547@debbugs.gnu.org>; Tue, 26 Nov 2024 22:55:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732690477; x=1733295277; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=aywbBGowmFXoSrVUyV9sn2cY9CNjBBNGA0gGnLJmNZw=; b=GyVNdIG5Tdv4/tZdWkTwYAV4ZAJ3cLHpJRDOLo4PP7A1yVT9ULYdViSHfwG/aPQBSN W2++kQT0ohLPgX996+HcIeQeEuLM0lwcZT79utDHQg5NhsSY6JA4fpmzG3/zwy9FPDsd ztf+/Z5krLSam/V5YFidoVz/7xRSQF1nbjd1U7TpgKVSWo9obacpTAozAh3akf5tPN+M bpGul6U1ayhACpCt/RBdgZbiHvfAYofXriE9oCgPeA1NxWqq0XD/UJnWPeVbWjfaQ7U4 A61WfZQEvnTnNSdYQ68foMo8awXyotJ9iWLd1nNkee6DeWE1pLIhEVxld29ZPzv+0eKZ UUzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732690477; x=1733295277; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=aywbBGowmFXoSrVUyV9sn2cY9CNjBBNGA0gGnLJmNZw=; b=lmTfUJMAA7NcXJWmD8l+BNY6AfwfJC4s8pfdjLTKsiIwlshqFFFFuDn8893ixfwLuG r8jtug30c3GAj9+7Q/8KG0hpEDUOK5cemXBKL0I4LkqOHOu69R5IB2DqJGJIoSCX9Yvv fH/K0YRlkcE5bv82sFCyYocTYedHF9zNOvpN/CXtttGtrMak9LDs8WmBQB6ESClbACCq J4+QCnXp48KU0Qzqc9ABH122XizNlE/FCDMlFgWzHF83LYXPANHQmUXCMd7jzNY9gjaM 86rCUArEFUz2Doi9u+3mjb3XZvreZ4Y/IL24dqdqV73c8UmTPiAByY4W9i7PIa+Tc9cD +MNA== X-Gm-Message-State: AOJu0YyR1c4uXU1hdRaumqhbsnwz/2Hk1+w5YwQd4/K9QIFCT2EOmX7p 1lKk6KiV/XeYnJhSoDU0Sh7niRmASSczlagDWyA6V/p99CXdLr1M X-Gm-Gg: ASbGnct10CBenq2Eaun0/ATf7cF6L+ocXMzgBQTtQkTVE5vj+vdhFkoSr+BkiqxZFIh F5zSjv+GgdxVxZN0wtpwO98rljhdqUuycjlt9tYgmO/ef8Czho1tEzfpK6zay2aS+eQL1c0X+q9 ac2DlZaZXpkEwjcoHuaFEuAZ7BQUixpEtBZ3hL8ylIR3zXWwldzRF8gFqzEtMB6Z8OgHMA4VE9n txO67UahuQ4di1Km4pUFfYHipbhJ+XLwGLhLIAjZb7ii3pFoKK8nBQKIqm9LioJV6y0B+KxOwJ6 uUoXjNx2pGBiAt2+SfMVZkVzlxjLFHKu9gqXxJxsPNwEebJEWBPxA5+T+QM= X-Google-Smtp-Source: AGHT+IGnvbnccHV6ds09J81vpbUlW5+aGL0wusts8bo3D5MoriNVgTlq1VX5KGtNqttXoGla0LWkaA== X-Received: by 2002:a05:6000:2d01:b0:382:44e0:c5e9 with SMTP id ffacd0b85a97d-385c6ec02damr952527f8f.25.1732690477132; Tue, 26 Nov 2024 22:54:37 -0800 (PST) Received: from pro2 (p200300e0b70ba2005d51b4324b812ec2.dip0.t-ipconnect.de. [2003:e0:b70b:a200:5d51:b432:4b81:2ec2]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3825fbf2b29sm15395020f8f.107.2024.11.26.22.54.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Nov 2024 22:54:36 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: =?utf-8?Q?=C3=93scar?= Fuentes Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c In-Reply-To: <87serdu9m3.fsf@telefonica.net> (=?utf-8?Q?=22=C3=93scar?= Fuentes"'s message of "Tue, 26 Nov 2024 19:35:00 +0100") References: <87serdu9m3.fsf@telefonica.net> Date: Wed, 27 Nov 2024 07:54:35 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: 74547@debbugs.gnu.org, Pip Cet X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) =C3=93scar Fuentes writes: > While editing a .dart file with lsp-mode. Thanks Oscar. That's a difficult one. > #3 0x00005555559c1384 in mps_lib_assert_fail > (condition=3D0x555555a4a157 "size > 0", line=3D579, file=3D0x555555a4= 7782 "buffer.c") > at /home/oscar/dev/other/mps/code/mpsliban.c:87 > #4 BufferFill > #5 0x00005555559f2da0 in amcSegFix (seg=3D0x7fffb820d070, ss=3D0x7ffffff= f9fc0, refIO=3D0x7fffffff99d0) > trace =3D > #6 0x0000555555990b8c in _mps_fix2 (mps_ss=3D0x7fffffff9fc8, mps_ref_io= =3D0x7fffffff9a10) > res =3D > #7 0x0000555555903cac in fix_lisp_obj (ss=3D0x7fffffff9fc8, pobj=3D0x7ff= f89f0e000) > at ../../emacs/src/igc.c:998 > res =3D 32767 > client =3D 0x7fff93f2f7d0 > base =3D 0x7fff93f2f7d0 > p =3D 0x7fff89f0e000 > --Type for more, q to quit, c to continue without paging-- > word =3D 140735675561940 > tag =3D 4 > _ss =3D 0x7fffffff9fc8 > _mps_zs =3D 22 > _mps_ufs =3D 549755846664 > _mps_wt =3D 32768 > _mps_w =3D 133143986160 > #8 0x0000555555904160 in fix_array (ss=3D0x7fffffff9fc8, array=3D0x7fff8= 9f0e000, n=3D6) > at ../../emacs/src/igc.c:1233 > res =3D 30 > i =3D 0 > _ss =3D 0x7fffffff9fc8 > _mps_zs =3D 22 > _mps_ufs =3D 549755813896 > _mps_wt =3D > _mps_w =3D 133143986160 > #9 0x000055555590674b in fix_vectorlike (ss=3D0x7fffffff9fc8, v=3D0x7fff= 89f0dff0) > at ../../emacs/src/igc.c:1974 > res =3D 32767 > size =3D 6 > _ss =3D 0x7fffffff9fc8 > _mps_zs =3D 22 > _mps_ufs =3D 549755813896 > _mps_wt =3D > _mps_w =3D 133143986160 > #10 0x0000555555908d53 in fix_vector (ss=3D0x7fffffff9fc8, v=3D0x7fff89f0= dff0) > --Type for more, q to quit, c to continue without paging-- > at ../../emacs/src/igc.c:2646 > obj_ =3D 0x7fff89f0dff0 > res =3D 0 > _ss =3D 0x7fffffff9fc8 > _mps_zs =3D 22 > _mps_ufs =3D 549755813896 > _mps_wt =3D > _mps_w =3D 133143986160 > #11 0x00005555559061d4 in dflt_scan_obj > (ss=3D0x7fffffff9fc8, base_start=3D0x7fff89f0dff0, > base_limit=3D0x7fff89f0f000, closure=3D0x0) I've stripped the rest of the backtrace because it's probably not too relevant. What Emacs is doing here is allocate a cons, which triggers a GC step because the allocation point needs more memory. In this GC step, we scans a memory area containing a vector (or vectorlike) containing 6 elements. The first element is a string for which MPS_FIX1 says it needs to be passed to MPS_FIX2, but MPS_FIX2 aborts. I have no idea why that is. I've added Pip in CC, maybe he has ideas. > In GNU Emacs 31.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo > version 1.18.2) of 2024-11-25 built on sky > Repository revision: fad5e872ca05e45afa42ad5fc77b6890c051e4a6 > Repository branch: scratch/igc > Windowing system distributor 'The X.Org Foundation', version 11.0.12101014 > System Description: Debian GNU/Linux trixie/sid > > Configured using: > 'configure CPPFLAGS=3D-I/home/oscar/lib/mps/include > LDFLAGS=3D-L/home/oscar/lib/mps/lib --with-native-compilation > --with-tree-sitter --without-toolkit-scroll-bars --with-x-toolkit=3Dlucid > --with-modules --without-imagemagick --with-mps=3Dyes > --enable-checking=3Dyes,glyphs --enable-check-lisp-object-type > 'CFLAGS=3D-O0 -g3'' Could you please configure --with-mps=3Ddebug? That uses the debug version of MPS which is more picky, but slower. Also, --enable-checking=3Digc_debug is probably better. IIRC, that's not on by default, and we probably don't need the other checks. Maybe we some further hints that way. =20=20 From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 05:50:13 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 10:50:13 +0000 Received: from localhost ([127.0.0.1]:50405 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHhWm-0001N2-MV for submit@debbugs.gnu.org; Sun, 01 Dec 2024 05:50:13 -0500 Received: from mail-10628.protonmail.ch ([79.135.106.28]:33399) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHhWk-0001HZ-1Z for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 05:50:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1733050203; x=1733309403; bh=IPbVefVBMGlZCNi9P1vl3Uv7HfsowzOs+li9HDYZSMI=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=xfmj4OgX/3YdpUIOtlKJ1ZtZVjyqkhllTaQr4d32419+i+nvVuKiSAQLiWf/Fpqtb Go72pjADtx0JIR16IEiFtrHxlY19RkbbKEDQulGq0B6ndU8zKSyGQ0fM18Ooa+Hfvg D9qChsw1iDNLZUeRCFMDPZLNCfItqYHsVms5HO5FMuy97Zsn7pExQF/EOaKoHhoHV/ ubdNQ0SczRlaBT6d7ztVqv4QAViGl+TeJys6y7SrKbLkgEw2KjY6Udck3heAmM5lPw plqEOmF6r0EAiXkZBVZFFKcf/zq30laNq67CSBolw2As9pIRb1m03UBN8cH3qNGlU8 OZj8TaVFb+O3A== Date: Sun, 01 Dec 2024 10:49:57 +0000 To: =?utf-8?Q?Gerd_M=C3=B6llmann?= From: Pip Cet Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c Message-ID: <87cyibn0dz.fsf@protonmail.com> In-Reply-To: References: <87serdu9m3.fsf@telefonica.net> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: e537bccdf9de69e0957c191592e974d40b9ab659 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: 74547@debbugs.gnu.org, =?utf-8?Q?=C3=93scar_Fuentes?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > =C3=93scar Fuentes writes: > >> While editing a .dart file with lsp-mode. > > Thanks Oscar. That's a difficult one. I agree. >> #3 0x00005555559c1384 in mps_lib_assert_fail >> (condition=3D0x555555a4a157 "size > 0", line=3D579, file=3D0x555555a= 47782 "buffer.c") >> at /home/oscar/dev/other/mps/code/mpsliban.c:87 >> #4 BufferFill >> #5 0x00005555559f2da0 in amcSegFix (seg=3D0x7fffb820d070, ss=3D0x7fffff= ff9fc0, refIO=3D0x7fffffff99d0) >> trace =3D >> #6 0x0000555555990b8c in _mps_fix2 (mps_ss=3D0x7fffffff9fc8, mps_ref_io= =3D0x7fffffff9a10) >> res =3D >> #7 0x0000555555903cac in fix_lisp_obj (ss=3D0x7fffffff9fc8, pobj=3D0x7f= ff89f0e000) >> at ../../emacs/src/igc.c:998 >> res =3D 32767 >> client =3D 0x7fff93f2f7d0 >> base =3D 0x7fff93f2f7d0 >> p =3D 0x7fff89f0e000 >> --Type for more, q to quit, c to continue without paging-- >> word =3D 140735675561940 >> tag =3D 4 >> _ss =3D 0x7fffffff9fc8 >> _mps_zs =3D 22 >> _mps_ufs =3D 549755846664 >> _mps_wt =3D 32768 >> _mps_w =3D 133143986160 >> #8 0x0000555555904160 in fix_array (ss=3D0x7fffffff9fc8, array=3D0x7fff= 89f0e000, n=3D6) >> at ../../emacs/src/igc.c:1233 >> res =3D 30 >> i =3D 0 >> _ss =3D 0x7fffffff9fc8 >> _mps_zs =3D 22 >> _mps_ufs =3D 549755813896 >> _mps_wt =3D >> _mps_w =3D 133143986160 >> #9 0x000055555590674b in fix_vectorlike (ss=3D0x7fffffff9fc8, v=3D0x7ff= f89f0dff0) >> at ../../emacs/src/igc.c:1974 >> res =3D 32767 >> size =3D 6 >> _ss =3D 0x7fffffff9fc8 >> _mps_zs =3D 22 >> _mps_ufs =3D 549755813896 >> _mps_wt =3D >> _mps_w =3D 133143986160 >> #10 0x0000555555908d53 in fix_vector (ss=3D0x7fffffff9fc8, v=3D0x7fff89f= 0dff0) >> --Type for more, q to quit, c to continue without paging-- >> at ../../emacs/src/igc.c:2646 >> obj_ =3D 0x7fff89f0dff0 >> res =3D 0 >> _ss =3D 0x7fffffff9fc8 >> _mps_zs =3D 22 >> _mps_ufs =3D 549755813896 >> _mps_wt =3D >> _mps_w =3D 133143986160 >> #11 0x00005555559061d4 in dflt_scan_obj >> (ss=3D0x7fffffff9fc8, base_start=3D0x7fff89f0dff0, >> base_limit=3D0x7fff89f0f000, closure=3D0x0) > > I've stripped the rest of the backtrace because it's probably not > too relevant. > > What Emacs is doing here is allocate a cons, which triggers a GC step > because the allocation point needs more memory. In this GC step, we > scans a memory area containing a vector (or vectorlike) containing 6 > elements. The first element is a string for which MPS_FIX1 says it needs > to be passed to MPS_FIX2, but MPS_FIX2 aborts. > > I have no idea why that is. I've added Pip in CC, maybe he has ideas. I think the relevant part is that the IGC header of the object passed to _mps_fix2 is incorrect: it claims to have size 0. This is often the case when no traceable reference to an object was found in a previous GC pass and the memory has been reused for other purposes. So it seems there is a vector or pseudovector of size 6 that somehow attempts to resurrect a freed object (in the first slot). Unfortunately, 6 is the usual size for Lisp closures, so it's a very common allocation and we can't just breakpoint based on that size alone. Do you have a core dump, =C3=93scar? I think we need to look at the vector and see whether we can figure out how it was allocated or modified. I think it's unlikely this particular vector is a closure, FWIW, because the first slot of a closure vector is always a fixnum. Pip From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 07:07:05 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 12:07:06 +0000 Received: from localhost ([127.0.0.1]:50588 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHijB-0005Gf-Id for submit@debbugs.gnu.org; Sun, 01 Dec 2024 07:07:05 -0500 Received: from mail-wr1-f46.google.com ([209.85.221.46]:51331) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHij8-0005GS-PE for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 07:07:04 -0500 Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-385e0e224cbso1060962f8f.2 for <74547@debbugs.gnu.org>; Sun, 01 Dec 2024 04:07:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733054761; x=1733659561; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=rQVTJhv0E/bzhwX3cT63T8ppO1aP1gNqPgFIlWvWU5g=; b=MAEpiOOsZSPQ5CP8qsgqrjDVG4MQ1tzPtExWnfvx9BXshbUSKgpjPsp/YSHKlHv1o8 fSIzO4NaFnjtzwYdn7bzYijql7aVCLdorqqJ4RFBIrtOiiRHGe/Qwod7mKQT6VtSm64/ ZLOC3SW0B3rkDdRs9wZmWvDLlW9MTv3hqJUkcqZfPL+tTcr4w5PNJ6NThpuzEB/5aVf5 Do1D2VfMIiCMnABw626e7JZp6+Wh+V88muLffORkpPDAP0+K/rQv/x4CpncD5flHEsre EHskAoQo6O0Kjoj7ky6PgWS8AOMoCST8aw6+n1sFLN6AXhWz+FrA9phl7BYCF7zOVreZ dvFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733054761; x=1733659561; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=rQVTJhv0E/bzhwX3cT63T8ppO1aP1gNqPgFIlWvWU5g=; b=p6LKOiv1ONPt/8tv+xn11PWAs6aTUDEhum0g8vxEsH/bVk3OcX3hQOX7XUK3O+N0XU gLhN32hRS41yQGWKk7JSoW0xq72DBO2X1pUejlB0T1XTlDCIrOCT9AAD2Av44q0TekkV MZa5xqctfVpWfQNhFKfN+6x6jcU5x0gax9231aGjmWFId9EbLDPs81G99pjmSgIBSPwh Z9QLZshcDEqT4kvF765V5WMRbwVQK9iIfZVFny3UzbyRqocCpp4Fkz/eqkTxkn6k1Rkr +uBWixAJIbiVYvEb9FC+Nnc8zqYmFwwpLtr3mJ6USf99MHVwLe2hkMN9c6JM6BbjzQbw 8/ew== X-Forwarded-Encrypted: i=1; AJvYcCU5PSVelCIoGNO+VXDWm/4m1mfstjx5Xt8uDUiu/Nx0H0/yolzUThUTpvT8i9OxnBtiGOsUuA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Ywm1bHSinxjSx1ZYOMYTQ6N3rA2QHJhQYjv6RtEu9aMzokpWY5+ 0yTa9eA7KOhKWW6EKIQg5nbl66A5p0DhxbRUY0mMTxdoYVxZmb9KKGuU1A== X-Gm-Gg: ASbGnctkIGs0nGO8/0HYz4ZlkTLG0at90lOodHWtTKMU/SsQA/8pLVDYHdt7elJUkEu uZZPHrHWM3kQfVaUDMTvfQBrYTEG8/SqJ+eu4/Txfrvkyfy/d+BxwCps/BJK5YGiAx7UNc6mpz0 tArCMssMvnILZhEeKeydVz5SdtaUYh3b0SzCEV9MINMMRxNtOV4hFKEHzjpNIz8QfclQQCp7f9J 6ggM5jY1X7kwCuBzUboFmDSNKo5iprXXsL6L7bk1n6l7FOanC2O12SEfeVDdaEnYNpmnvOtxfkQ uATUFx+z7v5mIPAipwvrHO9Q9CjK2SKiwYUu0yvLBfGklUlfFECuUfZSvw== X-Google-Smtp-Source: AGHT+IGjf6R3WsUB7NIYs0HrIyy9AfKQ097MZLaQ0V2TRP98mCl4iEIRj2a8J5XydzS1OxfM6rx0xw== X-Received: by 2002:a05:6000:188e:b0:385:ee40:2d75 with SMTP id ffacd0b85a97d-385ee402fd5mr1018513f8f.20.1733054761479; Sun, 01 Dec 2024 04:06:01 -0800 (PST) Received: from pro2 (p200300e0b73e1e0079ddbf8403284f30.dip0.t-ipconnect.de. [2003:e0:b73e:1e00:79dd:bf84:328:4f30]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-385f13e4457sm545015f8f.35.2024.12.01.04.06.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Dec 2024 04:06:00 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Pip Cet Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c In-Reply-To: <87cyibn0dz.fsf@protonmail.com> (Pip Cet's message of "Sun, 01 Dec 2024 10:49:57 +0000") References: <87serdu9m3.fsf@telefonica.net> <87cyibn0dz.fsf@protonmail.com> Date: Sun, 01 Dec 2024 13:05:59 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: 74547@debbugs.gnu.org, =?utf-8?Q?=C3=93scar?= Fuentes X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > I think it's unlikely this particular vector is a closure, FWIW, because > the first slot of a closure vector is always a fixnum. I agree. I've now checked all the possible PVEC types, and the only ones that fit size 6 are normal vectors, closures, or records. I also don't believe that it's a closure because of the fixnum. And records (SQLite) seem a bit unlikely. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 07:18:46 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 12:18:47 +0000 Received: from localhost ([127.0.0.1]:50603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHiuU-0005pE-K7 for submit@debbugs.gnu.org; Sun, 01 Dec 2024 07:18:46 -0500 Received: from mail-wm1-f53.google.com ([209.85.128.53]:47500) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHiuR-0005ov-Eb for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 07:18:44 -0500 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-434a852bb6eso30130175e9.3 for <74547@debbugs.gnu.org>; Sun, 01 Dec 2024 04:18:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733055462; x=1733660262; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=bOZPpbeL+xocpx89goL+q8WtGzIFd2V88w1Iq3eX95g=; b=m/gxpIuE2FBfTJG1jwTFh9PDRVnpOdOQBaSw5jIq2Uj9jdG/sCBWHuNWrGZfw53iW+ 5xPc+VDgX0cLHh4TgZJmhWbVIUEvKj3PGt/hq50BuZ5sr6tr4WaQIMhuz+Z7mmJdWFPN juJIIETIVLGbvSkZ0SzkQcCy3cLk8ust15be3H2+zR+1xvWllnUGFF5tvhOQRrZb7FVD XZB7/jcmHkhZC+WLRtQz79s00xWFsYtih7MeAjXi6Tz7ktcC+B2eKbhWvmigam3Q8F0r Bm9SjDQyQcwBXDqn/plFZcfzbOFPRlBDK7yzhN5lLMXPAlDb3rQgVIAZ99CtcQw1GuQL JX6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733055462; x=1733660262; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=bOZPpbeL+xocpx89goL+q8WtGzIFd2V88w1Iq3eX95g=; b=VO7x6dCdFxNZVpemYmDPNXk/aumvjuEINIaZucK4Y1N3VzzLgB+MkE1ODv9EjUjiOz ZrBBue8AS7mr7nhIleWKe9pmlPMEK8VmNNrV2P07+oCb70gV03laYMp0CcJ1g+PEgAJj f6YCk9+CxDQbRdbupZ4rI9geVTQgQrp57w96RCSKN3orM1pH/YJoSXbxD7ZhoEdtzviZ pO91TRy+LZlh8zT/Nfw+x9tI6ugKqH1TDwJW+wC4XQUJo6fOQynykDJVWKuasALJgyKG fe5FSIhkANzXsfhpaRBIUGphmN6+6or859nIIDxl+ML2JSwmXzzrVCFdzmPcKCw4HTuY nXBg== X-Gm-Message-State: AOJu0YxnmeW9PrxtU7czu3fzGAWUSJ5DHu1CiZkSGspqcC+IHF/xL6RW lUwP/ip7rYcZUgUhqXeOx87jTjU1w9CXSZy0XXwLRDLDfrMUG3/r X-Gm-Gg: ASbGncuUj6xhPgE5cJPeMFwLaSMcfCOvNmsdQo/hy3XohsUZTJ3e666fc0Ml6x9qX83 N7XIYlaKpK7DrWRjF37qPjQ8s6+4H7mx3f9iCeRTmmKK+rsvxMp+PZv6hRKNrzv+xuRDCbBUnr2 oBBXy+AmN/79c/cvVt3yOOocIXVxL0rgOz6JkBD0qVcUaLjYYE9Yp0NnSZ86oVCf1Cx2qIiNLRv 5oOAkJ2aIk3CQmIjm5cI4urUhx/U2xG9aGcTgOouYaX4+56Q8SFLvyBUw/vK4ssT52Oa2uHu+OW fBCtaIjbSY5nqxDY7Ajm8pkqALETQ+y1u5+TbXF0LFIP/xTN/08f/7R5tA== X-Google-Smtp-Source: AGHT+IE/ovOic/pXi7ZzE5LKICUZVr41HW13EJshqntHD6GhfhgUq292uvRNAlJrMBlHkZK0cZldZQ== X-Received: by 2002:a05:600c:1ca8:b0:430:5887:c238 with SMTP id 5b1f17b1804b1-434a9dc3e9dmr161052405e9.11.1733055462341; Sun, 01 Dec 2024 04:17:42 -0800 (PST) Received: from pro2 (p200300e0b73e1e0079ddbf8403284f30.dip0.t-ipconnect.de. [2003:e0:b73e:1e00:79dd:bf84:328:4f30]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-434aa763aaesm146068335e9.14.2024.12.01.04.17.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Dec 2024 04:17:41 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Pip Cet Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llmann=22'?= =?utf-8?Q?s?= message of "Sun, 01 Dec 2024 13:05:59 +0100") References: <87serdu9m3.fsf@telefonica.net> <87cyibn0dz.fsf@protonmail.com> Date: Sun, 01 Dec 2024 13:17:39 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: 74547@debbugs.gnu.org, =?utf-8?Q?=C3=93scar?= Fuentes X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Pip Cet writes: > >> I think it's unlikely this particular vector is a closure, FWIW, because >> the first slot of a closure vector is always a fixnum. > > I agree. > > I've now checked all the possible PVEC types, and the only ones that fit > size 6 are normal vectors, closures, or records. I also don't believe > that it's a closure because of the fixnum. And records (SQLite) seem a > bit unlikely. Hm, reading Oscar's report again - he was using LSP. Maybe it's something in the parser. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 07:30:43 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 12:30:43 +0000 Received: from localhost ([127.0.0.1]:50629 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHj63-0006VY-AE for submit@debbugs.gnu.org; Sun, 01 Dec 2024 07:30:43 -0500 Received: from mail-40131.protonmail.ch ([185.70.40.131]:64647) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHj60-0006VE-TL for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 07:30:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1733056233; x=1733315433; bh=NrxlHS1FA8tXyADahpQLs3I8lvLHxezudz//LIlPDfI=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=Ca9Icbt7nQ0RLFW/pfgCdrgNQKuWqIWCGIewHEmOeB4V95HckFh9T1aqUMqOiWZjV I1E48ZohDIHKFFw94VuTs0Hc5LYux8nVisIVFhi5D0fvNr4LGlheMU3i0sjkAaOQIi Tn4fpqOJTKEZjxb7S408Mc/UbinwQs4/OlHZkU64OUqKCEyzcQLCjAEW4lpoUAYsrg 5tcg7X/KnRakxgfW51IDn2fhdZu4NoWvxLQNJIkDz+9N7HTr29uiIg28GAAlIP/NzR gY0xlUJ7iQnRqsHKiBUrdL4pqRydV/rpbHXBHDXEkdocZOCQUP1CwifDR192iKNEOC QHLZWeOTL9TOg== Date: Sun, 01 Dec 2024 12:30:28 +0000 To: =?utf-8?Q?Gerd_M=C3=B6llmann?= From: Pip Cet Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c Message-ID: <875xo3mvqh.fsf@protonmail.com> In-Reply-To: References: <87serdu9m3.fsf@telefonica.net> <87cyibn0dz.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: e92a0c24f1b9c0d59c0a1191f9200a914d564a25 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: 74547@debbugs.gnu.org, =?utf-8?Q?=C3=93scar_Fuentes?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Gerd M=C3=B6llmann writes: >> Pip Cet writes: >> >>> I think it's unlikely this particular vector is a closure, FWIW, becaus= e >>> the first slot of a closure vector is always a fixnum. >> >> I agree. >> >> I've now checked all the possible PVEC types, and the only ones that fit >> size 6 are normal vectors, closures, or records. I also don't believe >> that it's a closure because of the fixnum. And records (SQLite) seem a >> bit unlikely. > > Hm, reading Oscar's report again - he was using LSP. Maybe it's > something in the parser. You mean the JSON code? Because I'm just looking at that and it doesn't appear to be protecting its Lisp_Objects at all; but I'm not a hundred percent sure LSP uses the JSON code. In either case, we need to fix json.c, I'll try to do that next. Pip From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 07:40:20 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 12:40:20 +0000 Received: from localhost ([127.0.0.1]:50641 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHjFM-0006yt-FJ for submit@debbugs.gnu.org; Sun, 01 Dec 2024 07:40:20 -0500 Received: from mail-wm1-f53.google.com ([209.85.128.53]:45443) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHjFJ-0006uD-Qg for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 07:40:18 -0500 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-434aabd688fso20320015e9.3 for <74547@debbugs.gnu.org>; Sun, 01 Dec 2024 04:40:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733056752; x=1733661552; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Qq/TjlqRa+VKArBiBhWrbwG08g/6qnGUq2oq1LrC3nE=; b=nTByZTBWA0DbKJ9NByTsamjVnVMd5bMHftNbXC3fcGQdjT0JSKZC8t0PxWgoET52Eq BIhhKN1zNMDrYmsVOWk49QBa2tMQ0UU2brMXMNImkV5VoQoT7Y2duMAG0AVrEOD7IObq wV6jlV+infxjUrHlrLF62ZjjInx09clI+WJDpHMQPWkRDzKkd6b8Qo6Zh/XI2XwfK76L 6HUPiNUKjdRlO5WRJBDnvycRMMuhJjFLa+MkDIUqIaIVTOhBj2bdt95tCUU1WaX6tqhW QhoV5LfqLN3YFI3tT4CcySSkP6VW4b0t5+iavO1M36v8+/ANTtKJpkZ8j3Mp0R+Em4z5 JYxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733056752; x=1733661552; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Qq/TjlqRa+VKArBiBhWrbwG08g/6qnGUq2oq1LrC3nE=; b=jVxIjRJmhHzApLyyMvnrYSAEZm3zk4qTWcrEdOM9FlYTnuxJ29Ekb/f91EWRnY96Up rMr9ZqxaI//iemR0wyoJp8hCO7Stv3lI7vv/nXal85owmdA8M9Z4GCLMWQz6ERIojD2P FdkmcO7Vv2gK0WHBoIl0N5rTLcd/Vihg+IB6tYqSbky48GsD4RTI3lHxxGwrfDVRLx7u g68tiSIxSL/bFMy+2oSTI8b5KmEbWmaAtxEEObekAwl2+KETSRssGvC23e/hKxhjQWJD XbUU4+bwXwWbR6f7OVKOEG40xw6E9n3kEJSqlpHqGh3Fp/W7yo1ttn2lkNSpuHAzNlEg x2FA== X-Gm-Message-State: AOJu0Yzek6XKJRpi57CTaleYhi8Uc8rYWeIonvKyg06XmDM1YfIRVxiM wL6HqSBwwT+gWZCkoErYN1XAwa6KwSF/P/7qwAe/3JSlBwWF1gIM X-Gm-Gg: ASbGncudKloS1lAZgZ/QddNuozXqcJyzcBrYADbGLc/twp/UuMsXV/jofSfN4gYlrTc rd874xWCD5yqYB29M2lD/MU4LJ62OGDGZGkNvpyXHIAaBcR1JNBqTXoz4gyWi03p0jSU9T1oGi/ 3m8pAObNbpQm+avipWI5OeWEx2RrK6+Gdi6+EoLTwXzb8tOMIE5Ig+4SaIOsW/R+7uOHgTsOjcO MU03UI0pf2x87uVmQ833dAoZVyj+ynNwla25j9ofjRfmAKb+3mloF2kYX9S7SOdddfs4a0GjyWW Vd/2XkwAX18EFqInvJWVt19Tua7Yw9Fy+XvRKM+f7OWv3lfvT8qeDvEC9g== X-Google-Smtp-Source: AGHT+IEvEHJgxbyX5nzioxWnHQWUOIfFOUPoZD0JLMvPojYnSBLv1CGNpcll54UIyz+GuNmb1ae4SQ== X-Received: by 2002:a5d:6d08:0:b0:382:43ab:7d68 with SMTP id ffacd0b85a97d-385c6eb7a52mr16260264f8f.12.1733056751946; Sun, 01 Dec 2024 04:39:11 -0800 (PST) Received: from pro2 (p200300e0b73e1e0079ddbf8403284f30.dip0.t-ipconnect.de. [2003:e0:b73e:1e00:79dd:bf84:328:4f30]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-434aa74f1f6sm150280725e9.8.2024.12.01.04.39.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Dec 2024 04:39:10 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Pip Cet Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c In-Reply-To: <875xo3mvqh.fsf@protonmail.com> (Pip Cet's message of "Sun, 01 Dec 2024 12:30:28 +0000") References: <87serdu9m3.fsf@telefonica.net> <87cyibn0dz.fsf@protonmail.com> <875xo3mvqh.fsf@protonmail.com> Date: Sun, 01 Dec 2024 13:39:09 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: 74547@debbugs.gnu.org, =?utf-8?Q?=C3=93scar?= Fuentes X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > Gerd M=C3=B6llmann writes: > >> Gerd M=C3=B6llmann writes: >>> Pip Cet writes: >>> >>>> I think it's unlikely this particular vector is a closure, FWIW, becau= se >>>> the first slot of a closure vector is always a fixnum. >>> >>> I agree. >>> >>> I've now checked all the possible PVEC types, and the only ones that fit >>> size 6 are normal vectors, closures, or records. I also don't believe >>> that it's a closure because of the fixnum. And records (SQLite) seem a >>> bit unlikely. >> >> Hm, reading Oscar's report again - he was using LSP. Maybe it's >> something in the parser. > > You mean the JSON code? Because I'm just looking at that and it doesn't > appear to be protecting its Lisp_Objects at all; but I'm not a hundred > percent sure LSP uses the JSON code. Yes, exactly, json.c. First thing I saw when searching for xfree static void json_parser_done (void *parser) { struct json_parser *p =3D (struct json_parser *) parser; if (p->object_workspace !=3D p->internal_object_workspace) xfree (p->object_workspace); That at least needs an explanation. I would have expected it to be allocated as root. > > In either case, we need to fix json.c, I'll try to do that next. > > Pip Thanks! From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 07:57:17 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 12:57:18 +0000 Received: from localhost ([127.0.0.1]:50662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHjVl-0007o8-1k for submit@debbugs.gnu.org; Sun, 01 Dec 2024 07:57:17 -0500 Received: from mail-10629.protonmail.ch ([79.135.106.29]:22779) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHjVi-0007nq-Kb for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 07:57:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1733057827; x=1733317027; bh=wA+bbLq4Lfe6Rc3R9EWyYND548P8sKZOKAdjRxqQ7vk=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=sikqlcTwDwQ3jG6DKD2JkQZChNdzPFwEIWvmeCtHE0D7S+TK7dhx+UWpSjpklzU4b 5353YnNlgXsPkBwtQbUMsqD5KdD6Z8zthgJ1mU55vt3/rVzpqcr1p22hlF6oqZLsBy 75U3d9K3vThR3vMYfIPp8HyWuaEMNIp3dwSTnUkMPkZVw6dWkHuutocKanINdUqBR/ kk2q0E1vbZ+6aSFG4laSBtT7e8tC7IEPk+jWVcS/ba46hHCpLwQnOAJly+tUEohWYv JtTo1A/9zOp3A6FSe55Lml+V9kXKpqOFCC1F4XfKb+HHGyMENeS9Csy8zaIL33R0Om +54y1QWcsQ/GA== Date: Sun, 01 Dec 2024 12:57:04 +0000 To: =?utf-8?Q?Gerd_M=C3=B6llmann?= From: Pip Cet Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c Message-ID: <871pyrmui4.fsf@protonmail.com> In-Reply-To: References: <87serdu9m3.fsf@telefonica.net> <87cyibn0dz.fsf@protonmail.com> <875xo3mvqh.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: bd0ffe0075a04b40a1874584e6a393fa70e5ad96 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: 74547@debbugs.gnu.org, =?utf-8?Q?=C3=93scar_Fuentes?= , geza.herman@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Pip Cet writes: > Yes, exactly, json.c. First thing I saw when searching for xfree > > static void > json_parser_done (void *parser) > { > struct json_parser *p =3D (struct json_parser *) parser; > if (p->object_workspace !=3D p->internal_object_workspace) > xfree (p->object_workspace); > > That at least needs an explanation. I would have expected it to be > allocated as root. Well, the explanation is this comment: /* Lisp_Objects are collected in this area during object/array parsing. To avoid allocations, initially internal_object_workspace is used. If it runs out of space then we switch to allocated space. Important note: with this design, GC must not run during JSON parsing, otherwise Lisp_Objects in the workspace may get incorrectly collected. */ Obviously, we cannot make any such guarantees when MPS is in use. (I don't think we can make the guarantee when MPS is not in use, but I'm not totally certain; we certainly allocate strings while parsing JSON, which is sufficient to trigger GC in the MPS case). Note that the json_parser object itself is fine (it's allocated on the stack, thus marked ambiguously), it's only in the case that we create more than 64 Lisp_Object values when parsing a single JSON document that we end up with untraced references on the heap. I don't know whether it's likely that that was what happened to Oscar. My gut feeling is 64 objects would be easily reached by LSP messages, but I'd need more time to test. Anyway, here's a patch which might help: commit c175744f2172ba3405ae98eb3575b2bf4adadfa4 Author: Pip Cet Date: Sun Dec 1 12:46:08 2024 +0000 Ensure JSON parser allocations are traced (bug#74547) =20 * src/json.c (json_parser_done): (json_make_object_workspace_for_slow_path): Use IGC-aware allocations. diff --git a/src/json.c b/src/json.c index eb446f5c221..900fbcbb41a 100644 --- a/src/json.c +++ b/src/json.c @@ -807,7 +807,11 @@ json_parser_done (void *parser) { struct json_parser *p =3D (struct json_parser *) parser; if (p->object_workspace !=3D p->internal_object_workspace) +#ifdef HAVE_MPS + igc_xfree (p->object_workspace); +#else xfree (p->object_workspace); +#endif if (p->byte_workspace !=3D p->internal_byte_workspace) xfree (p->byte_workspace); } @@ -833,17 +837,31 @@ json_make_object_workspace_for_slow_path (struct json= _parser *parser, if (parser->object_workspace_size =3D=3D JSON_PARSER_INTERNAL_OBJECT_WORKSPACE_SIZE) { +#ifndef HAVE_MPS new_workspace_ptr =09=3D xnmalloc (new_workspace_size, sizeof (Lisp_Object)); +#else + new_workspace_ptr +=09=3D igc_xalloc_lisp_objs_exact (new_workspace_size); +#endif memcpy (new_workspace_ptr, parser->object_workspace, =09 (sizeof (Lisp_Object) =09 * parser->object_workspace_current)); } else { +#ifndef HAVE_MPS new_workspace_ptr =09=3D xnrealloc (parser->object_workspace, new_workspace_size, =09=09 sizeof (Lisp_Object)); +#else + new_workspace_ptr +=09=3D igc_xalloc_lisp_objs_exact (new_workspace_size); + memcpy (new_workspace_ptr, parser->object_workspace, +=09 (sizeof (Lisp_Object) +=09 * parser->object_workspace_current)); + igc_xfree (parser->object_workspace); +#endif } =20 parser->object_workspace =3D new_workspace_ptr; From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 08:18:49 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 13:18:49 +0000 Received: from localhost ([127.0.0.1]:50692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHjqa-0000R9-Lx for submit@debbugs.gnu.org; Sun, 01 Dec 2024 08:18:48 -0500 Received: from relayout02-q01.e.movistar.es ([86.109.101.151]:15857) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHjqW-0000Qk-Oj for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 08:18:47 -0500 Received: from relayout02-redir.e.movistar.es (relayout02-redir.e.movistar.es [86.109.101.202]) by relayout02-out.e.movistar.es (Postfix) with ESMTP id 4Y1SCx2JPCzhYmd; Sun, 1 Dec 2024 14:18:37 +0100 (CET) Received: from sky (125.red-83-37-187.dynamicip.rima-tde.net [83.37.187.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout02.e.movistar.es (Postfix) with ESMTPSA id 4Y1SCs6l1mzdbLW; Sun, 1 Dec 2024 14:18:32 +0100 (CET) From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Gerd =?utf-8?Q?M=C3=B6llmann?= Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llmann=22'?= =?utf-8?Q?s?= message of "Sun, 01 Dec 2024 13:17:39 +0100") References: <87serdu9m3.fsf@telefonica.net> <87cyibn0dz.fsf@protonmail.com> Date: Sun, 01 Dec 2024 14:18:32 +0100 Message-ID: <87r06rmthz.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-TnetOut-Country: IP: 83.37.187.125 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout02 X-TnetOut-MsgID: 4Y1SCs6l1mzdbLW.A91FC X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: oscarfv@telefonica.net X-TnetOut-Watermark: 1733663916.98766@QjN85Lf2P4QKVD7+CAwToA X-Spam-Status: No X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74547 Cc: Pip Cet , 74547@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Gerd M=C3=B6llmann writes: > Hm, reading Oscar's report again - he was using LSP. Maybe it's > something in the parser. The three times that I caugth the crash with the debugger mini-echo [1] was in the Elisp backtrace. Maybe lsp-mode does something that upsets the garbage collector and it surfaces when mini-echo executes. Just now tried for some minutes with mini-echo active and without lsp-mode and no crash, but maybe I was unlucky. lsp-mode is heavy on GC and it is difficult to replicate that. As for the core dump, I have two, but I'm not sure if they contain sensitive info. Usually the crash takes a few minutes of work to happen. I can execute Emacs under gdb on a controlled environment and then answer your requests, no problem with having it open for several days. Or send you the core dump, if it is more useful. 1. https://github.com/liuyinz/mini-echo.el From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 08:31:48 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 13:31:48 +0000 Received: from localhost ([127.0.0.1]:50710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHk3A-0001AO-5M for submit@debbugs.gnu.org; Sun, 01 Dec 2024 08:31:48 -0500 Received: from mail-wm1-f43.google.com ([209.85.128.43]:54437) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHk37-0001A2-A9 for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 08:31:46 -0500 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-434ab114753so27692205e9.0 for <74547@debbugs.gnu.org>; Sun, 01 Dec 2024 05:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733059839; x=1733664639; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=7pSFgKKhQyeaKJWxkO1KU7UkGRUq8TiHilyMTiENkg8=; b=SJwoBf78tXcKsMqrcoMj1d92Cru3s7G5S6PefnE4d5hULP1AmOP6mAG4ThwnhIM123 BuzQh1uipkI2h//cYvqc/77v9oYCnqHvsplftHWm7zLD/hvlEeCMkuSGHD4raqQWfmmu Ir8bBZSUiWPJuihHT4+zdkGoVYewAnaimJEOZy2aKok/4bVCs5u8SCReLXhTQ2UF5Z4B t/zjGLjmCmxfPYrjktIrHSp7H/vjzyXq7yAI2S/bvXqEBapliW84LhyFqunMF+9yjU08 VScT1IYT+Veel7GFraiCPJDmnxdpuxbYYhCsRjd5hGP17dmC1BGIzdsqHTQX7OWYes+4 ZIsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733059839; x=1733664639; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=7pSFgKKhQyeaKJWxkO1KU7UkGRUq8TiHilyMTiENkg8=; b=vC9TOuP0OWMaELPCcaxjc+my/5q/zKB5cRIb0BmFAO20q1i67AN8jZkRBteItUfpV0 1K+uJ0eROXmNhDVxZkvuFouzZqkOrL5ycy5jyTNscp8gpB6nVIewQXAsw5uV+ZUrMCL5 n5Q8f6o6u/ojYj8sNeUeENtcW9It78A8cfkK28ihPgdhQ6rscASa2vNAFLc68nVkJRbh Q+rQbSupd2G/f97X3msT1AIGZPw9OeJbGd1on6H5nzMdoWn9qAD4oeWPu4P+0W24G+cv ZIBzL62bBqM5tWaeAGJ7jB+xTbKQ/tdnqJA+EFVLBFfSKYD8KZiaLavrInm7CmoBYM+N gvRQ== X-Gm-Message-State: AOJu0Yx+4cNYJt9nITrULofa2YnSlKuQyUD9qRFhSpHeu994WoduB18+ Lm9/FM0vb4TtyCbFLC56exdJkFEfNQyZ3IFiNEH6PIjc7hkjRpR+ X-Gm-Gg: ASbGncvwkziGMppowH3tFksXYgFUWoXRwuVULNFHFw0WAuiBR0Lj1Ey4iawGpZHcYYE 796f28XgnCZq30kGN2kNGvnTU/TqLwrKx43yT01MxhZWl3ghVqTACe5h2qvFJ2pq2W5p6wKQ+jN 5YS1NM7MgkeCmkux3sSWG9oBTpzUaxSJMO1ZvjJzMbuKdjQ+ADGyWC1Ubk2jO8sVorN5NPJiBhg ssZYs/Ik9Zvrr203Q0YiwJuNJqwXwXpFGVCNzxI/e1qkLChurq5lL24fTuQzzK8nPIvatSeo04W YDhtTMhKZFB+KD80fkpUPMuw9QvfnO69GJKa8jNANohKfl5pt12AQWQ4zg== X-Google-Smtp-Source: AGHT+IGkT9VQaEB8tT0bM7KfNqEYjKywCODBTj339WeceljuJkeqnlGvrYJ4tuJJnrRHEQmdcocGzw== X-Received: by 2002:a05:600c:35ce:b0:434:a6af:d333 with SMTP id 5b1f17b1804b1-434a9dd00eamr188105645e9.16.1733059839368; Sun, 01 Dec 2024 05:30:39 -0800 (PST) Received: from pro2 (p200300e0b73e1e0079ddbf8403284f30.dip0.t-ipconnect.de. [2003:e0:b73e:1e00:79dd:bf84:328:4f30]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-434aa7e4c89sm147040045e9.41.2024.12.01.05.30.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Dec 2024 05:30:39 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Pip Cet Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c In-Reply-To: <871pyrmui4.fsf@protonmail.com> (Pip Cet's message of "Sun, 01 Dec 2024 12:57:04 +0000") References: <87serdu9m3.fsf@telefonica.net> <87cyibn0dz.fsf@protonmail.com> <875xo3mvqh.fsf@protonmail.com> <871pyrmui4.fsf@protonmail.com> Date: Sun, 01 Dec 2024 14:30:37 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: 74547@debbugs.gnu.org, =?utf-8?Q?=C3=93scar?= Fuentes , geza.herman@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > Gerd M=C3=B6llmann writes: >> Pip Cet writes: >> Yes, exactly, json.c. First thing I saw when searching for xfree >> >> static void >> json_parser_done (void *parser) >> { >> struct json_parser *p =3D (struct json_parser *) parser; >> if (p->object_workspace !=3D p->internal_object_workspace) >> xfree (p->object_workspace); >> >> That at least needs an explanation. I would have expected it to be >> allocated as root. > > Well, the explanation is this comment: > > /* Lisp_Objects are collected in this area during object/array > parsing. To avoid allocations, initially > internal_object_workspace is used. If it runs out of space then > we switch to allocated space. Important note: with this design, > GC must not run during JSON parsing, otherwise Lisp_Objects in > the workspace may get incorrectly collected. */ That explains it, indeed :-(. > > Obviously, we cannot make any such guarantees when MPS is in use. (I > don't think we can make the guarantee when MPS is not in use, but I'm > not totally certain; we certainly allocate strings while parsing JSON, > which is sufficient to trigger GC in the MPS case). If json.c calls something like maybe_quit, which I's expect it must, then GC can indeed happen. See bug#56108 for an example in the regexp code found with ASAN. It's not as risky in the old code as with concurrent GC, but anyway. > > Note that the json_parser object itself is fine (it's allocated on the > stack, thus marked ambiguously), it's only in the case that we create > more than 64 Lisp_Object values when parsing a single JSON document that > we end up with untraced references on the heap. > > I don't know whether it's likely that that was what happened to Oscar. > My gut feeling is 64 objects would be easily reached by LSP messages, > but I'd need more time to test. > > Anyway, here's a patch which might help: > > commit c175744f2172ba3405ae98eb3575b2bf4adadfa4 > Author: Pip Cet > Date: Sun Dec 1 12:46:08 2024 +0000 Very nide, thank you! From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 08:45:32 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 13:45:32 +0000 Received: from localhost ([127.0.0.1]:50725 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHkGR-0001s5-NI for submit@debbugs.gnu.org; Sun, 01 Dec 2024 08:45:32 -0500 Received: from mail-wm1-f48.google.com ([209.85.128.48]:42170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHkGP-0001rp-FN for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 08:45:30 -0500 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-434a8b94fb5so19509365e9.0 for <74547@debbugs.gnu.org>; Sun, 01 Dec 2024 05:45:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733060668; x=1733665468; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=obdCSdop9SBARRiRKl97oGGTDJmjTbBnuxFfV4doO30=; b=AQRHdadz1YfXF7RQkqR+57dRMyW2xmXi0LTvTi3+hp/Qa4E2kUWbY1bnvoKYfe+2vG MmRmkzySI7i2bJ1t9Y3lxdZm+7Yi/HJU/AOga2K9bYA343Ffpqu0RdGYvapFR4zG52zT 4KpHk12g+HmLW/6+h2+bQxHcQGYQMi83EC1zjbd7MDI7DjkmKL9F1DztuzMW8lD0q8aS Jm44MjEp+AmdiYbDsmujD4xniXbskrkjU8T88NKiubxaUWbtbp5kVpNTLC6voPHiv7J7 ZBb2fcLahI94ioTfdHufBuqX3n7y/iL2/ogVB3w3OWPtFVLMAASixV5+Kt5f/AboFuAq zDoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733060668; x=1733665468; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=obdCSdop9SBARRiRKl97oGGTDJmjTbBnuxFfV4doO30=; b=w52m/XtyXn6u5Ct+w3fYg3S1qbnjdRO9yQnIx3Nnfv4kWq55bJOqZaFt/aDsowrupB A48/rgk086kgJ2rQkRT5j00PCRtUUEjNNIrQBQVk0zGfB2iYs5PQGgNI3CSbqCdFyehz h06YySiHmuuaW70oNQdJPLW+d9FBX+RIMok7xeOzTqvf0jO10A+mxJgR9Z8Im3oY0PIE +bkt3vvw30NzpqDRCpLEB7B/ZOOaG8ZD+QNEmp0Jx15ue6o66so4sxQGm3I7BaTph7x5 rP94Vd70YOsN3h+8WqekvaLPvCdNR6f4Ebih3weMViuoihpjXQQMo2gd2yPmfrcftrO+ XmVg== X-Forwarded-Encrypted: i=1; AJvYcCWooiqHOHtIXQcVggwpGvDQSxSlc9grm5aWtBHHtyl9gdBmA94tHMp/8VAyqtr9AsWCIxigfg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwyrtPTSu4ri1tNvqXxojtt8iA/+lAi/jnn66hnfflGoYpmXtQ/ uRcX2WFTWXVhHSFUjAu13fflggR6fsZqAKDGsMaRRdUek4S3N5balfYzXA== X-Gm-Gg: ASbGncvZNep/IBY9f+XIF4GLbVBd4M49EgfmMwaMmW3M9nP8KWJzVxzE3LYoG+7qp/G SIAD+6LzpirDPKM8AvfsGizq85mdOCb3nFYvkWZSdFeMZKO+/ZmPDQ5c8NROO7AM+TcNhZMUD75 /L2BlVYQtxOHYFubr4ZOolYfUFo/ze+KFm67YIH+iC0wffjswwDqEHT0HaKf4Pc9tsME+ViKIMK UbMyKJ4JnbyJ/yRX9tAW7wAggOj3x8hlxStRYJu8bf/U3gbBlBCYG6V2bX2HYvri8qKNAh6MVAj V/4E8QRqoDJEY93hRFnU7kgEmmTeQ7yvvf56IsRIDad4RsYN5V4or6R7ag== X-Google-Smtp-Source: AGHT+IHQUafKOXF4XrCco87vclrmmifwQmZa/ynADxfhKZ5NM/5PrXpetxE03aOpCKoJBgR7EklyIg== X-Received: by 2002:a05:600c:198e:b0:434:9cf6:a2a5 with SMTP id 5b1f17b1804b1-434afb9ecc7mr126973705e9.8.1733060667847; Sun, 01 Dec 2024 05:44:27 -0800 (PST) Received: from pro2 (p200300e0b73e1e0079ddbf8403284f30.dip0.t-ipconnect.de. [2003:e0:b73e:1e00:79dd:bf84:328:4f30]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-434aa74f18bsm152364315e9.4.2024.12.01.05.44.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Dec 2024 05:44:26 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: =?utf-8?Q?=C3=93scar?= Fuentes Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c In-Reply-To: <87r06rmthz.fsf@telefonica.net> (=?utf-8?Q?=22=C3=93scar?= Fuentes"'s message of "Sun, 01 Dec 2024 14:18:32 +0100") References: <87serdu9m3.fsf@telefonica.net> <87cyibn0dz.fsf@protonmail.com> <87r06rmthz.fsf@telefonica.net> Date: Sun, 01 Dec 2024 14:44:24 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: Pip Cet , 74547@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) =C3=93scar Fuentes writes: > Gerd M=C3=B6llmann writes: > >> Hm, reading Oscar's report again - he was using LSP. Maybe it's >> something in the parser. > > The three times that I caugth the crash with the debugger mini-echo [1] > was in the Elisp backtrace. Maybe lsp-mode does something that upsets > the garbage collector and it surfaces when mini-echo executes. Just now > tried for some minutes with mini-echo active and without lsp-mode and no > crash, but maybe I was unlucky. lsp-mode is heavy on GC and it is > difficult to replicate that. Yeah, It's pretty difficult to find the exact time when something goes wrong because the allocation points have some memory reserved, so that it's not exactly predictable when a GC step happens. But I find Pip's change very promising. It's fixing something that cleqrly cannot work with MPS. Could you please try it (it doesn't seem to be pushed yet.) From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 09:58:26 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 14:58:26 +0000 Received: from localhost ([127.0.0.1]:52610 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHlOz-00066v-0v for submit@debbugs.gnu.org; Sun, 01 Dec 2024 09:58:25 -0500 Received: from mail-10631.protonmail.ch ([79.135.106.31]:55763) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHlOv-00066W-HS for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 09:58:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1733065094; x=1733324294; bh=EqYXTOrsJ3uxI3JRZ18CF8/j08kVI77dwfd54W2ccf4=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=XPcB9lwCGHMts0teIP2bvGuNMF/cQnhxjy8TpwuK+PE5NKHIxfc+tTIDX1Ov8a9NO Et3su0NQa+RYajH9Uygyu2KQLU0EC0MgI8vOfngSb/lFzlF16evFONMlPi136qKZFx TC55/pIWKTYOuMUcMy4WU/88ScznXr7wShbJFRLN8Vg4htYFoTesrw3iIPrpx4lH8q sXuiO/yC9qvFvJeCd3vmgWAR/HeZcgxgHk4slThwNRAdjbkPW++aTttnLps+nJfXx8 vr45tCr43TaQLHg7/R4KvHlqXVL4mDa40iEXKizebmY92Ut3IEKQCs8VyNfksLzNct HdHF9yddaZrMg== Date: Sun, 01 Dec 2024 14:58:10 +0000 To: =?utf-8?Q?Gerd_M=C3=B6llmann?= From: Pip Cet Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c Message-ID: <87wmgjlabu.fsf@protonmail.com> In-Reply-To: References: <87serdu9m3.fsf@telefonica.net> <87cyibn0dz.fsf@protonmail.com> <875xo3mvqh.fsf@protonmail.com> <871pyrmui4.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: a08e1bb9f9dcc154f958aee35f6dfb42ee723016 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: 74547@debbugs.gnu.org, =?utf-8?Q?=C3=93scar_Fuentes?= , geza.herman@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Pip Cet writes: >> Gerd M=C3=B6llmann writes: >>> Pip Cet writes: >>> Yes, exactly, json.c. First thing I saw when searching for xfree >>> >>> static void >>> json_parser_done (void *parser) >>> { >>> struct json_parser *p =3D (struct json_parser *) parser; >>> if (p->object_workspace !=3D p->internal_object_workspace) >>> xfree (p->object_workspace); >>> >>> That at least needs an explanation. I would have expected it to be >>> allocated as root. >> >> Well, the explanation is this comment: >> >> /* Lisp_Objects are collected in this area during object/array >> parsing. To avoid allocations, initially >> internal_object_workspace is used. If it runs out of space then >> we switch to allocated space. Important note: with this design, >> GC must not run during JSON parsing, otherwise Lisp_Objects in >> the workspace may get incorrectly collected. */ > > That explains it, indeed :-(. Just to be clear, I think the mixed heap/stack allocation is the right thing to do here, but we need to let both garbage collectors know about the Lisp_Objects we allocated. I think the best way to do that is to use a Lisp_Vector when we run out of stack space. That way, we don't have to worry about forgetting to GC it, and we can use standard functions rather than rolling our own. >> Obviously, we cannot make any such guarantees when MPS is in use. (I >> don't think we can make the guarantee when MPS is not in use, but I'm >> not totally certain; we certainly allocate strings while parsing JSON, >> which is sufficient to trigger GC in the MPS case). > > If json.c calls something like maybe_quit, which I's expect it must, > then GC can indeed happen. See bug#56108 for an example in the regexp > code found with ASAN. It's not as risky in the old code as with > concurrent GC, but anyway. There's a rarely_quit in json_parse_array, which, AFAICS, always triggers in the first loop iteration (when i =3D=3D 0), but probably never reaches 65536 for the second trigger. My proposal is to modify json.c so it uses a lisp vector if more than 64 objects are needed, and to remove the home-grown symset hash set, replacing it by a standard hash table. Note that the symset is only used to detect duplicate JSON keys. When such duplication is detected, we simply ignore the second plist entry. (I think it would be better to throw an error, but the documentation disagrees.) So here's the patch with the old behavior, where (json-serialize '(a "test" a "ignored")) doesn't throw an error and simply returns "{\"a\":\"test\"}" commit 85fbd342d3b4a8afabe8078e19be9b45fe3e20d2 Author: Pip Cet Date: Sun Dec 1 12:46:08 2024 +0000 Use standard Lisp objects in json.c (bug#74547) =20 * src/json.c (json_out_t): Make the symset table a Lisp_Object. (symset_t): (pop_symset): (cleanup_symset_tables): (symset_hash): (symset_expand): (symset_size): Remove. (make_symset_table): Use an ordinary hash table for the symset. (push_symset): Don't return a value. (symset_add): Use ordinary hash table accessors. (cleanup_json_out): Remove. (json_out_object_cons): Use ordinary hash table for symsets. (json_serialize): (json_parser_init): (json_parser_done): Adjust to use ordinary hash table code. (json_make_object_workspace_for_slow_path): Use an ordinary vector for the workspace. (json_parse_array): Avoid calling rarely_quit(0) (json_parser_done): Remove manual memory management. diff --git a/src/json.c b/src/json.c index eb446f5c221..0e17b893087 100644 --- a/src/json.c +++ b/src/json.c @@ -28,7 +28,6 @@ Copyright (C) 2017-2024 Free Software Foundation, Inc. #include "lisp.h" #include "buffer.h" #include "coding.h" -#include "igc.h" =20 enum json_object_type { @@ -111,161 +110,9 @@ json_parse_args (ptrdiff_t nargs, Lisp_Object *args, ptrdiff_t chars_delta; /* size - {number of characters in buf} */ =20 int maxdepth; - struct symset_tbl *ss_table;=09/* table used by containing object */ struct json_configuration conf; } json_out_t; =20 -/* Set of symbols. */ -typedef struct -{ - ptrdiff_t count;=09=09/* symbols in table */ - int bits;=09=09=09/* log2(table size) */ - struct symset_tbl *table;=09/* heap-allocated table */ -} symset_t; - -struct symset_tbl -{ - /* Table used by the containing object if any, so that we can free all - tables if an error occurs. */ - struct symset_tbl *up; - /* Table of symbols (2**bits elements), Qunbound where unused. */ - Lisp_Object entries[]; -}; - -static inline ptrdiff_t -symset_size (int bits) -{ - return (ptrdiff_t) 1 << bits; -} - -static struct symset_tbl * -make_symset_table (int bits, struct symset_tbl *up) -{ - int maxbits =3D min (SIZE_WIDTH - 2 - (word_size < 8 ? 2 : 3), 32); - if (bits > maxbits) - memory_full (PTRDIFF_MAX);=09/* Will never happen in practice. */ -#ifdef HAVE_MPS - struct symset_tbl *st =3D igc_xzalloc_ambig (sizeof *st + (sizeof *st->e= ntries << bits)); -#else - struct symset_tbl *st =3D xmalloc (sizeof *st + (sizeof *st->entries << = bits)); -#endif - st->up =3D up; - ptrdiff_t size =3D symset_size (bits); - for (ptrdiff_t i =3D 0; i < size; i++) - st->entries[i] =3D Qunbound; - return st; -} - -/* Create a new symset to use for a new object. */ -static symset_t -push_symset (json_out_t *jo) -{ - int bits =3D 4; - struct symset_tbl *tbl =3D make_symset_table (bits, jo->ss_table); - jo->ss_table =3D tbl; - return (symset_t){ .count =3D 0, .bits =3D bits, .table =3D tbl }; -} - -/* Destroy the current symset. */ -static void -pop_symset (json_out_t *jo, symset_t *ss) -{ - jo->ss_table =3D ss->table->up; -#ifdef HAVE_MPS - igc_xfree (ss->table); -#else - xfree (ss->table); -#endif -} - -/* Remove all heap-allocated symset tables, in case an error occurred. */ -static void -cleanup_symset_tables (struct symset_tbl *st) -{ - while (st) - { - struct symset_tbl *up =3D st->up; -#ifdef HAVE_MPS - igc_xfree (st); -#else - xfree (st); -#endif - st =3D up; - } -} - -static inline uint32_t -symset_hash (Lisp_Object sym, int bits) -{ - EMACS_UINT hash; -#ifdef HAVE_MPS - hash =3D igc_hash (sym); -#else - hash =3D XHASH (sym); -#endif - return knuth_hash (reduce_emacs_uint_to_hash_hash (hash), bits); -} - -/* Enlarge the table used by a symset. */ -static NO_INLINE void -symset_expand (symset_t *ss) -{ - struct symset_tbl *old_table =3D ss->table; - int oldbits =3D ss->bits; - ptrdiff_t oldsize =3D symset_size (oldbits); - int bits =3D oldbits + 1; - ss->bits =3D bits; - ss->table =3D make_symset_table (bits, old_table->up); - /* Move all entries from the old table to the new one. */ - ptrdiff_t mask =3D symset_size (bits) - 1; - struct symset_tbl *tbl =3D ss->table; - for (ptrdiff_t i =3D 0; i < oldsize; i++) - { - Lisp_Object sym =3D old_table->entries[i]; - if (!BASE_EQ (sym, Qunbound)) -=09{ -=09 ptrdiff_t j =3D symset_hash (sym, bits); -=09 while (!BASE_EQ (tbl->entries[j], Qunbound)) -=09 j =3D (j + 1) & mask; -=09 tbl->entries[j] =3D sym; -=09} - } -#ifdef HAVE_MPS - igc_xfree (old_table); -#else - xfree (old_table); -#endif -} - -/* If sym is in ss, return false; otherwise add it and return true. - Comparison is done by strict identity. */ -static inline bool -symset_add (json_out_t *jo, symset_t *ss, Lisp_Object sym) -{ - /* Make sure we don't fill more than half of the table. */ - if (ss->count >=3D (symset_size (ss->bits) >> 1)) - { - symset_expand (ss); - jo->ss_table =3D ss->table; - } - - struct symset_tbl *tbl =3D ss->table; - ptrdiff_t mask =3D symset_size (ss->bits) - 1; - for (ptrdiff_t i =3D symset_hash (sym, ss->bits); ; i =3D (i + 1) & mask= ) - { - Lisp_Object s =3D tbl->entries[i]; - if (BASE_EQ (s, sym)) -=09return false;=09=09/* Previous occurrence found. */ - if (BASE_EQ (s, Qunbound)) -=09{ -=09 /* Not in set, add it. */ -=09 tbl->entries[i] =3D sym; -=09 ss->count++; -=09 return true; -=09} - } -} - static NO_INLINE void json_out_grow_buf (json_out_t *jo, ptrdiff_t bytes) { @@ -283,7 +130,6 @@ cleanup_json_out (void *arg) json_out_t *jo =3D arg; xfree (jo->buf); jo->buf =3D NULL; - cleanup_symset_tables (jo->ss_table); } =20 /* Make room for `bytes` more bytes in buffer. */ @@ -442,8 +288,8 @@ json_out_unnest (json_out_t *jo) static void json_out_object_cons (json_out_t *jo, Lisp_Object obj) { + Lisp_Object symset =3D CALLN (Fmake_hash_table, QCtest, Qeq); json_out_nest (jo); - symset_t ss =3D push_symset (jo); json_out_byte (jo, '{'); bool is_alist =3D CONSP (XCAR (obj)); bool first =3D true; @@ -469,8 +315,9 @@ json_out_object_cons (json_out_t *jo, Lisp_Object obj) key =3D maybe_remove_pos_from_symbol (key); CHECK_TYPE (BARE_SYMBOL_P (key), Qsymbolp, key); =20 - if (symset_add (jo, &ss, key)) + if (NILP (Fgethash (key, symset, Qnil))) =09{ +=09 Fputhash (key, Qt, symset); =09 if (!first) =09 json_out_byte (jo, ','); =09 first =3D false; @@ -486,7 +333,6 @@ json_out_object_cons (json_out_t *jo, Lisp_Object obj) } CHECK_LIST_END (tail, obj); json_out_byte (jo, '}'); - pop_symset (jo, &ss); json_out_unnest (jo); } =20 @@ -591,7 +437,6 @@ json_serialize (json_out_t *jo, Lisp_Object object, jo->capacity =3D 0; jo->chars_delta =3D 0; jo->buf =3D NULL; - jo->ss_table =3D NULL; jo->conf.object_type =3D json_object_hashtable; jo->conf.array_type =3D json_array_array; jo->conf.null_object =3D QCnull; @@ -729,6 +574,7 @@ #define JSON_PARSER_INTERNAL_BYTE_WORKSPACE_SIZE 512 Lisp_Object internal_object_workspace [JSON_PARSER_INTERNAL_OBJECT_WORKSPACE_SIZE]; Lisp_Object *object_workspace; + Lisp_Object object_workspace_vector; size_t object_workspace_size; size_t object_workspace_current; =20 @@ -796,6 +642,7 @@ json_parser_init (struct json_parser *parser, parser->object_workspace_size =3D JSON_PARSER_INTERNAL_OBJECT_WORKSPACE_SIZE; parser->object_workspace_current =3D 0; + parser->object_workspace_vector =3D Qnil; =20 parser->byte_workspace =3D parser->internal_byte_workspace; parser->byte_workspace_end =3D (parser->byte_workspace @@ -806,8 +653,6 @@ json_parser_init (struct json_parser *parser, json_parser_done (void *parser) { struct json_parser *p =3D (struct json_parser *) parser; - if (p->object_workspace !=3D p->internal_object_workspace) - xfree (p->object_workspace); if (p->byte_workspace !=3D p->internal_byte_workspace) xfree (p->byte_workspace); } @@ -818,6 +663,11 @@ json_parser_done (void *parser) json_make_object_workspace_for_slow_path (struct json_parser *parser, =09=09=09=09=09 size_t size) { + if (NILP (parser->object_workspace_vector)) + { + parser->object_workspace_vector =3D +=09Fvector(parser->object_workspace_current, parser->object_workspace); + } size_t needed_workspace_size =3D (parser->object_workspace_current + size); size_t new_workspace_size =3D parser->object_workspace_size; @@ -829,23 +679,13 @@ json_make_object_workspace_for_slow_path (struct json= _parser *parser, =09} } =20 - Lisp_Object *new_workspace_ptr; - if (parser->object_workspace_size - =3D=3D JSON_PARSER_INTERNAL_OBJECT_WORKSPACE_SIZE) - { - new_workspace_ptr -=09=3D xnmalloc (new_workspace_size, sizeof (Lisp_Object)); - memcpy (new_workspace_ptr, parser->object_workspace, -=09 (sizeof (Lisp_Object) -=09 * parser->object_workspace_current)); - } - else - { - new_workspace_ptr -=09=3D xnrealloc (parser->object_workspace, new_workspace_size, -=09=09 sizeof (Lisp_Object)); - } + Lisp_Object new_workspace_vector =3D + larger_vector (parser->object_workspace_vector, +=09=09 new_workspace_size - parser->object_workspace_size, -1); + + Lisp_Object *new_workspace_ptr =3D XVECTOR (new_workspace_vector)->conte= nts; =20 + parser->object_workspace_vector =3D new_workspace_vector; parser->object_workspace =3D new_workspace_ptr; parser->object_workspace_size =3D new_workspace_size; } @@ -1476,7 +1316,7 @@ json_parse_array (struct json_parser *parser) =09result =3D make_vector (number_of_elements, Qnil); =09for (size_t i =3D 0; i < number_of_elements; i++) =09 { -=09 rarely_quit (i); +=09 rarely_quit (~i); =09 ASET (result, i, parser->object_workspace[first + i]); =09 } =09parser->object_workspace_current =3D first; From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 10:19:39 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 15:19:39 +0000 Received: from localhost ([127.0.0.1]:52642 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHljW-0007Fa-Iq for submit@debbugs.gnu.org; Sun, 01 Dec 2024 10:19:39 -0500 Received: from mail-wm1-f44.google.com ([209.85.128.44]:49653) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHljT-0007FQ-6i for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 10:19:37 -0500 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-434aa472617so28396075e9.3 for <74547@debbugs.gnu.org>; Sun, 01 Dec 2024 07:19:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733066314; x=1733671114; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=aiIY4o0BOyGpZllwCCWa+6r0EYNpuzrDbZgqfEz6JpM=; b=TuVFbay7iXrgt4bWnyr+md2GxL5ahDiiGyaLH7G9ocztmJME5E171XpkGuTEN+Rli2 8PSS/V/Hb0EDW+0ZdDd/E+CpxHOK3JgWDsTc1cGg7bwINA/n9lPYS37AJqXGEp34jLO3 prEmczWdWAMHn7cP30OZy4zBIPf5PC5IqMd/125JO2AJOzbc2Td92hpxFiNcfDaSIXiL OgpHZYd1iw9qSR28x8ljRpMSUPCkdS/bUJrNs9xtmgK211R0YqN2o6uDOMQHv6WkeB7A NHNa5VsE1or6L5CaQtqqc8rt+2/CPpmU22IL5fM3Ndy5eIJG0VgN3a1I4xwwwCFXun61 HlHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733066314; x=1733671114; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=aiIY4o0BOyGpZllwCCWa+6r0EYNpuzrDbZgqfEz6JpM=; b=Z5nSaDNV3x2JaC+CXuZAuB2X3/4zNGt9KrVjmkQttnC1Qf1bom4OifsAzcisKFo+vc /EACewUc9eTHi/cqLyMdNFfAq+xFvjGM7MeyTk1R55ntQ0LGv4D0TEt6FCYKdJ7TSXKz V4AmAcJDP4YydEUsybMLwhqfy1cLMRQhhsIqwsOkDDMSxx6GjhyIqUFfozs/jprQL4Uw 5BHn4PGD/6XVHz7/vw2u2uC6kFA/C/RU9rLxNRYQDvz9c3wvRVwPA5i+okH3gQnuohC0 EVUf57JxHdFbQ5Qx8HipMD7mrw7j+ntiJd53/u88cvSus8zIdgUAPMc8TqS6rUPKI4/v MWnQ== X-Gm-Message-State: AOJu0Yz8kf0yZIHoyOfuvk0i3kj7M/f0WCl4ciAuSKSjhNoOfaG+9DnE 48jvER8YBd0wEKN0pMglQJy73VxAVpsoHj9eSM2QVapEV3sjO8Rv X-Gm-Gg: ASbGnct0TNSWuhjEYtdC/Td8dbCFD63N3EmROaRdZoD3v1E3j4vQtRDXxicC9HPCIgu geXjRMQB3gntpxqTSYF3+GhZsqB2tkcXkwD1qoEb8a7wfBXHFcV6PlyEITzcWd0Ox5D/tjANl9M EYWgcmj3KgEUOBS2U2sGykNzMtiib+7+kqwOa0+v07XV9miCooz4mN95xrEY7YiqBik5iE6gxzj 7kKNGwtNIB4mgyngLIiwZKJiaIL9+kRdgBnY3fI2T04bNC3/eqxYmWNBFdTjEYNkY+vocBV8Xpr RICkvFBS1tC2/Srz8FKlVzVqUuz7G9AtFpN3G04PJa2pNoQ8hdeFapb8Wg== X-Google-Smtp-Source: AGHT+IEh6Ww0x8zZKkd1whZCLDigM3pBrdQcbHhY2LDx5Wry78lJ5xlylxXqhkEWgCqLPYLCxFTlxA== X-Received: by 2002:a05:600c:5102:b0:432:d797:404a with SMTP id 5b1f17b1804b1-434a9de3947mr157775125e9.22.1733066314099; Sun, 01 Dec 2024 07:18:34 -0800 (PST) Received: from pro2 (p200300e0b73e1e0079ddbf8403284f30.dip0.t-ipconnect.de. [2003:e0:b73e:1e00:79dd:bf84:328:4f30]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-434aa763aaesm150495715e9.14.2024.12.01.07.18.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Dec 2024 07:18:32 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Pip Cet Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c In-Reply-To: <87wmgjlabu.fsf@protonmail.com> (Pip Cet's message of "Sun, 01 Dec 2024 14:58:10 +0000") References: <87serdu9m3.fsf@telefonica.net> <87cyibn0dz.fsf@protonmail.com> <875xo3mvqh.fsf@protonmail.com> <871pyrmui4.fsf@protonmail.com> <87wmgjlabu.fsf@protonmail.com> Date: Sun, 01 Dec 2024 16:18:31 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: 74547@debbugs.gnu.org, =?utf-8?Q?=C3=93scar?= Fuentes , geza.herman@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > Gerd M=C3=B6llmann writes: > >> Pip Cet writes: > >>> Gerd M=C3=B6llmann writes: >>>> Pip Cet writes: >>>> Yes, exactly, json.c. First thing I saw when searching for xfree >>>> >>>> static void >>>> json_parser_done (void *parser) >>>> { >>>> struct json_parser *p =3D (struct json_parser *) parser; >>>> if (p->object_workspace !=3D p->internal_object_workspace) >>>> xfree (p->object_workspace); >>>> >>>> That at least needs an explanation. I would have expected it to be >>>> allocated as root. >>> >>> Well, the explanation is this comment: >>> >>> /* Lisp_Objects are collected in this area during object/array >>> parsing. To avoid allocations, initially >>> internal_object_workspace is used. If it runs out of space then >>> we switch to allocated space. Important note: with this design, >>> GC must not run during JSON parsing, otherwise Lisp_Objects in >>> the workspace may get incorrectly collected. */ >> >> That explains it, indeed :-(. > > Just to be clear, I think the mixed heap/stack allocation is the right > thing to do here, but we need to let both garbage collectors know about > the Lisp_Objects we allocated. > > I think the best way to do that is to use a Lisp_Vector when we run out > of stack space. That way, we don't have to worry about forgetting to GC > it, and we can use standard functions rather than rolling our own. Yeah, I'd prefer using Lisp_Vectors too, and it was actually implemented at some point, but removed again, see https://yhetil.org/emacs-devel/87edc1rzig.fsf@gmail.com/ I vaguely remember a longer thread about GC in json.c at the time. Could be that that was before igc became a realistic possibility, don't remember. And yes, I've forgotten about it, and should actually have fixed this long ago :-). From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 10:24:45 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 15:24:45 +0000 Received: from localhost ([127.0.0.1]:52651 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHloS-0007W4-GK for submit@debbugs.gnu.org; Sun, 01 Dec 2024 10:24:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHloQ-0007Vj-1O for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 10:24:43 -0500 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 1tHloJ-00025D-5Y; Sun, 01 Dec 2024 10:24:35 -0500 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=39XhSevY9aqzOUcNWestWOZBnyi0L75jbfKOGTPD6Xw=; b=hmCqfdYLj24jdz6xhGY0 7bzNqHeeXaP08Gx0KTD3dNu2Fd0ymk7shEMXFV5QoNZigR5w2A/tNsQzlx7E/Rbpyv29a+Ng9mQuY OlZmp9dKfE7eE765+3Q8/xGQTwME8TL8Io4yAr2GU772lyy4cdRxZeEvroqPAmqQBmAFa4ijPFWQr LP9LR85OSmqTrXXnKjRKXLtlgfsoNJ8vnvfrwir/HGkIgjqyE9xGvy9dSzI1sTgroLOdO/EAwiO5b h1qQKNW2tSOsfm6pTBoLGwppOGWPNxopgLonGv8hwD7XgOv75bZDj8Ro20K5i+2E05N5WEGTbJ0Pp GScWLzc1osD3GQ==; Date: Sun, 01 Dec 2024 17:23:45 +0200 Message-Id: <86wmgj4ebi.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet , Mattias =?utf-8?Q?Engdeg=C3=A5rd?= , =?utf-8?Q?G=C3=A9za?= Herman In-Reply-To: <87wmgjlabu.fsf@protonmail.com> (bug-gnu-emacs@gnu.org) Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c References: <87serdu9m3.fsf@telefonica.net> <87cyibn0dz.fsf@protonmail.com> <875xo3mvqh.fsf@protonmail.com> <871pyrmui4.fsf@protonmail.com> <87wmgjlabu.fsf@protonmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74547 Cc: gerd.moellmann@gmail.com, 74547@debbugs.gnu.org, oscarfv@telefonica.net, geza.herman@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 74547@debbugs.gnu.org, > Óscar Fuentes , geza.herman@gmail.com > Date: Sun, 01 Dec 2024 14:58:10 +0000 > From: Pip Cet via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Gerd Möllmann writes: > > > Pip Cet writes: > > >> Gerd Möllmann writes: > >>> Pip Cet writes: > >>> Yes, exactly, json.c. First thing I saw when searching for xfree > >>> > >>> static void > >>> json_parser_done (void *parser) > >>> { > >>> struct json_parser *p = (struct json_parser *) parser; > >>> if (p->object_workspace != p->internal_object_workspace) > >>> xfree (p->object_workspace); > >>> > >>> That at least needs an explanation. I would have expected it to be > >>> allocated as root. > >> > >> Well, the explanation is this comment: > >> > >> /* Lisp_Objects are collected in this area during object/array > >> parsing. To avoid allocations, initially > >> internal_object_workspace is used. If it runs out of space then > >> we switch to allocated space. Important note: with this design, > >> GC must not run during JSON parsing, otherwise Lisp_Objects in > >> the workspace may get incorrectly collected. */ > > > > That explains it, indeed :-(. > > Just to be clear, I think the mixed heap/stack allocation is the right > thing to do here, but we need to let both garbage collectors know about > the Lisp_Objects we allocated. > > I think the best way to do that is to use a Lisp_Vector when we run out > of stack space. That way, we don't have to worry about forgetting to GC > it, and we can use standard functions rather than rolling our own. > > >> Obviously, we cannot make any such guarantees when MPS is in use. (I > >> don't think we can make the guarantee when MPS is not in use, but I'm > >> not totally certain; we certainly allocate strings while parsing JSON, > >> which is sufficient to trigger GC in the MPS case). > > > > If json.c calls something like maybe_quit, which I's expect it must, > > then GC can indeed happen. See bug#56108 for an example in the regexp > > code found with ASAN. It's not as risky in the old code as with > > concurrent GC, but anyway. > > There's a rarely_quit in json_parse_array, which, AFAICS, always > triggers in the first loop iteration (when i == 0), but probably never > reaches 65536 for the second trigger. > > My proposal is to modify json.c so it uses a lisp vector if more than 64 > objects are needed, and to remove the home-grown symset hash set, > replacing it by a standard hash table. > > Note that the symset is only used to detect duplicate JSON keys. When > such duplication is detected, we simply ignore the second plist entry. > (I think it would be better to throw an error, but the documentation > disagrees.) > > So here's the patch with the old behavior, where > > (json-serialize '(a "test" a "ignored")) > > doesn't throw an error and simply returns > > "{\"a\":\"test\"}" Adding Mattias and Géza, who were involved in implementing json.c. > commit 85fbd342d3b4a8afabe8078e19be9b45fe3e20d2 > Author: Pip Cet > Date: Sun Dec 1 12:46:08 2024 +0000 > > Use standard Lisp objects in json.c (bug#74547) > > * src/json.c (json_out_t): Make the symset table a Lisp_Object. > (symset_t): > (pop_symset): > (cleanup_symset_tables): > (symset_hash): > (symset_expand): > (symset_size): Remove. > (make_symset_table): Use an ordinary hash table for the symset. > (push_symset): Don't return a value. > (symset_add): Use ordinary hash table accessors. > (cleanup_json_out): Remove. > (json_out_object_cons): Use ordinary hash table for symsets. > (json_serialize): > (json_parser_init): > (json_parser_done): Adjust to use ordinary hash table code. > (json_make_object_workspace_for_slow_path): Use an ordinary vector for > the workspace. > (json_parse_array): Avoid calling rarely_quit(0) > (json_parser_done): Remove manual memory management. > > diff --git a/src/json.c b/src/json.c > index eb446f5c221..0e17b893087 100644 > --- a/src/json.c > +++ b/src/json.c > @@ -28,7 +28,6 @@ Copyright (C) 2017-2024 Free Software Foundation, Inc. > #include "lisp.h" > #include "buffer.h" > #include "coding.h" > -#include "igc.h" > > enum json_object_type > { > @@ -111,161 +110,9 @@ json_parse_args (ptrdiff_t nargs, Lisp_Object *args, > ptrdiff_t chars_delta; /* size - {number of characters in buf} */ > > int maxdepth; > - struct symset_tbl *ss_table; /* table used by containing object */ > struct json_configuration conf; > } json_out_t; > > -/* Set of symbols. */ > -typedef struct > -{ > - ptrdiff_t count; /* symbols in table */ > - int bits; /* log2(table size) */ > - struct symset_tbl *table; /* heap-allocated table */ > -} symset_t; > - > -struct symset_tbl > -{ > - /* Table used by the containing object if any, so that we can free all > - tables if an error occurs. */ > - struct symset_tbl *up; > - /* Table of symbols (2**bits elements), Qunbound where unused. */ > - Lisp_Object entries[]; > -}; > - > -static inline ptrdiff_t > -symset_size (int bits) > -{ > - return (ptrdiff_t) 1 << bits; > -} > - > -static struct symset_tbl * > -make_symset_table (int bits, struct symset_tbl *up) > -{ > - int maxbits = min (SIZE_WIDTH - 2 - (word_size < 8 ? 2 : 3), 32); > - if (bits > maxbits) > - memory_full (PTRDIFF_MAX); /* Will never happen in practice. */ > -#ifdef HAVE_MPS > - struct symset_tbl *st = igc_xzalloc_ambig (sizeof *st + (sizeof *st->entries << bits)); > -#else > - struct symset_tbl *st = xmalloc (sizeof *st + (sizeof *st->entries << bits)); > -#endif > - st->up = up; > - ptrdiff_t size = symset_size (bits); > - for (ptrdiff_t i = 0; i < size; i++) > - st->entries[i] = Qunbound; > - return st; > -} > - > -/* Create a new symset to use for a new object. */ > -static symset_t > -push_symset (json_out_t *jo) > -{ > - int bits = 4; > - struct symset_tbl *tbl = make_symset_table (bits, jo->ss_table); > - jo->ss_table = tbl; > - return (symset_t){ .count = 0, .bits = bits, .table = tbl }; > -} > - > -/* Destroy the current symset. */ > -static void > -pop_symset (json_out_t *jo, symset_t *ss) > -{ > - jo->ss_table = ss->table->up; > -#ifdef HAVE_MPS > - igc_xfree (ss->table); > -#else > - xfree (ss->table); > -#endif > -} > - > -/* Remove all heap-allocated symset tables, in case an error occurred. */ > -static void > -cleanup_symset_tables (struct symset_tbl *st) > -{ > - while (st) > - { > - struct symset_tbl *up = st->up; > -#ifdef HAVE_MPS > - igc_xfree (st); > -#else > - xfree (st); > -#endif > - st = up; > - } > -} > - > -static inline uint32_t > -symset_hash (Lisp_Object sym, int bits) > -{ > - EMACS_UINT hash; > -#ifdef HAVE_MPS > - hash = igc_hash (sym); > -#else > - hash = XHASH (sym); > -#endif > - return knuth_hash (reduce_emacs_uint_to_hash_hash (hash), bits); > -} > - > -/* Enlarge the table used by a symset. */ > -static NO_INLINE void > -symset_expand (symset_t *ss) > -{ > - struct symset_tbl *old_table = ss->table; > - int oldbits = ss->bits; > - ptrdiff_t oldsize = symset_size (oldbits); > - int bits = oldbits + 1; > - ss->bits = bits; > - ss->table = make_symset_table (bits, old_table->up); > - /* Move all entries from the old table to the new one. */ > - ptrdiff_t mask = symset_size (bits) - 1; > - struct symset_tbl *tbl = ss->table; > - for (ptrdiff_t i = 0; i < oldsize; i++) > - { > - Lisp_Object sym = old_table->entries[i]; > - if (!BASE_EQ (sym, Qunbound)) > - { > - ptrdiff_t j = symset_hash (sym, bits); > - while (!BASE_EQ (tbl->entries[j], Qunbound)) > - j = (j + 1) & mask; > - tbl->entries[j] = sym; > - } > - } > -#ifdef HAVE_MPS > - igc_xfree (old_table); > -#else > - xfree (old_table); > -#endif > -} > - > -/* If sym is in ss, return false; otherwise add it and return true. > - Comparison is done by strict identity. */ > -static inline bool > -symset_add (json_out_t *jo, symset_t *ss, Lisp_Object sym) > -{ > - /* Make sure we don't fill more than half of the table. */ > - if (ss->count >= (symset_size (ss->bits) >> 1)) > - { > - symset_expand (ss); > - jo->ss_table = ss->table; > - } > - > - struct symset_tbl *tbl = ss->table; > - ptrdiff_t mask = symset_size (ss->bits) - 1; > - for (ptrdiff_t i = symset_hash (sym, ss->bits); ; i = (i + 1) & mask) > - { > - Lisp_Object s = tbl->entries[i]; > - if (BASE_EQ (s, sym)) > - return false; /* Previous occurrence found. */ > - if (BASE_EQ (s, Qunbound)) > - { > - /* Not in set, add it. */ > - tbl->entries[i] = sym; > - ss->count++; > - return true; > - } > - } > -} > - > static NO_INLINE void > json_out_grow_buf (json_out_t *jo, ptrdiff_t bytes) > { > @@ -283,7 +130,6 @@ cleanup_json_out (void *arg) > json_out_t *jo = arg; > xfree (jo->buf); > jo->buf = NULL; > - cleanup_symset_tables (jo->ss_table); > } > > /* Make room for `bytes` more bytes in buffer. */ > @@ -442,8 +288,8 @@ json_out_unnest (json_out_t *jo) > static void > json_out_object_cons (json_out_t *jo, Lisp_Object obj) > { > + Lisp_Object symset = CALLN (Fmake_hash_table, QCtest, Qeq); > json_out_nest (jo); > - symset_t ss = push_symset (jo); > json_out_byte (jo, '{'); > bool is_alist = CONSP (XCAR (obj)); > bool first = true; > @@ -469,8 +315,9 @@ json_out_object_cons (json_out_t *jo, Lisp_Object obj) > key = maybe_remove_pos_from_symbol (key); > CHECK_TYPE (BARE_SYMBOL_P (key), Qsymbolp, key); > > - if (symset_add (jo, &ss, key)) > + if (NILP (Fgethash (key, symset, Qnil))) > { > + Fputhash (key, Qt, symset); > if (!first) > json_out_byte (jo, ','); > first = false; > @@ -486,7 +333,6 @@ json_out_object_cons (json_out_t *jo, Lisp_Object obj) > } > CHECK_LIST_END (tail, obj); > json_out_byte (jo, '}'); > - pop_symset (jo, &ss); > json_out_unnest (jo); > } > > @@ -591,7 +437,6 @@ json_serialize (json_out_t *jo, Lisp_Object object, > jo->capacity = 0; > jo->chars_delta = 0; > jo->buf = NULL; > - jo->ss_table = NULL; > jo->conf.object_type = json_object_hashtable; > jo->conf.array_type = json_array_array; > jo->conf.null_object = QCnull; > @@ -729,6 +574,7 @@ #define JSON_PARSER_INTERNAL_BYTE_WORKSPACE_SIZE 512 > Lisp_Object internal_object_workspace > [JSON_PARSER_INTERNAL_OBJECT_WORKSPACE_SIZE]; > Lisp_Object *object_workspace; > + Lisp_Object object_workspace_vector; > size_t object_workspace_size; > size_t object_workspace_current; > > @@ -796,6 +642,7 @@ json_parser_init (struct json_parser *parser, > parser->object_workspace_size > = JSON_PARSER_INTERNAL_OBJECT_WORKSPACE_SIZE; > parser->object_workspace_current = 0; > + parser->object_workspace_vector = Qnil; > > parser->byte_workspace = parser->internal_byte_workspace; > parser->byte_workspace_end = (parser->byte_workspace > @@ -806,8 +653,6 @@ json_parser_init (struct json_parser *parser, > json_parser_done (void *parser) > { > struct json_parser *p = (struct json_parser *) parser; > - if (p->object_workspace != p->internal_object_workspace) > - xfree (p->object_workspace); > if (p->byte_workspace != p->internal_byte_workspace) > xfree (p->byte_workspace); > } > @@ -818,6 +663,11 @@ json_parser_done (void *parser) > json_make_object_workspace_for_slow_path (struct json_parser *parser, > size_t size) > { > + if (NILP (parser->object_workspace_vector)) > + { > + parser->object_workspace_vector = > + Fvector(parser->object_workspace_current, parser->object_workspace); > + } > size_t needed_workspace_size > = (parser->object_workspace_current + size); > size_t new_workspace_size = parser->object_workspace_size; > @@ -829,23 +679,13 @@ json_make_object_workspace_for_slow_path (struct json_parser *parser, > } > } > > - Lisp_Object *new_workspace_ptr; > - if (parser->object_workspace_size > - == JSON_PARSER_INTERNAL_OBJECT_WORKSPACE_SIZE) > - { > - new_workspace_ptr > - = xnmalloc (new_workspace_size, sizeof (Lisp_Object)); > - memcpy (new_workspace_ptr, parser->object_workspace, > - (sizeof (Lisp_Object) > - * parser->object_workspace_current)); > - } > - else > - { > - new_workspace_ptr > - = xnrealloc (parser->object_workspace, new_workspace_size, > - sizeof (Lisp_Object)); > - } > + Lisp_Object new_workspace_vector = > + larger_vector (parser->object_workspace_vector, > + new_workspace_size - parser->object_workspace_size, -1); > + > + Lisp_Object *new_workspace_ptr = XVECTOR (new_workspace_vector)->contents; > > + parser->object_workspace_vector = new_workspace_vector; > parser->object_workspace = new_workspace_ptr; > parser->object_workspace_size = new_workspace_size; > } > @@ -1476,7 +1316,7 @@ json_parse_array (struct json_parser *parser) > result = make_vector (number_of_elements, Qnil); > for (size_t i = 0; i < number_of_elements; i++) > { > - rarely_quit (i); > + rarely_quit (~i); > ASET (result, i, parser->object_workspace[first + i]); > } > parser->object_workspace_current = first; > > > > > From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 10:31:02 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 15:31:02 +0000 Received: from localhost ([127.0.0.1]:52665 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHluX-0007w8-Ud for submit@debbugs.gnu.org; Sun, 01 Dec 2024 10:31:02 -0500 Received: from relayout01-q02.e.movistar.es ([86.109.101.142]:57881) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHluU-0007vR-4t for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 10:31:00 -0500 Received: from relayout01-redir.e.movistar.es (relayout01-redir.e.movistar.es [86.109.101.201]) by relayout01-out.e.movistar.es (Postfix) with ESMTP id 4Y1W8W16qyzjYSF; Sun, 1 Dec 2024 16:30:51 +0100 (CET) Received: from sky (125.red-83-37-187.dynamicip.rima-tde.net [83.37.187.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout01.e.movistar.es (Postfix) with ESMTPSA id 4Y1W8T6X2WzfZXL; Sun, 1 Dec 2024 16:30:49 +0100 (CET) From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Pip Cet Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c In-Reply-To: <87wmgjlabu.fsf@protonmail.com> (Pip Cet's message of "Sun, 01 Dec 2024 14:58:10 +0000") References: <87serdu9m3.fsf@telefonica.net> <87cyibn0dz.fsf@protonmail.com> <875xo3mvqh.fsf@protonmail.com> <871pyrmui4.fsf@protonmail.com> <87wmgjlabu.fsf@protonmail.com> Date: Sun, 01 Dec 2024 16:30:49 +0100 Message-ID: <87jzcjmndi.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-TnetOut-Country: IP: 83.37.187.125 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout01 X-TnetOut-MsgID: 4Y1W8T6X2WzfZXL.A5986 X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: oscarfv@telefonica.net X-TnetOut-Watermark: 1733671850.96723@ZaXSmhWmXoXC2suDA8+tsA X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: Gerd =?utf-8?Q?M=C3=B6llmann?= , 74547@debbugs.gnu.org, geza.herman@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > commit 85fbd342d3b4a8afabe8078e19be9b45fe3e20d2 > Author: Pip Cet > Date: Sun Dec 1 12:46:08 2024 +0000 Pip, is that your local repo? Do you intend to push the changes soon or should I apply them as patches over scratch/igc? Today I plan to do quite a lot of work with lsp-mode. Thanks! From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 10:48:39 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 15:48:39 +0000 Received: from localhost ([127.0.0.1]:52695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHmBb-0000MO-4f for submit@debbugs.gnu.org; Sun, 01 Dec 2024 10:48:39 -0500 Received: from mail-40134.protonmail.ch ([185.70.40.134]:33483) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHmBY-0000Ll-8m for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 10:48:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1733068110; x=1733327310; bh=IkFgSGWas+U3hFWzpW3LpMaoXECf+pRFb1NaM+cfCDQ=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=n3FrjvDRqEgOW3Os/wOttw4u75fji2KcKnvQPM13iV2UA/7dd/tq6gYtfs1KwGVzy T+WS6ApsmFo8XBSiAYw1fWWObVMBDR8+4huVNv9tWpJom+HKavCOcJxRNSF08n1keq Cyhz43x/CBUmK+HEXBbpJGc188X0M5PneXXvTeY55xazNq+SDnGljpIeORoIUJ/z2i +mFCY61HTC1ItJSHBQEwcF3OKDBu+oLhQ3mgOfrdjsHOs3aM99ty7wI6Shcs/c0rbB Dr0gW3Aqxh5UNQdC1PS7RCQZeERqCPlXzO6YMHrQCubefYIbweAbJRye96H1zDOatG 3CF30fngN0kbw== Date: Sun, 01 Dec 2024 15:48:21 +0000 To: =?utf-8?Q?Gerd_M=C3=B6llmann?= From: Pip Cet Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c Message-ID: <87r06rl807.fsf@protonmail.com> In-Reply-To: References: <87serdu9m3.fsf@telefonica.net> <875xo3mvqh.fsf@protonmail.com> <871pyrmui4.fsf@protonmail.com> <87wmgjlabu.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 652a41fe042cdcd04200281a0c7a58e5ad504d09 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: 74547@debbugs.gnu.org, =?utf-8?Q?=C3=93scar_Fuentes?= , geza.herman@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Yeah, I'd prefer using Lisp_Vectors too, and it was actually implemented > at some point, but removed again, see > > https://yhetil.org/emacs-devel/87edc1rzig.fsf@gmail.com/ > > I vaguely remember a longer thread about GC in json.c at the time. Could > be that that was before igc became a realistic possibility, don't > remember. Okay, sounds like it's a political issue. I'll push the first patch which keeps changes to a minimum. Pip From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 10:49:28 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 15:49:28 +0000 Received: from localhost ([127.0.0.1]:52701 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHmCO-0000OY-Gh for submit@debbugs.gnu.org; Sun, 01 Dec 2024 10:49:28 -0500 Received: from mail-wm1-f43.google.com ([209.85.128.43]:52286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHmCL-0000OL-MK for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 10:49:26 -0500 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-434aa222d96so42591695e9.0 for <74547@debbugs.gnu.org>; Sun, 01 Dec 2024 07:49:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733068105; x=1733672905; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=iOUf9Y7YlcOa+ZAqIWjaUHUTl9fbJLMzEZxaNjYu4Mk=; b=UZuJtYUEwM8g/w1l/LfOJ6B9SB1NfeHWqtepNXvNj402HH8DJp+bnnF1MZbSmhLxek dK8yhByIQsnnHwIs7uay9s43UVsLhRELIgeV/b6bXVdLLhpNyQ9avwz6/QgdmSueVkEu SIBq7OoAdfv31y+HLIVjpJyHSeu5fhpDr03yAfBt90xXrl3xgTJYigDJrOdidLlyQb+v M/A8FNJegoCWgNvf3S6v1Yekob2GepWaz3RLPJUzgaFk2U5wkjxV60P3R5AK7kib81Kx 8tNt+cfc1dsmf3hLozhRI4MEXKM5D3wEUF4qqhK/TKKCT0Ori5nJeAn9GLK3BtFdnFd0 Swaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733068105; x=1733672905; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=iOUf9Y7YlcOa+ZAqIWjaUHUTl9fbJLMzEZxaNjYu4Mk=; b=hsFKsFvedkahTvEIPL7pEIqS40v3AuYENkyPriOcFW61wroiWMLigC9INTC9AEg+ak wuftJkEeNGSuUjHGOQoH7xtZS3DMDONDb4yylvzpEawYs5bQsAL0TOvD0L7c9t9/RjDT 4xUkCX1q5FkXJboyIccgXmUgiI1vrZd5AzXDQgu9c57LGjSCDoxvXVjOHzqJZSSB7xKb t4A3izchRdzBbTOt7dzA93vyc3eDzYfDmIRKWpwlBbk/HZ96KovzulMLdUqDfzb0uSkz 65l9LZfcss0VHF/dhmVfSbGiurMJ9FoVCC3U39gzpLlSCKd+isXILfoSgC0nHwdIgbxr xrfA== X-Forwarded-Encrypted: i=1; AJvYcCXr+cpqdYpA3QMXR+YjN79AhxFSEuDJ577t8zj5nHdGwC6TzE2qwKEUrUXUiAEnAwFBdjuPyQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yx4k7MZfhcJI5DrqPVrbyhgN4NaJ8HkJoigduwSoD7m800bal5s DXAmnWypXE3KRF3Nv60iLCVktzSZFlqvLs2Lmtx4krYN1FgepAE4 X-Gm-Gg: ASbGncvXMan6lB7dH3/4tD/90df7BQzpT06ZCX3mXm3zt85qpoMEtQIAd6uXOYSN3fh cVf9fU6pT07mne+QZS9a1s8WTgsWfEDiqMXn119v3CtEE2tJaoC/sLnMW6KfvROmZuPs68JF+sW uJ8akY7d3Sefh9Oftz/1oBX7QixK9xJvbdx5gDwf+HO1oy3fHzxTy3o3/QJuXoL+3WgyfgrKyJW nM7RkCMQCA1S/dkCjKRn5RvFJDP5crBTx4x6lv90NGo4HHl/SHZRLRcnR5/NfT3jxWge+vf/RFW rAobKXEL79RVaekGN7YXSYVfaTpimHnzdyzzNq+rOjh5d3iazrTjO3vv7w== X-Google-Smtp-Source: AGHT+IGUUTQRv94SCpyN/7ubmtalFDk5StggrvqRopDQPUdOBIhvl7vKkWAomAK1QtjioYI6F4wpcg== X-Received: by 2002:a05:600c:1c09:b0:434:9f88:a751 with SMTP id 5b1f17b1804b1-434a9de9542mr188949235e9.20.1733068104601; Sun, 01 Dec 2024 07:48:24 -0800 (PST) Received: from pro2 (p200300e0b73e1e0079ddbf8403284f30.dip0.t-ipconnect.de. [2003:e0:b73e:1e00:79dd:bf84:328:4f30]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-434aa7e5e59sm153971505e9.44.2024.12.01.07.48.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Dec 2024 07:48:24 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: =?utf-8?Q?=C3=93scar?= Fuentes Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c In-Reply-To: <87jzcjmndi.fsf@telefonica.net> (=?utf-8?Q?=22=C3=93scar?= Fuentes"'s message of "Sun, 01 Dec 2024 16:30:49 +0100") References: <87serdu9m3.fsf@telefonica.net> <87cyibn0dz.fsf@protonmail.com> <875xo3mvqh.fsf@protonmail.com> <871pyrmui4.fsf@protonmail.com> <87wmgjlabu.fsf@protonmail.com> <87jzcjmndi.fsf@telefonica.net> Date: Sun, 01 Dec 2024 16:48:23 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: Pip Cet , 74547@debbugs.gnu.org, geza.herman@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) =C3=93scar Fuentes writes: > Pip Cet writes: > >> commit 85fbd342d3b4a8afabe8078e19be9b45fe3e20d2 >> Author: Pip Cet >> Date: Sun Dec 1 12:46:08 2024 +0000 > > Pip, is that your local repo? Do you intend to push the changes soon or > should I apply them as patches over scratch/igc? Today I plan to do > quite a lot of work with lsp-mode. > > Thanks! I think you could apply either patch from Pip, Oscar. They should be functionally equivalent, and it could tell us if we are on the right track. It might take some time until a solution is found (it's Pip's second path :-)) that satisfies all parties. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 10:55:22 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 15:55:22 +0000 Received: from localhost ([127.0.0.1]:52716 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHmI5-0000nA-W5 for submit@debbugs.gnu.org; Sun, 01 Dec 2024 10:55:22 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHmI3-0000kB-MT for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 10:55:20 -0500 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 1tHmHx-0003by-KO; Sun, 01 Dec 2024 10:55:13 -0500 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=B2VTtmlR9n1W3BwSSa1Cs0Usw2wueJQf4FYzKZDz7xI=; b=nDdfYLdJWXTHdVnxpV70 PQVJqMCEbvz9p4EwbkQG7v7SlJk/rerBMYx9V9wpbTKL4fpyZfxcjafyjssmhnZMx25YeD2hyRbkG WtujS1N3hIUXfASKgZqOD7Ufi74V5ccm9WFQe79dCLrytDwTIJeDTW+SHoAQJ0KefAHckI2xST34R 7C814Z4qk1aYl8jCQ8xKBI3H2ca0GEPbhLqXvCugxPi5nl66nxswFP1mdJxidEFn4u3Vf0yJr1CHs 3mgfCw94tvlX9B0XDBxh38u+6NoXk1vgH+kPwD2cBiM+iGN8da0L41giF2ySSBv9Ix5dnI90SBDaw pJUQ2OdSh1z6sg==; Date: Sun, 01 Dec 2024 17:55:04 +0200 Message-Id: <86ttbn4cvb.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sun, 01 Dec 2024 16:18:31 +0100) Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c References: <87serdu9m3.fsf@telefonica.net> <87cyibn0dz.fsf@protonmail.com> <875xo3mvqh.fsf@protonmail.com> <871pyrmui4.fsf@protonmail.com> <87wmgjlabu.fsf@protonmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74547 Cc: pipcet@protonmail.com, oscarfv@telefonica.net, 74547@debbugs.gnu.org, geza.herman@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 74547@debbugs.gnu.org, > Óscar Fuentes , geza.herman@gmail.com > From: Gerd Möllmann > Date: Sun, 01 Dec 2024 16:18:31 +0100 > > Pip Cet writes: > > > Gerd Möllmann writes: > > > >> Pip Cet writes: > > > >>> Gerd Möllmann writes: > >>>> Pip Cet writes: > >>>> Yes, exactly, json.c. First thing I saw when searching for xfree > >>>> > >>>> static void > >>>> json_parser_done (void *parser) > >>>> { > >>>> struct json_parser *p = (struct json_parser *) parser; > >>>> if (p->object_workspace != p->internal_object_workspace) > >>>> xfree (p->object_workspace); > >>>> > >>>> That at least needs an explanation. I would have expected it to be > >>>> allocated as root. > >>> > >>> Well, the explanation is this comment: > >>> > >>> /* Lisp_Objects are collected in this area during object/array > >>> parsing. To avoid allocations, initially > >>> internal_object_workspace is used. If it runs out of space then > >>> we switch to allocated space. Important note: with this design, > >>> GC must not run during JSON parsing, otherwise Lisp_Objects in > >>> the workspace may get incorrectly collected. */ > >> > >> That explains it, indeed :-(. > > > > Just to be clear, I think the mixed heap/stack allocation is the right > > thing to do here, but we need to let both garbage collectors know about > > the Lisp_Objects we allocated. > > > > I think the best way to do that is to use a Lisp_Vector when we run out > > of stack space. That way, we don't have to worry about forgetting to GC > > it, and we can use standard functions rather than rolling our own. > > Yeah, I'd prefer using Lisp_Vectors too, and it was actually implemented > at some point, but removed again, see > > https://yhetil.org/emacs-devel/87edc1rzig.fsf@gmail.com/ > > I vaguely remember a longer thread about GC in json.c at the time. Could > be that that was before igc became a realistic possibility, don't > remember. > > And yes, I've forgotten about it, and should actually have fixed this > long ago :-). Please be sure to measure performance. json.c is performance-critical in many applications nowadays, that's why it was implemented in C. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 10:58:16 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 15:58:16 +0000 Received: from localhost ([127.0.0.1]:52726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHmKu-0000tb-0Q for submit@debbugs.gnu.org; Sun, 01 Dec 2024 10:58:16 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]:36579) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHmKr-0000tH-Vh for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 10:58:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1733068687; x=1733327887; bh=2vCLbG6U4k3GGy47k4rLyVeHzHDi50BkybIaAdJVU9Y=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=UbRJni7pJ626Xl14Us9fkZom7gYbzWLbdeJTmox1TzrwBrpN+WCLlGMzc+yKeFSBl BeeAbt20KLqW0uesIEfdj81UetXNVqsDxbaT6nUbHRwBV0ZrTb7XEWJWBkjGz2lOX0 OuhqzGDHSrE8p4G3NKsYEzW5R7U4ScHzCoUv/ZwiQlHwft0S+jCi7DF+3H/8G/tVmO /GFtlEIxWa1qjzBe5y5/VXRGin2UNoHfuoizFn1GxN+b6nO0VRABA4OxSuSUePVnoy 78Vc6ITzFcUVKKH1kcNFfnYp28TR6BfMXxoYvEcb4whU0rk9H81qsgA0QdiuKq3UcC qR/L+rXClnJZw== Date: Sun, 01 Dec 2024 15:58:05 +0000 To: =?utf-8?Q?=C3=93scar_Fuentes?= From: Pip Cet Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c Message-ID: <87mshfl7k0.fsf@protonmail.com> In-Reply-To: <87jzcjmndi.fsf@telefonica.net> References: <87serdu9m3.fsf@telefonica.net> <875xo3mvqh.fsf@protonmail.com> <871pyrmui4.fsf@protonmail.com> <87wmgjlabu.fsf@protonmail.com> <87jzcjmndi.fsf@telefonica.net> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 52a30f62fd74c46737f613fc24e3d45431d73829 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , 74547@debbugs.gnu.org, geza.herman@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) =C3=93scar Fuentes writes: > Pip Cet writes: > >> commit 85fbd342d3b4a8afabe8078e19be9b45fe3e20d2 >> Author: Pip Cet >> Date: Sun Dec 1 12:46:08 2024 +0000 > > Pip, is that your local repo? Do you intend to push the changes soon or > should I apply them as patches over scratch/igc? Today I plan to do > quite a lot of work with lsp-mode. I've pushed the first patch to scratch/igc. It'd be great if you could run it for a while to see whether it fixes the problem! Thanks! Pip From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 11:24:14 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 16:24:14 +0000 Received: from localhost ([127.0.0.1]:52813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHmk2-0002PV-8s for submit@debbugs.gnu.org; Sun, 01 Dec 2024 11:24:14 -0500 Received: from relayout02-q02.e.movistar.es ([86.109.101.152]:58527) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHmjy-0002PB-OO for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 11:24:13 -0500 Received: from relayout02-redir.e.movistar.es (relayout02-redir.e.movistar.es [86.109.101.202]) by relayout02-out.e.movistar.es (Postfix) with ESMTP id 4Y1XKv74dfzhYqG; Sun, 1 Dec 2024 17:24:03 +0100 (CET) Received: from sky (125.red-83-37-187.dynamicip.rima-tde.net [83.37.187.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout02.e.movistar.es (Postfix) with ESMTPSA id 4Y1XKs3VpPzdbPd; Sun, 1 Dec 2024 17:24:01 +0100 (CET) From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Pip Cet Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c In-Reply-To: <87mshfl7k0.fsf@protonmail.com> (Pip Cet's message of "Sun, 01 Dec 2024 15:58:05 +0000") References: <87serdu9m3.fsf@telefonica.net> <875xo3mvqh.fsf@protonmail.com> <871pyrmui4.fsf@protonmail.com> <87wmgjlabu.fsf@protonmail.com> <87jzcjmndi.fsf@telefonica.net> <87mshfl7k0.fsf@protonmail.com> Date: Sun, 01 Dec 2024 17:24:01 +0100 Message-ID: <87cyibmkwu.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-TnetOut-Country: IP: 83.37.187.125 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout02 X-TnetOut-MsgID: 4Y1XKs3VpPzdbPd.AACD6 X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: oscarfv@telefonica.net X-TnetOut-Watermark: 1733675043.64865@8GSwVo898H8yC/DaIZHHPA X-Spam-Status: No X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74547 Cc: Gerd =?utf-8?Q?M=C3=B6llmann?= , 74547@debbugs.gnu.org, geza.herman@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Pip Cet writes: > =C3=93scar Fuentes writes: > > I've pushed the first patch to scratch/igc. It'd be great if you could > run it for a while to see whether it fixes the problem! Just built Emacs with the first patch and a long session of work is underway. If Emacs doesn't crash today we can say with certainty that the patch solves the problem... or hides it :-) Thank you. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 11:33:28 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 16:33:28 +0000 Received: from localhost ([127.0.0.1]:52849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHmsy-0002w3-1k for submit@debbugs.gnu.org; Sun, 01 Dec 2024 11:33:28 -0500 Received: from mail-wr1-f49.google.com ([209.85.221.49]:51206) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHmsu-0002vq-U1 for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 11:33:26 -0500 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-385e0e224cbso1130113f8f.2 for <74547@debbugs.gnu.org>; Sun, 01 Dec 2024 08:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733070744; x=1733675544; darn=debbugs.gnu.org; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=qR+izncIY56V0NZ6aug0fSMp89RWJrhIoFykmXsHjtI=; b=lYF4PAlV5p1+agP2wJ752+Nf6VxeqFp0HPLO48ETLh64O236O5PIknmKwsg73VEBEI k1GfNY74pwbcL5rlXxzGh0AE1o80mTFgbTquZVNMHFgexqrJEmnsjUVJyOQxUBGwuhys DtwgwwrMkJrXoT3vg+eEx62Pf0ROcS7ww3mShoi14hkBLLj0Q8/gue6+Ul2GOVjwHHcL bbxqRoiYmLTsGmv+I9mQhACeNU+o44iIYEBjUsUY3juJN6HEPkDCqVxyfd7yPDsDXYMa GljxnvTFK4QBgM3ns+SI4Nqy90cgcXIf3XnyhbHZIcbMQnQWmdOcNiIVb4b+5sX2SAGb 7biA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733070744; x=1733675544; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=qR+izncIY56V0NZ6aug0fSMp89RWJrhIoFykmXsHjtI=; b=C9mv0pmUNzNCejseDpLmv7zI/suJsr+bxEv2rL2xWEi2BUVoDq/EWTJzYGnzjlMb8S MnyKNUr9ylrm9gifv50FAl3vgBEtp9HTRIJ8ziwuzX7z8Z15s3g+cORnpQ2WFuDk85rL lom57F3NeEhvAwF1ggn+QSAdp2aM+CdFJz4DLDTAeS6h+hUFWEcqrU8kBG9nxE2j5g75 40iCfWR5ee1/5U2xjHJ8UKJnu75AEk+uFsYZtJ5W2/NKgUAhaddZtOtBCyonOyFIiNuW Z8cmLQoACYlbrRBBdrry8uX+Zi9tfAhjkvNCZNp9n6CViZOfO6TMd61YHPiNY3foHagA GdAQ== X-Gm-Message-State: AOJu0Ywjt0i1xE86LkBfGHZAxDR8nw1laFsYtlnxKP7Dn9S9jDggTjIM s04xjWsBSVXiyjN1UclG7gCvD0lDfz9u612RPs/3aZ7YMIksD3k6 X-Gm-Gg: ASbGnctQLoeqWGKhKzYnNOXE/hjEg/v20jocofKGJWNNOxJt38jxKPy3Ly1zESqb1XN 2U/p2CGhbOVf3L2l8VKnupCOZuadfQeGcbpCXl0+elZkkV3CQLr616RZU4lAx4Q30vueuiKuE9h JHG+L41jcbou0fVdY6hIx2GRzWahCkUmWMxgFmoBblQnSB1VayBcTk+rJI+WEsFjKuWA6Iqcqy5 f3akZ50RYH39BCrklDUxPDKC/ebqJ5qsakU64GI2Ngc2H/y1i8Rm0uQMi0r7yOuO1njGroCpfHZ aJS4AINu X-Google-Smtp-Source: AGHT+IFF6ck/bex1q5S44mMkjJLj5jLNpO7dT3Kp9TkBoZlaaabVZRDGTSEWguPpCmFEC9Ep3cp1KQ== X-Received: by 2002:a05:6000:1fa3:b0:385:eed9:cbca with SMTP id ffacd0b85a97d-385eed9cda6mr1822412f8f.27.1733070743708; Sun, 01 Dec 2024 08:32:23 -0800 (PST) Received: from [192.168.1.65] (1F2EF6E9.nat.pool.telekom.hu. [31.46.246.233]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-434aa7e5285sm152947865e9.40.2024.12.01.08.32.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Dec 2024 08:32:23 -0800 (PST) Content-Type: multipart/alternative; boundary="------------Yd0QfrXRzY0YtXSFwv4UVQBF" Message-ID: <11705193-9151-43fb-9109-8a579e77d32b@gmail.com> Date: Sun, 1 Dec 2024 17:32:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c To: Pip Cet , =?UTF-8?Q?Gerd_M=C3=B6llmann?= References: <87serdu9m3.fsf@telefonica.net> <875xo3mvqh.fsf@protonmail.com> <871pyrmui4.fsf@protonmail.com> <87wmgjlabu.fsf@protonmail.com> <87r06rl807.fsf@protonmail.com> Content-Language: en-US From: Geza Herman In-Reply-To: <87r06rl807.fsf@protonmail.com> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: 74547@debbugs.gnu.org, =?UTF-8?Q?=C3=93scar_Fuentes?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --------------Yd0QfrXRzY0YtXSFwv4UVQBF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/1/24 16:48, Pip Cet wrote: > Gerd Möllmann writes: > >> Yeah, I'd prefer using Lisp_Vectors too, and it was actually implemented >> at some point, but removed again, see >> >> https://yhetil.org/emacs-devel/87edc1rzig.fsf@gmail.com/ >> >> I vaguely remember a longer thread about GC in json.c at the time. Could >> be that that was before igc became a realistic possibility, don't >> remember. > Okay, sounds like it's a political issue. I'll push the first patch > which keeps changes to a minimum. > > Pip > Back then, the future of the new GC was a question, so Gerd said (https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00544.html) that "Please don't take my GC efforts into consideration. That may succeed or not. But this is also a matter of good design, using the stack, (which BTW pdumper does, too), vs. bad design." That's why we went with the fastest implementation that doesn't use lisp vectors for storage. But we suspected that this JSON parser design will likely cause a problem with the new GC. So I think even if it turned out that the current problem was not caused by the parser, I still think that there should be something done about this JSON parser design to eliminate this potential problem. The lisp vector based approach was reverted because it added an extra pressure to the GC. For large JSON messages, it doesn't matter too much, but when the JSON is small, the extra GC time made the parser measurably slower. But, as far as I remember, that version hadn't have the small internal storage optimization yet. If we convert back to the vector based approach, the extra GC pressure will be smaller (compared to the original vector based approach without the internal storage), as for smaller sizes the vector won't be actually used. Géza --------------Yd0QfrXRzY0YtXSFwv4UVQBF Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/1/24 16:48, Pip Cet wrote:
Gerd Möllmann <gerd.moellmann@gmail.com> writes:


Yeah, I'd prefer using Lisp_Vectors too, and it was actually implemented
at some point, but removed again, see

  https://yhetil.org/emacs-devel/87edc1rzig.fsf@gmail.com/

I vaguely remember a longer thread about GC in json.c at the time. Could
be that that was before igc became a realistic possibility, don't
remember.

Okay, sounds like it's a political issue. I'll push the first patch
which keeps changes to a minimum.

Pip

Back then, the future of the new GC was a question, so Gerd said (https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00544.html) that
"Please don't take my GC efforts into consideration. That may succeed or not. But this is also a matter of good design, using the stack, (which BTW pdumper does, too), vs. bad design." That's why we went with the fastest implementation that doesn't use lisp vectors for storage. But we suspected that this JSON parser design will likely cause a problem with the new GC. So I think even if it turned out that the current problem was not caused by the parser, I still think that there should be something done about this JSON parser design to eliminate this potential problem. The lisp vector based approach was reverted because it added an extra pressure to the GC. For large JSON messages, it doesn't matter too much, but when the JSON is small, the extra GC time made the parser measurably slower. But, as far as I remember, that version hadn't have the small internal storage optimization yet. If we convert back to the vector based approach, the extra GC pressure will be smaller (compared to the original vector based approach without the internal storage), as for smaller sizes the vector won't be actually used.

Géza
--------------Yd0QfrXRzY0YtXSFwv4UVQBF-- From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 14:42:43 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 19:42:43 +0000 Received: from localhost ([127.0.0.1]:53142 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHpq7-0004Sg-1L for submit@debbugs.gnu.org; Sun, 01 Dec 2024 14:42:43 -0500 Received: from mail-wm1-f45.google.com ([209.85.128.45]:55653) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHpq5-0004SM-1D for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 14:42:42 -0500 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-434a752140eso28698825e9.3 for <74547@debbugs.gnu.org>; Sun, 01 Dec 2024 11:42:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733082095; x=1733686895; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=vNuz3UL9Zpu0avcodzbgpLVwILkZ+Jppd86uxJxLqn0=; b=ZjWdXzA46adA33ZdzWxN2MY9yCQ6oUd1jl6Yyn0rnucDPUMeq7a9vH0AOwYIK34M3h yhKyEL0HhUsMBUBimO8CakyrMO1H3UI1SUWM24eS8Vi83JpH+TxvNuwpztAWIc9aDrnT B8jGj8GV8I7Xdzryb6SbzHa2WowtneaWN9hVkZilDFTRMevI/Cho7fHMg90t2rdt9R+U 4bCjgl+N9tpA87i7+ytq03KDOl9VZ0pfPmXO/M2fdUoKFTy8/pA+If2uZNw2iqwDC3AK Yy+ASXD0COt8gjYH8ht8drcVLbUfsiDU+zjo4kJXUyImwPkmfArZfjlzRsENI8+7SUW1 iCgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733082095; x=1733686895; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=vNuz3UL9Zpu0avcodzbgpLVwILkZ+Jppd86uxJxLqn0=; b=gzVLNO1MBxH2tIkiDpvyu0Dy8aJla5qW0wbtAa5Mp2Nj0RR5xFoU2IzC9m7kfCj9oz Fl+a/rrfb3uqnJ6/HR8ovqLGXg5tQ0DP85e7JEo0d7Yd3NwZc1DUk8ssF3WWzbYU2IsG +92rJmSDuenMbtut2A4b0ZrN4Jl9hLxKw9Lg1W3DQ6Y3bUxnqR1bMw0fc0pY4r7PMGEM 20jtwd68hmXWi0o7OqkuSESpQ35Q29/6nDTmO7ISnGSyOiREzwvsynwFdUHD3XDZiq7g mKx0T3lHUJSSzs03xwfhBeciJEAonohfcuL8tQ9+c3LjykNYqe5cW8Dn1xiEFHeu8LcU 9CwQ== X-Forwarded-Encrypted: i=1; AJvYcCWLgpwarwvuYsiDAs9zFOKEbNtVIt5IYW94Xqh1/GohTYBVstzNwWIVQ143xzYSE5TLtD0Vlw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyeCxwJtkG/Zxs/ueJYJH8eXP9C7UqtJWmMBkhZI9DViYhzIruZ T/FhZT16T4ysAhkvd9Q57kFZ7NAtyoD1GmyIM+o06aUT4QGJKthT X-Gm-Gg: ASbGncsiDqCGPbb0tQhy2KmAcKUxPaTJAYhaOyjrBpRx+nVlhsliqBWemWuDEgbPkLH JyxL21Ihvvr3UOOAJsHkdrJFVZWe4P1rkLAgscytCkqk5G7vZeL+R+wugDebu9TInJzBOxHeEQO HQEikj/eGrFk1ER/n5ULd8HSoyBboWk8NUgh3IkUoHYMtlwwbmiAEcsvTqI0hXkIMDPyL64VXF2 cxLIi6UPc3TGY+6641lAv/AIjruGsOs0YJq8Ei+lpWzjI4NkjJ9BrIeIPVR0u13OrxS+B+GcEeP Bv5K/NL98JMm8o7pcCd5+mjO6TTMjinoRHVrCz52xuE7VcT+7Uq1KJ5EBg== X-Google-Smtp-Source: AGHT+IF25Dsg3Debo2eXa64i36jHFGN/fgKWQCG4q3qMz/BcE9PaNtuAHs5cBxLCzdDlnl45XNGPRg== X-Received: by 2002:a05:6000:2d04:b0:385:e30a:3945 with SMTP id ffacd0b85a97d-385e30a3b68mr3963383f8f.23.1733082095129; Sun, 01 Dec 2024 11:41:35 -0800 (PST) Received: from pro2 (p200300e0b73e1e0079ddbf8403284f30.dip0.t-ipconnect.de. [2003:e0:b73e:1e00:79dd:bf84:328:4f30]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-385ccd80435sm10362812f8f.100.2024.12.01.11.41.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Dec 2024 11:41:34 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Geza Herman Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c In-Reply-To: <11705193-9151-43fb-9109-8a579e77d32b@gmail.com> (Geza Herman's message of "Sun, 1 Dec 2024 17:32:21 +0100") References: <87serdu9m3.fsf@telefonica.net> <875xo3mvqh.fsf@protonmail.com> <871pyrmui4.fsf@protonmail.com> <87wmgjlabu.fsf@protonmail.com> <87r06rl807.fsf@protonmail.com> <11705193-9151-43fb-9109-8a579e77d32b@gmail.com> Date: Sun, 01 Dec 2024 20:41:33 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: Pip Cet , =?utf-8?Q?=C3=93scar?= Fuentes , 74547@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Geza Herman writes: > On 12/1/24 16:48, Pip Cet wrote: > > Gerd M=C3=B6llmann writes: > > Yeah, I'd prefer using Lisp_Vectors too, and it was actually implemented > at some point, but removed again, see > > https://yhetil.org/emacs-devel/87edc1rzig.fsf@gmail.com/ > > I vaguely remember a longer thread about GC in json.c at the time. Could > be that that was before igc became a realistic possibility, don't > remember. > > > Okay, sounds like it's a political issue. I'll push the first patch > which keeps changes to a minimum. > > Pip > > Back then, the future of the new GC was a question, so Gerd said > (https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00544.html) th= at > "Please don't take my GC efforts into consideration. That may succeed or = not. But this is also a matter of good design, > using the stack, (which BTW pdumper does, too), vs. bad design." That's w= hy we went with the fastest implementation that > doesn't use lisp vectors for storage. But we suspected that this JSON par= ser design will likely cause a problem with the > new GC. So I think even if it turned out that the current problem was not= caused by the parser, I still think that there > should be something done about this JSON parser design to eliminate this = potential problem. The lisp vector based > approach was reverted because it added an extra pressure to the GC. For l= arge JSON messages, it doesn't matter too much, > but when the JSON is small, the extra GC time made the parser measurably = slower. But, as far as I remember, that version > hadn't have the small internal storage optimization yet. If we convert ba= ck to the vector based approach, the extra GC > pressure will be smaller (compared to the original vector based approach = without the internal storage), as for smaller > sizes the vector won't be actually used. > > G=C3=A9za Sorry again for not remembering this earlier. It only resurfaced slowly in my mind when I saw Pip's patch. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 16:15:55 2024 Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 21:15:56 +0000 Received: from localhost ([127.0.0.1]:53288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHrIJ-0000k7-0n for submit@debbugs.gnu.org; Sun, 01 Dec 2024 16:15:55 -0500 Received: from mail-10629.protonmail.ch ([79.135.106.29]:10511) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHrIF-0000jp-C1 for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 16:15:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1733087743; x=1733346943; bh=rgX0cB6f0d56HBHNdrB+rVRh4a+cW7EaQjGMwJ5EnHw=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=rzOMXFmFIUw9ETY3k1+Z3UREtei+uuNkcrH8dCvWJQoY6jIf0G5QrgVcIa+atNVHJ UfX36/jy+eL7zkF3QqVEml9teGHEdOTeiGpk8IMOhAaOYrKB/0gFEAWoQSIevJE0eo hdpLaxfwMnd3oMWsAjL/go48nQuZMuMyJ7OJ22UZWn8FrVITJy7Q8HPT6D9MqvxtDT 00tI3JoWjREheq2yPUP51x0/YwwcbCbGHH8pkSDbpGd0iVR/Yvi4RjqoitJL1ARgWt Ffhl6YLwsL8kTYae6t7sdpP2yJRlfc7rYmqqu8HSbyD94mO0bAKCthWNJQwjHnXjT5 ySGwGkRmvwm6w== Date: Sun, 01 Dec 2024 21:15:41 +0000 To: Geza Herman From: Pip Cet Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c Message-ID: <87cyibksuu.fsf@protonmail.com> In-Reply-To: <11705193-9151-43fb-9109-8a579e77d32b@gmail.com> References: <87serdu9m3.fsf@telefonica.net> <875xo3mvqh.fsf@protonmail.com> <871pyrmui4.fsf@protonmail.com> <87wmgjlabu.fsf@protonmail.com> <87r06rl807.fsf@protonmail.com> <11705193-9151-43fb-9109-8a579e77d32b@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 3f8fadac9a75bf7da887997aee3303e7e1f03064 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , 74547@debbugs.gnu.org, =?utf-8?Q?=C3=93scar_Fuentes?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Geza Herman" writes: > On 12/1/24 16:48, Pip Cet wrote: > Gerd M=C2=B6llmann writes: > > Back then, the future of the new GC was a question, so Gerd said > (https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00544.html) > that > "Please don't take my GC efforts into consideration. That may succeed > or not. But this is also a matter of good design, using the stack, > (which BTW pdumper does, too), vs. bad design." That's why we went wit= h > the fastest implementation that doesn't use lisp vectors for storage. > But we suspected that this JSON parser design will likely cause a > problem with the new GC. So I think even if it turned out that the > current problem was not caused by the parser, I still think that there > should be something done about this JSON parser design to eliminate > this potential problem. The lisp vector based approach was reverted > because it added an extra pressure to the GC. For large JSON messages, > it doesn't matter too much, but when the JSON is small, the extra GC > time made the parser measurably slower. But, as far as I remember, tha= t > version hadn't have the small internal storage optimization yet. If we > convert back to the vector based approach, the extra GC pressure will > be smaller (compared to the original vector based approach without the > internal storage), as for smaller sizes the vector won't be actually > used. > G=C2=A9za Thank you for the summary, that makes sense. Is there a standard corpus of JSON documents that you use to benchmark the code? That would be very helpful, I think, since Eli correctly points out JSON parsing performance is critical. My gut feeling is that we should get rid of the object_workspace entirely, instead modifying the general Lisp code to avoid performance issues (and sacrifice some memory in the process, on most systems). When building a hash table, we can do so directly and fine-tune the hash table code not to reallocate too often. I'd imagine such fine tuning would be generally useful (JSON-derived hash tables are unlikely to exceed the initial 65 elements, but when they do, growing by a factor of four might be appropriate). When building a vector, we might want to introduce a `vtruncate' function which destructively reduces a vector's size without reallocating it. Again, I think that function would be useful in a few other places. Then we could start by allocating a 64-element vector, fill in the array elements, grow it in the rare case that we exceed 64 elements, and truncate it in the common case that fewer than 64 slots are used. No need to copy anything from the stack to the heap, the elements would just appear where they are needed. However, some memory would be wasted, and on low-memory systems, we might want to define `vtruncate' and `hash-table-truncate' to reduce memory usage. Here's some code which might illustrate this idea, but WON'T WORK yet, since the old GC requires vtruncate to do more work. >From 9c84c08fd9d4bb9c419025787663b7f7f2611952 Mon Sep 17 00:00:00 2001 From: Pip Cet Date: Sun, 1 Dec 2024 21:00:46 +0000 Subject: [PATCH] Optimize json.c performance * src/alloc.c (Fvtruncate): New function. (syms_of_alloc): Register it. * src/fns.c (Fhash_table_truncate): New function. (syms_of_fns): Register it. * src/json.c (JSON_PARSER_INTERNAL_OBJECT_WORKSPACE_SIZE): Rename to ... (JSON_PARSER_INITIAL_VECTOR_SIZE): ... this. (struct json_parser): Remove object workspace. (json_parser_init): Adjust to removed object workspace. (json_make_object_workspace_for_slow_path, json_make_object_workspace_for): Remove. (json_parse_array): Parse directly to a heap vector, truncate it when done. (json_parse_object): Parse directly to a hash table, truncate it when done. --- src/alloc.c | 25 +++++++++ src/fns.c | 13 +++++ src/json.c | 143 +++++++++++++--------------------------------------- 3 files changed, 74 insertions(+), 107 deletions(-) diff --git a/src/alloc.c b/src/alloc.c index 55126b1d551..b78c27ccf35 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -3935,6 +3935,30 @@ DEFUN ("vector", Fvector, Svector, 0, MANY, 0, return val; } =20 +DEFUN ("vtruncate", Fvtruncate, Svtruncate, 2, 2, 0, + doc: /* Truncate VECTOR so only the first LENGTH elements remain. + +Return a vector to be used instead of VECTOR, which may also be modified +destructively. This function is a performance optimization. */) + (Lisp_Object length, Lisp_Object vector) +{ + CHECK_TYPE (FIXNATP (length), Qwholenump, length); + CHECK_TYPE (VECTORP (vector) && +=09 PSEUDOVECTOR_TYPE (XVECTOR (vector)) =3D=3D PVEC_NORMAL_VECTOR, +=09 Qvectorp, vector); + if (XFIXNAT (length) > ASIZE (vector)) + signal_error ("vector too short", vector); + if (XFIXNAT (length) =3D=3D 0) + return zero_vector; + +#ifdef HAVE_MPS + XVECTOR (vector)->header.size =3D XFIXNAT (length); + return vector; +#else + return Fvector (XFIXNAT (length), XVECTOR (vector)->contents); +#endif +} + DEFUN ("make-byte-code", Fmake_byte_code, Smake_byte_code, 4, MANY, 0, doc: /* Create a byte-code object with specified arguments as eleme= nts. The arguments should be the ARGLIST, bytecode-string BYTE-CODE, constant @@ -8600,6 +8624,7 @@ syms_of_alloc (void) defsubr (&Sgarbage_collect_maybe); defsubr (&Smemory_info); defsubr (&Smemory_use_counts); + defsubr (&Svtruncate); #if defined GNU_LINUX && defined __GLIBC__ && \ (__GLIBC__ > 2 || __GLIBC_MINOR__ >=3D 10) =20 diff --git a/src/fns.c b/src/fns.c index f8191d72443..51bc7488457 100644 --- a/src/fns.c +++ b/src/fns.c @@ -6651,6 +6651,18 @@ DEFUN ("define-hash-table-test", Fdefine_hash_table_= test, return Fput (name, Qhash_table_test, list2 (test, hash)); } =20 +DEFUN ("hash-table-truncate", Fhash_table_truncate, + Shash_table_truncate, 1, 1, 0, + doc: /* Indicate that TABLE is unlikely to grow further. + +Returns TABLE, with its internal structures potentially reduced to fit +the current number of elements precisely. This function is a +performance optimization. */) + (Lisp_Object table) +{ + return table; +} + DEFUN ("internal--hash-table-histogram", Finternal__hash_table_histogram, Sinternal__hash_table_histogram, @@ -7408,6 +7420,7 @@ syms_of_fns (void) defsubr (&Shash_table_rehash_threshold); defsubr (&Shash_table_size); defsubr (&Shash_table_test); + defsubr (&Shash_table_truncate); defsubr (&Shash_table_weakness); defsubr (&Shash_table_p); defsubr (&Sclrhash); diff --git a/src/json.c b/src/json.c index 0e17b893087..dd8e45003c4 100644 --- a/src/json.c +++ b/src/json.c @@ -535,7 +535,7 @@ DEFUN ("json-insert", Fjson_insert, Sjson_insert, 1, MA= NY, } =20 =20 -#define JSON_PARSER_INTERNAL_OBJECT_WORKSPACE_SIZE 64 +#define JSON_PARSER_INITIAL_VECTOR_SIZE 64 #define JSON_PARSER_INTERNAL_BYTE_WORKSPACE_SIZE 512 =20 struct json_parser @@ -565,22 +565,8 @@ #define JSON_PARSER_INTERNAL_BYTE_WORKSPACE_SIZE 512 =20 size_t additional_bytes_count; =20 - /* Lisp_Objects are collected in this area during object/array - parsing. To avoid allocations, initially - internal_object_workspace is used. If it runs out of space then - we switch to allocated space. Important note: with this design, - GC must not run during JSON parsing, otherwise Lisp_Objects in - the workspace may get incorrectly collected. */ - Lisp_Object internal_object_workspace - [JSON_PARSER_INTERNAL_OBJECT_WORKSPACE_SIZE]; - Lisp_Object *object_workspace; - Lisp_Object object_workspace_vector; - size_t object_workspace_size; - size_t object_workspace_current; - - /* String and number parsing uses this workspace. The idea behind - internal_byte_workspace is the same as the idea behind - internal_object_workspace */ + /* String and number parsing uses this workspace. It starts out on + the stack, but moves to the heap if more space is needed. */ unsigned char internal_byte_workspace[JSON_PARSER_INTERNAL_BYTE_WORKSPACE_SIZE]; unsigned char *byte_workspace; @@ -638,12 +624,6 @@ json_parser_init (struct json_parser *parser, =20 parser->additional_bytes_count =3D 0; =20 - parser->object_workspace =3D parser->internal_object_workspace; - parser->object_workspace_size - =3D JSON_PARSER_INTERNAL_OBJECT_WORKSPACE_SIZE; - parser->object_workspace_current =3D 0; - parser->object_workspace_vector =3D Qnil; - parser->byte_workspace =3D parser->internal_byte_workspace; parser->byte_workspace_end =3D (parser->byte_workspace =09=09=09=09+ JSON_PARSER_INTERNAL_BYTE_WORKSPACE_SIZE); @@ -657,50 +637,6 @@ json_parser_done (void *parser) xfree (p->byte_workspace); } =20 -/* Makes sure that the object_workspace has 'size' available space for - Lisp_Objects */ -NO_INLINE static void -json_make_object_workspace_for_slow_path (struct json_parser *parser, -=09=09=09=09=09 size_t size) -{ - if (NILP (parser->object_workspace_vector)) - { - parser->object_workspace_vector =3D -=09Fvector(parser->object_workspace_current, parser->object_workspace); - } - size_t needed_workspace_size - =3D (parser->object_workspace_current + size); - size_t new_workspace_size =3D parser->object_workspace_size; - while (new_workspace_size < needed_workspace_size) - { - if (ckd_mul (&new_workspace_size, new_workspace_size, 2)) -=09{ -=09 json_signal_error (parser, Qjson_out_of_memory); -=09} - } - - Lisp_Object new_workspace_vector =3D - larger_vector (parser->object_workspace_vector, -=09=09 new_workspace_size - parser->object_workspace_size, -1); - - Lisp_Object *new_workspace_ptr =3D XVECTOR (new_workspace_vector)->conte= nts; - - parser->object_workspace_vector =3D new_workspace_vector; - parser->object_workspace =3D new_workspace_ptr; - parser->object_workspace_size =3D new_workspace_size; -} - -INLINE void -json_make_object_workspace_for (struct json_parser *parser, -=09=09=09=09size_t size) -{ - if (parser->object_workspace_size - parser->object_workspace_current - < size) - { - json_make_object_workspace_for_slow_path (parser, size); - } -} - static void json_byte_workspace_reset (struct json_parser *parser) { @@ -1258,10 +1194,18 @@ json_parse_number (struct json_parser *parser, int = c) json_parse_array (struct json_parser *parser) { int c =3D json_skip_whitespace (parser); - - const size_t first =3D parser->object_workspace_current; Lisp_Object result =3D Qnil; + ptrdiff_t index =3D 0; =20 + switch (parser->conf.array_type) + { + case json_array_array: + result =3D make_vector (0, Qnil); + break; + + default: + break; + } if (c !=3D ']') { parser->available_depth--; @@ -1277,10 +1221,15 @@ json_parse_array (struct json_parser *parser) =09 switch (parser->conf.array_type) =09 { =09 case json_array_array: -=09 json_make_object_workspace_for (parser, 1); -=09 parser->object_workspace[parser->object_workspace_current] -=09=09=3D element; -=09 parser->object_workspace_current++; +=09 if (index =3D=3D ASIZE (result)) +=09=09{ +=09=09 ptrdiff_t incr =3D ASIZE (result); +=09=09 if (incr =3D=3D 0) +=09=09 incr =3D JSON_PARSER_INITIAL_VECTOR_SIZE; +=09=09 result =3D larger_vector (result, incr, -1); +=09=09} +=09 ASET (result, index, element); +=09 index++; =09 break; =09 case json_array_list: =09 { @@ -1310,18 +1259,8 @@ json_parse_array (struct json_parser *parser) switch (parser->conf.array_type) { case json_array_array: - { -=09size_t number_of_elements -=09 =3D parser->object_workspace_current - first; -=09result =3D make_vector (number_of_elements, Qnil); -=09for (size_t i =3D 0; i < number_of_elements; i++) -=09 { -=09 rarely_quit (~i); -=09 ASET (result, i, parser->object_workspace[first + i]); -=09 } -=09parser->object_workspace_current =3D first; -=09break; - } + result =3D Fvtruncate (result, make_fixnum (index)); + break; case json_array_list: break; default: @@ -1349,10 +1288,18 @@ json_parse_object_member_value (struct json_parser = *parser) json_parse_object (struct json_parser *parser) { int c =3D json_skip_whitespace (parser); - - const size_t first =3D parser->object_workspace_current; Lisp_Object result =3D Qnil; =20 + switch (parser->conf.object_type) + { + case json_object_hashtable: + result =3D CALLN (Fmake_hash_table, QCtest, Qequal); + break; + + default: + break; + } + if (c !=3D '}') { parser->available_depth--; @@ -1374,11 +1321,7 @@ json_parse_object (struct json_parser *parser) =09 { =09=09Lisp_Object key =3D json_parse_string (parser, false, false); =09=09Lisp_Object value =3D json_parse_object_member_value (parser); -=09=09json_make_object_workspace_for (parser, 2); -=09=09parser->object_workspace[parser->object_workspace_current] =3D key; -=09=09parser->object_workspace_current++; -=09=09parser->object_workspace[parser->object_workspace_current] =3D value= ; -=09=09parser->object_workspace_current++; +=09=09Fputhash (key, value, result); =09=09break; =09 } =09 case json_object_alist: @@ -1426,21 +1369,7 @@ json_parse_object (struct json_parser *parser) { case json_object_hashtable: { -=09EMACS_INT value =3D (parser->object_workspace_current - first) / 2; -=09result =3D make_hash_table (&hashtest_equal, value, Weak_None, false); -=09struct Lisp_Hash_Table *h =3D XHASH_TABLE (result); -=09for (size_t i =3D first; i < parser->object_workspace_current; i +=3D 2= ) -=09 { -=09 hash_hash_t hash; -=09 Lisp_Object key =3D parser->object_workspace[i]; -=09 Lisp_Object value =3D parser->object_workspace[i + 1]; -=09 ptrdiff_t i =3D hash_lookup_get_hash (h, key, &hash); -=09 if (i < 0) -=09 hash_put (h, key, value, hash); -=09 else -=09 set_hash_value_slot (h, i, value); -=09 } -=09parser->object_workspace_current =3D first; +=09result =3D Fhash_table_truncate (result); =09break; } case json_object_alist: --=20 2.47.0 From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 04 14:12:28 2024 Received: (at 74547) by debbugs.gnu.org; 4 Dec 2024 19:12:28 +0000 Received: from localhost ([127.0.0.1]:36877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tIunT-00027S-SH for submit@debbugs.gnu.org; Wed, 04 Dec 2024 14:12:28 -0500 Received: from mail-wm1-f49.google.com ([209.85.128.49]:61910) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tIunR-00027B-Na for 74547@debbugs.gnu.org; Wed, 04 Dec 2024 14:12:26 -0500 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-434a2f3bae4so1268905e9.3 for <74547@debbugs.gnu.org>; Wed, 04 Dec 2024 11:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733339480; x=1733944280; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=mpmkhUzcdeOzUPHmQpcHIwlYlYfvH/Rs/B8SK50Xycw=; b=hTMoMyLZ/Tg7UOBN9IYaA5HK8QiyQ6Sum/AaJTDi3XPxYhBefOZuPgJQdtAw6Bs3jK wcrJk71LIjpbw7IqtAea5VBYefGD+IyNPyTfmas0PfDbhB7YaOKJJgoZdkEkAYI+t/ZE uQ/cFYmVgeOYclLDkL7AD3PFfVOm3RllS8wQTWnFGYWSSvifSy1R5QoFIYbJk/sjI/U0 hcZMe3Htv+ba9rAzvqVn3FoQyFQUxbsGVZe2X4wyDQZO+abvLXVxnWP8c8GJTSPEk6Ff MokRUFowmQe9kZIwbnII6lEr3e+G9EretK+L62VVR/xpn+7dLGX56/bQ5Y3nHqSnsn0e MEEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733339480; x=1733944280; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mpmkhUzcdeOzUPHmQpcHIwlYlYfvH/Rs/B8SK50Xycw=; b=r9lFPyQ/FRB3Ji2trNV9XOK1Fwm8uo1er80EEBm7W/Ealr/67E25/nDFTSUgU7sAhO VEJn3uKwhWvN3NZkdJoRGJ8rGXryN5o+BflVajQY/XPbjw3EO8xS8gaSTntk60bKSYvw IrzaRu8CMFSRpnzbDlF27K8HA2uEQIRMQZpblD5EaRuEp2pT5OcLd6zBIOs8cJlZ+Ppc ddWtRMMf97ZclHmBtQGD2gtxXlMHJnV3bOSx01rjkHc2gKI2/2DEWwgkgF/eDYGIjqnb pcfhojcY9TUSyh2CQ74U0xDyUMICisWOYIRLPuNshXiyatQOSHzj3KFx+4pj6KrPp20t dHmw== X-Forwarded-Encrypted: i=1; AJvYcCX7yMXBqT66QoRkSkeCfDf+0aNHlSXlUNcMoJe6CvjHLErPHxtLZt0jBJww7h2l0lM5rVlwYg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxGkLMO5zeGXPjCYRzj9Hb8jkJl24avymKZh8gXJp2iO5ymIEYw 4M5cKhFWq0jPG0b8y6gBmwJ6kq/TUzbKXkQR0AzB5kBIfcayTjbC X-Gm-Gg: ASbGncuZNeObTvlsIZjpDQEkU26h8DvnAFs2mAysYAIcdpbUIallGnXEFtD2Ka5Teki 6+DU+wTp81nlT/67XHsU0rLBvlHYhMCtpdOj+JQN8FxHTByz5KLhb0iGwIiuh2gQmlLlZk6qi1B 5Fr2KD8r/5AY397UFfP+qwO7MPnePh1HHAsLvyvWKeSNqHcU42SfWRYJAzyP+YH7FZxPoPzhimR 2PdeuXAvZpuW/SwIifaFty9tscvppTCqkq+0keuGu9S8jBsmWHFqSGvYYmh1w7OI6/AyPiH9na5 s4HmWv4i X-Google-Smtp-Source: AGHT+IGbh47GsbAoVWy36vykRZir5dnKAzrEXNBzbElzIm8fkaOQML1NmOu8e2a17DWDeOgwK1boYg== X-Received: by 2002:a05:600c:45c9:b0:42c:b45d:4a7b with SMTP id 5b1f17b1804b1-434d0a03461mr63452565e9.25.1733339479571; Wed, 04 Dec 2024 11:11:19 -0800 (PST) Received: from [10.9.10.156] (62-77-231-86.static.invitel.hu. [62.77.231.86]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-434d52cbd42sm33694415e9.38.2024.12.04.11.11.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Dec 2024 11:11:19 -0800 (PST) Message-ID: <129c28f6-e3e3-47a1-b5a5-b59eac86df3d@gmail.com> Date: Wed, 4 Dec 2024 20:11:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c To: Pip Cet References: <87serdu9m3.fsf@telefonica.net> <875xo3mvqh.fsf@protonmail.com> <871pyrmui4.fsf@protonmail.com> <87wmgjlabu.fsf@protonmail.com> <87r06rl807.fsf@protonmail.com> <11705193-9151-43fb-9109-8a579e77d32b@gmail.com> <87cyibksuu.fsf@protonmail.com> Content-Language: en-US From: Geza Herman In-Reply-To: <87cyibksuu.fsf@protonmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74547 Cc: =?UTF-8?Q?Gerd_M=C3=B6llmann?= , 74547@debbugs.gnu.org, =?UTF-8?Q?=C3=93scar_Fuentes?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 12/1/24 22:15, Pip Cet wrote: > "Geza Herman" writes: >> On 12/1/24 16:48, Pip Cet wrote: >> Gerd M¶llmann writes: >> >> Back then, the future of the new GC was a question, so Gerd said >> (https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00544.html) >> that >> "Please don't take my GC efforts into consideration. That may succeed >> or not. But this is also a matter of good design, using the stack, >> (which BTW pdumper does, too), vs. bad design." That's why we went with >> the fastest implementation that doesn't use lisp vectors for storage. >> But we suspected that this JSON parser design will likely cause a >> problem with the new GC. So I think even if it turned out that the >> current problem was not caused by the parser, I still think that there >> should be something done about this JSON parser design to eliminate >> this potential problem. The lisp vector based approach was reverted >> because it added an extra pressure to the GC. For large JSON messages, >> it doesn't matter too much, but when the JSON is small, the extra GC >> time made the parser measurably slower. But, as far as I remember, that >> version hadn't have the small internal storage optimization yet. If we >> convert back to the vector based approach, the extra GC pressure will >> be smaller (compared to the original vector based approach without the >> internal storage), as for smaller sizes the vector won't be actually >> used. >> G©za > Thank you for the summary, that makes sense. Is there a standard corpus > of JSON documents that you use to benchmark the code? That would be very > helpful, I think, since Eli correctly points out JSON parsing > performance is critical. I'm not aware of such a corpus. When I developed the new JSON parser, the performance difference was so large so it was obvious that the new parser is faster. But I did benchmarks on JSONs which was generated by LSP communication (maybe I can share this one, if there is interest, but I need to anonymize it first), and also I did a benchmark on all the JSONs I found on my computer. But this time, the performance difference is expected to be smaller, using lisp vectors shouldn't have a very large effect on performance. I'd check the performance with small JSONs, but large enough ones where the (non-internal) object_workspace is actually get used (make sure to run a lot of iterations, so the amortized GC time will be included in the result). For larger JSONs, we shouldn't have a difference, as all the other allocations (which store the actual result of the parsing) should hide the additional lisp vector allocation cost. At least, this is my theory. > My gut feeling is that we should get rid of the object_workspace > entirely, instead modifying the general Lisp code to avoid performance > issues (and sacrifice some memory in the process, on most systems). object_workspace is only grown once for the lifetime of one parsing. Once it is grown to the needed size, the only extra cost when parsing a value is to copy the data to its final place from the object_workspace. Truncate based solution does the same copy, but it also needs to grow the hashtable/array for each value, so it executes more allocations and copies than the current solution. So I'd prefer if we kept object_workspace. If the only solution is to convert it to a lisp vector, then I think we should do that. But again, this is just my theory. If we try the truncate based solution, and if it turns out that it's not significantly slower, then it can be a good solution as well. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 22 05:29:41 2024 Received: (at 74547-done) by debbugs.gnu.org; 22 Dec 2024 10:29:41 +0000 Received: from localhost ([127.0.0.1]:49091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPJDR-0003ih-6S for submit@debbugs.gnu.org; Sun, 22 Dec 2024 05:29:41 -0500 Received: from relayout02-q01.e.movistar.es ([86.109.101.151]:39925) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPJDN-0003iK-4g for 74547-done@debbugs.gnu.org; Sun, 22 Dec 2024 05:29:39 -0500 Received: from relayout02-redir.e.movistar.es (relayout02-redir.e.movistar.es [86.109.101.202]) by relayout02-out.e.movistar.es (Postfix) with ESMTP id 4YGHT625H3zhYpD; Sun, 22 Dec 2024 11:29:30 +0100 (CET) Received: from sky (26.red-81-39-22.dynamicip.rima-tde.net [81.39.22.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout02.e.movistar.es (Postfix) with ESMTPSA id 4YGHT11vt9zdZTZ; Sun, 22 Dec 2024 11:29:25 +0100 (CET) From: =?utf-8?Q?=C3=93scar_Fuentes?= To: 74547-done@debbugs.gnu.org Subject: Re: bug#74547: 31.0.50; igc: assertion failed in buffer.c In-Reply-To: <129c28f6-e3e3-47a1-b5a5-b59eac86df3d@gmail.com> (Geza Herman's message of "Wed, 4 Dec 2024 20:11:18 +0100") References: <87serdu9m3.fsf@telefonica.net> <875xo3mvqh.fsf@protonmail.com> <871pyrmui4.fsf@protonmail.com> <87wmgjlabu.fsf@protonmail.com> <87r06rl807.fsf@protonmail.com> <11705193-9151-43fb-9109-8a579e77d32b@gmail.com> <87cyibksuu.fsf@protonmail.com> <129c28f6-e3e3-47a1-b5a5-b59eac86df3d@gmail.com> Date: Sun, 22 Dec 2024 11:29:24 +0100 Message-ID: <87seqgvwmz.fsf@telefonica.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-TnetOut-Country: IP: 81.39.22.26 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout02 X-TnetOut-MsgID: 4YGHT11vt9zdZTZ.A9F3A X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: oscarfv@telefonica.net X-TnetOut-Watermark: 1735468170.13452@nIlmgYZEivx0ekvGUgoZwQ X-Spam-Status: No X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74547-done Cc: Gerd =?utf-8?Q?M=C3=B6llmann?= , Pip Cet , Geza Herman X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) After extensive use, I can say with great confidence that this bug is fixed. Closing. Thanks to all. From unknown Tue Jun 24 03:27:40 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 19 Jan 2025 12:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator