bug#75477: 31.0.50; scratch/igc: crash on the latest commit

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Ihor Radchenko]

While waiting to see if bug#75292 has been fixed on the latest
scratch/igc. Is experiences Emacs hanging and even crashing when
creating a new frame.

I have managed to capture a backtrace today:

Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at emacs.c:432
432	{
(gdb) bt
#0  terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at emacs.c:432
#1  0x00005555556efeb5 in handle_fatal_signal (sig=sig@entry=11) at sysdep.c:1799
#2  0x00005555556eff22 in deliver_thread_signal (sig=11, handler=0x5555556efea3 <handle_fatal_signal>) at sysdep.c:1791
#3  deliver_fatal_thread_signal (sig=sig@entry=11) at sysdep.c:1811
#4  0x00005555556eff52 in handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at sysdep.c:1949
#5  0x00007ffff2c41100 in <signal handler called> () at /lib64/libc.so.6
#6  0x00007ffff2c412db in kill () at /lib64/libc.so.6
#7  0x0000555555893629 in sigHandle (sig=<optimized out>, info=<optimized out>, uap=<optimized out>) at /home/yantar92/Dist/mps/code/protsgix.c:114
#8  0x00007ffff2c41100 in <signal handler called> () at /lib64/libc.so.6
#9  scan_ambig (ss=0x7fffffffa6c8, start=<optimized out>, end=0x555596d238f0, closure=<optimized out>) at igc.c:1552
#10 0x0000555555888a98 in RootScan (ss=ss@entry=0x7fffffffa6c0, root=root@entry=0x7fff4d514550) at /home/yantar92/Dist/mps/code/root.c:540
#11 0x0000555555889315 in traceScanRootRes (ts=ts@entry=1, rank=rank@entry=0, arena=arena@entry=0x7ffff7fbe000, root=root@entry=0x7fff4d514550) at /home/yantar92/Dist/mps/code/trace.c:528
#12 0x0000555555889a31 in traceScanRoot (root=0x7fff4d514550, arena=0x7ffff7fbe000, rank=0, ts=<optimized out>) at /home/yantar92/Dist/mps/code/trace.c:545
#13 rootFlip (p=<synthetic pointer>, root=0x7fff4d514550) at /home/yantar92/Dist/mps/code/trace.c:580
#14 RootsIterate (p=<synthetic pointer>, f=<optimized out>, arena=0x7ffff7fbe008) at /home/yantar92/Dist/mps/code/root.c:665
#15 traceFlip (trace=0x7ffff7fbeaa8) at /home/yantar92/Dist/mps/code/trace.c:652
#16 TraceStart (trace=trace@entry=0x7ffff7fbeaa8, mortality=<optimized out>, finishingTime=<optimized out>) at /home/yantar92/Dist/mps/code/trace.c:1694
#17 0x000055555588a76f in PolicyStartTrace (traceReturn=traceReturn@entry=0x7fffffffa880, collectWorldReturn=collectWorldReturn@entry=0x7fffffffa8dc, arena=arena@entry=0x7ffff7fbe000, collectWorldAllowed=collectWorldAllowed@entry=1)
    at /home/yantar92/Dist/mps/code/policy.c:335
#18 0x000055555588cff2 in TracePoll (workReturn=workReturn@entry=0x7fffffffa8e0, collectWorldReturn=collectWorldReturn@entry=0x7fffffffa8dc, globals=globals@entry=0x7ffff7fbe008, collectWorldAllowed=1) at /home/yantar92/Dist/mps/code/trace.c:1840
#19 0x000055555588d19b in ArenaPoll (globals=globals@entry=0x7ffff7fbe008) at /home/yantar92/Dist/mps/code/global.c:745
#20 0x000055555588d58a in mps_ap_fill (p_o=p_o@entry=0x7fffffffaa50, mps_ap=mps_ap@entry=0x7fffe8001a40, size=size@entry=48) at /home/yantar92/Dist/mps/code/mpsi.c:1097
#21 0x00005555557de1a8 in alloc_impl (size=48, type=IGC_OBJ_STRING_DATA, ap=0x7fffe8001a40) at igc.c:3940
#22 0x00005555557de2cc in alloc (size=size@entry=44, type=type@entry=IGC_OBJ_STRING_DATA) at igc.c:3968
#23 0x00005555557e0d8c in alloc_string_data (nbytes=35, clear=false) at igc.c:4021
#24 igc_make_string (nchars=35, nbytes=35, unibyte=unibyte@entry=false, clear=clear@entry=false) at igc.c:4085
#25 0x00005555557e0dbc in igc_make_multibyte_string (nchars=<optimized out>, nbytes=<optimized out>, clear=clear@entry=false) at igc.c:4092
#26 0x0000555555735002 in make_clear_multibyte_string (nchars=nchars@entry=35, nbytes=nbytes@entry=35, clearit=clearit@entry=false) at alloc.c:2669
#27 0x0000555555735021 in make_clear_string (length=length@entry=35, clearit=clearit@entry=false) at alloc.c:2641
#28 0x0000555555735917 in make_uninit_string (length=length@entry=35) at alloc.c:2652
#29 0x00005555557649ec in concat_to_string (nargs=2, args=0x7fffffffabf8) at fns.c:938
#30 0x0000555555764e46 in Fconcat (nargs=<optimized out>, args=<optimized out>) at fns.c:750
#31 0x00007fffdfe7529b in F7365742d666163652d6174747269627574652d66726f6d2d7265736f75726365_set_face_attribute_from_resource_0 () at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/faces-b9447c93-66d43d26.eln
#32 0x0000555555759184 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=5, args=args@entry=0x7fffffffad68) at eval.c:3184
#33 0x000055555575b20c in funcall_general (fun=<optimized out>, numargs=numargs@entry=5, args=args@entry=0x7fffffffad68) at /home/yantar92/Git/emacs/src/lisp.h:2332
#34 0x0000555555757318 in Ffuncall (nargs=6, args=0x7fffffffad60) at eval.c:3108
#35 0x00007fffdfe75502 in F7365742d666163652d617474726962757465732d66726f6d2d7265736f7572636573_set_face_attributes_from_resources_0 () at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/faces-b9447c93-66d43d26.eln
#36 0x0000555555759133 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffffaed8) at eval.c:3178
#37 0x000055555575b20c in funcall_general (fun=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffffaed8) at /home/yantar92/Git/emacs/src/lisp.h:2332
#38 0x0000555555757318 in Ffuncall (nargs=3, args=0x7fffffffaed0) at eval.c:3108
#39 0x00007fffdfe757ca in F6d616b652d666163652d782d7265736f757263652d696e7465726e616c_make_face_x_resource_internal_0 () at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/faces-b9447c93-66d43d26.eln
#40 0x0000555555759133 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffffb0d8) at eval.c:3178
#41 0x000055555575b20c in funcall_general (fun=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffffb0d8) at /home/yantar92/Git/emacs/src/lisp.h:2332
#42 0x0000555555757318 in Ffuncall (nargs=3, args=0x7fffffffb0d0) at eval.c:3108
#43 0x00007fffdfe7c57b in F666163652d737065632d726563616c63_face_spec_recalc_0 () at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/faces-b9447c93-66d43d26.eln
#44 0x0000555555759133 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffffb438) at eval.c:3178
#45 0x000055555575b20c in funcall_general (fun=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffffb438) at /home/yantar92/Git/emacs/src/lisp.h:2332
#46 0x0000555555757318 in Ffuncall (nargs=3, args=0x7fffffffb430) at eval.c:3108
#47 0x00007fffdfe7ee73 in F782d6372656174652d6672616d652d776974682d6661636573_x_create_frame_with_faces_0 () at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/faces-b9447c93-66d43d26.eln
#48 0x0000555555759120 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffdedff0d0) at eval.c:3176
#49 0x00005555557a00af in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, args_template@entry=257, nargs=<optimized out>, nargs@entry=1, args=<optimized out>, args@entry=0x7fffdedff050) at /home/yantar92/Git/emacs/src/lisp.h:2332
#50 0x000055555575ad08 in funcall_lambda (fun=XIL(0x7fff5fa1e9d5), nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffdedff050) at eval.c:3267
#51 0x000055555575b0bd in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffdedff050) at eval.c:3059
#52 0x0000555555757318 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffdedff048) at eval.c:3108
#53 0x00005555557575fe in Fapply (nargs=2, args=0x7fffdedff048) at eval.c:2737
#54 0x000055555575920e in funcall_subr (subr=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffdedff048) at eval.c:3199
#55 0x00005555557a00af in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, args_template@entry=128, nargs=<optimized out>, nargs@entry=1, args=<optimized out>, args@entry=0x7fffffffb9c8) at /home/yantar92/Git/emacs/src/lisp.h:2332
#56 0x000055555575ad08 in funcall_lambda (fun=XIL(0x7fff4ba7330d), nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffffb9c8) at eval.c:3267
#57 0x000055555575b0bd in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffffb9c8) at eval.c:3059
#58 0x0000555555757318 in Ffuncall (nargs=2, args=0x7fffffffb9c0) at eval.c:3108
#59 0x00007fffdfc12ed6 in F6d616b652d6672616d65_make_frame_0 () at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/frame-b40fc590-5b61451b.eln
#60 0x0000555555759120 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffffbb88) at eval.c:3176
#61 0x000055555575b20c in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffffbb88) at /home/yantar92/Git/emacs/src/lisp.h:2332
#62 0x0000555555757318 in Ffuncall (nargs=2, args=0x7fffffffbb80) at eval.c:3108
#63 0x00007fffdc3878be in F7365727665722d2d6372656174652d6672616d65_server__create_frame_0 () at /home/yantar92/.emacs.d/eln-cache/31.0.50-fc0e2b3f/server-0cc44189-5626429c.eln
#64 0x000055555575914a in funcall_subr (subr=<optimized out>, numargs=numargs@entry=3, args=args@entry=0x7fffffffbdb0) at eval.c:3180
#65 0x000055555575b20c in funcall_general (fun=<optimized out>, numargs=numargs@entry=3, args=args@entry=0x7fffffffbdb0) at /home/yantar92/Git/emacs/src/lisp.h:2332
#66 0x0000555555757318 in Ffuncall (nargs=4, args=0x7fffffffbda8) at eval.c:3108
#67 0x00007fffdc38753d in F7365727665722d6372656174652d77696e646f772d73797374656d2d6672616d65_server_create_window_system_frame_0 () at /home/yantar92/.emacs.d/eln-cache/31.0.50-fc0e2b3f/server-0cc44189-5626429c.eln
#68 0x0000555555759184 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=5, args=args@entry=0x7fffffffbfb8) at eval.c:3184
#69 0x000055555575b20c in funcall_general (fun=<optimized out>, numargs=numargs@entry=5, args=args@entry=0x7fffffffbfb8) at /home/yantar92/Git/emacs/src/lisp.h:2332
--Type <RET> for more, q to quit, c to continue without paging--
#70 0x0000555555757318 in Ffuncall (nargs=6, args=0x7fffffffbfb0) at eval.c:3108
#71 0x00007fffdc38988c in F7365727665722d2d70726f636573732d66696c7465722d31_server__process_filter_1_0 () at /home/yantar92/.emacs.d/eln-cache/31.0.50-fc0e2b3f/server-0cc44189-5626429c.eln
#72 0x0000555555759133 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffffc148) at eval.c:3178
#73 0x000055555575b20c in funcall_general (fun=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffffc148) at /home/yantar92/Git/emacs/src/lisp.h:2332
#74 0x0000555555757318 in Ffuncall (nargs=3, args=0x7fffffffc140) at eval.c:3108
#75 0x00007fffdc38809b in F7365727665722d2d70726f636573732d66696c7465722d616c6c2d70656e64696e67_server__process_filter_all_pending_0 () at /home/yantar92/.emacs.d/eln-cache/31.0.50-fc0e2b3f/server-0cc44189-5626429c.eln
#76 0x0000555555759114 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=0, args=args@entry=0x7fffffffc290) at eval.c:3174
#77 0x000055555575b20c in funcall_general (fun=<optimized out>, numargs=numargs@entry=0, args=args@entry=0x7fffffffc290) at /home/yantar92/Git/emacs/src/lisp.h:2332
#78 0x0000555555757318 in Ffuncall (nargs=1, args=0x7fffffffc288) at eval.c:3108
#79 0x00007fffdc387f3e in F7365727665722d70726f636573732d66696c746572_server_process_filter_0 () at /home/yantar92/.emacs.d/eln-cache/31.0.50-fc0e2b3f/server-0cc44189-5626429c.eln
#80 0x0000555555759133 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffffc3c8) at eval.c:3178
#81 0x000055555575b20c in funcall_general (fun=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffffc3c8) at /home/yantar92/Git/emacs/src/lisp.h:2332
#82 0x0000555555757318 in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7fffffffc3c0) at eval.c:3108
#83 0x000055555575786f in Fapply (nargs=nargs@entry=2, args=args@entry=0x7fffffffc460) at eval.c:2780
#84 0x000055555575794c in apply1 (fn=<optimized out>, arg=<optimized out>) at eval.c:2996
#85 0x00005555557ac94f in read_process_output_call (fun_and_args=fun_and_args@entry=XIL(0x7fff5845b603)) at process.c:6148
#86 0x0000555555755cde in internal_condition_case_1 (bfun=bfun@entry=0x5555557ac936 <read_process_output_call>, arg=XIL(0x7fff5845b603), handlers=handlers@entry=XIL(0), hfun=hfun@entry=0x5555557ac887 <read_process_output_error_handler>) at eval.c:1651
#87 0x00005555557af7a6 in read_and_dispose_of_process_output (p=<optimized out>, chars=<optimized out>, nbytes=3596, coding=<optimized out>) at process.c:6517
#88 read_process_output (proc=proc@entry=XIL(0x7fff5845ad15), channel=channel@entry=16) at process.c:6285
#89 0x00005555557b79b4 in wait_reading_process_output (time_limit=time_limit@entry=0, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=true, wait_for_cell=wait_for_cell@entry=XIL(0), wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:5966
#90 0x00005555556deaec in kbd_buffer_get_event (kbp=<synthetic pointer>, used_mouse_menu=0x7fffffffcfeb, end_time=0x0) at keyboard.c:4115
#91 read_event_from_main_queue (end_time=end_time@entry=0x0, local_getcjmp=local_getcjmp@entry=0x7fffffffccc0, used_mouse_menu=used_mouse_menu@entry=0x7fffffffcfeb) at keyboard.c:2336
#92 0x00005555556e175d in read_decoded_event_from_main_queue (end_time=<optimized out>, local_getcjmp=<optimized out>, prev_event=<optimized out>, used_mouse_menu=<optimized out>) at keyboard.c:2399
#93 read_char (commandflag=1, map=map@entry=XIL(0x7fff57ea9de3), prev_event=XIL(0), used_mouse_menu=used_mouse_menu@entry=0x7fffffffcfeb, end_time=end_time@entry=0x0) at keyboard.c:3031
#94 0x00005555556e2ced in read_key_sequence
    (keybuf=keybuf@entry=0x7fffffffd140, prompt=prompt@entry=XIL(0), dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, disable_text_conversion_p=false) at keyboard.c:10763
#95 0x00005555556e4e77 in command_loop_1 () at keyboard.c:1435
#96 0x0000555555755c66 in internal_condition_case (bfun=bfun@entry=0x5555556e4985 <command_loop_1>, handlers=handlers@entry=XIL(0xa8), hfun=hfun@entry=0x5555556d58f0 <cmd_error>) at eval.c:1627
#97 0x00005555556d0707 in command_loop_2 (handlers=handlers@entry=XIL(0xa8)) at keyboard.c:1174
#98 0x0000555555755ba1 in internal_catch (tag=tag@entry=XIL(0x153f0), func=func@entry=0x5555556d06d7 <command_loop_2>, arg=arg@entry=XIL(0xa8)) at eval.c:1306
#99 0x00005555556d06b4 in command_loop () at keyboard.c:1152
#100 0x00005555556d5465 in recursive_edit_1 () at keyboard.c:760
#101 0x00005555556d580b in Frecursive_edit () at keyboard.c:843
#102 0x00005555556cf92b in main (argc=1, argv=0x7fffffffd5d8) at emacs.c:2658

Lisp Backtrace:
"set-face-attribute-from-resource" (0xffffad68)
"set-face-attributes-from-resources" (0xffffaed8)
"make-face-x-resource-internal" (0xffffb0d8)
"face-spec-recalc" (0xffffb438)
"x-create-frame-with-faces" (0xdedff0d0)
0x5fa1e9d0 PVEC_CLOSURE
"apply" (0xdedff048)
"frame-creation-function" (0xffffb9c8)
"make-frame" (0xffffbb88)
"server--create-frame" (0xffffbdb0)
"server-create-window-system-frame" (0xffffbfb8)
"server--process-filter-1" (0xffffc148)
"server--process-filter-all-pending" (0xffffc290)
"server-process-filter" (0xffffc3c8)

In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.42, cairo version 1.18.2) of 2025-01-10 built on localhost
Repository revision: 9f8bebddf3ae90558e7e87e192007c74f7cc9e0b
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101014
System Description: Gentoo Linux

Configured using:
 'configure --with-mps=yes --with-native-compilation 'CFLAGS=-g3
 -I/opt/mps/include -L/opt/mps/lib'
 JAVAC=/etc/java-config-2/current-system-vm/bin/javac
 PKG_CONFIG_PATH=/usr/share/guile-data/3.0/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG
LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM
XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors]

"Ihor Radchenko" <yantar92@posteo.net> writes:

> While waiting to see if bug#75292 has been fixed on the latest
> scratch/igc. Is experiences Emacs hanging and even crashing when
> creating a new frame.

Thanks for the report!  Think I found it.

> I have managed to capture a backtrace today:
>
> Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at emacs.c:432
> 432	{
> (gdb) bt
> #0  terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at emacs.c:432
> #1  0x00005555556efeb5 in handle_fatal_signal (sig=sig@entry=11) at sysdep.c:1799
> #2  0x00005555556eff22 in deliver_thread_signal (sig=11, handler=0x5555556efea3 <handle_fatal_signal>) at sysdep.c:1791
> #3  deliver_fatal_thread_signal (sig=sig@entry=11) at sysdep.c:1811
> #4  0x00005555556eff52 in handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at sysdep.c:1949
> #5  0x00007ffff2c41100 in <signal handler called> () at /lib64/libc.so.6
> #6  0x00007ffff2c412db in kill () at /lib64/libc.so.6
> #7  0x0000555555893629 in sigHandle (sig=<optimized out>, info=<optimized out>, uap=<optimized out>) at /home/yantar92/Dist/mps/code/protsgix.c:114
> #8  0x00007ffff2c41100 in <signal handler called> () at /lib64/libc.so.6
> #9  scan_ambig (ss=0x7fffffffa6c8, start=<optimized out>, end=0x555596d238f0, closure=<optimized out>) at igc.c:1552

We were asked to scan memory ending at 0x555596d238f0 (the start address
was optimized out), which we had registered as an ambiguous root, but
the scan function segfaulted; most likely, the memory we scanned was not
mapped (or no longer mapped).

My first suspect was the framep area we allocate for the X widget, but
that's an 8-byte area allocated with malloc: therefore, it's 16-byte
aligned, so the end address would have to end in 8 rather than 0.

The GTK code creates a lot of temporary roots, most of them by using
igc_xzalloc_ambig (8): again, it's very unlikely one of those is our
culprit because of the aligned end pointer.

So it must be a different object.  So far, what I've found was:

void
xg_free_frame_widgets (struct frame *f)
{
  if (FRAME_GTK_OUTER_WIDGET (f))
    {
      xp_output *x = f->output_data.xp;
      struct xg_frame_tb_info *tbinfo
        = g_object_get_data (G_OBJECT (FRAME_GTK_OUTER_WIDGET (f)),
                             TB_INFO_KEY);
      if (tbinfo)
        xfree (tbinfo);

which calls xfree() on a pointer that was obtained with igc_xzalloc.
Definitely a bug, usually a harmless one, except in the very rare case
that xfree unmaps memory rather than merely putting it on the free list.

That would match the alignment, and it would explain the bug if we hit
one of the (very rare; almost impossible if malloc uses sbrk, unlikely
if malloc uses mmap) cases in which xfree actually unmaps memory rather
than merely putting the block on the free list.

But this function is called during frame deletion, not frame creation.
Did you delete any frames in this session?

Pip

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Ihor Radchenko]

Pip Cet <pipcet@protonmail.com> writes:

> But this function is called during frame deletion, not frame creation.
> Did you delete any frames in this session?

I constantly create and delete frames as a part of my Emacs usage.

Although, right after the crash, when I ran Emacs again, and tried to
create an extra frame (to report this bug), Emacs crashed again. I did
not delete frames that time.
(But that particular crash may or may not be the same with what I
reported; I did not run gdb that time)

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Gerd Möllmann]

Ihor Radchenko <yantar92@posteo.net> writes:

> Pip Cet <pipcet@protonmail.com> writes:
>
>> But this function is called during frame deletion, not frame creation.
>> Did you delete any frames in this session?
>
> I constantly create and delete frames as a part of my Emacs usage.
>
> Although, right after the crash, when I ran Emacs again, and tried to
> create an extra frame (to report this bug), Emacs crashed again. I did
> not delete frames that time.
> (But that particular crash may or may not be the same with what I
> reported; I did not run gdb that time)

Don't know if that helps, but M-x igc-root-stats can be used to display
information about known roots. Maybe one can see there if the number of
roots increases over time, which would indicate if there is something
like a "root leak", for example by using xfree instead of igc_xfree.

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Ihor Radchenko]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Don't know if that helps, but M-x igc-root-stats can be used to display
> information about known roots. Maybe one can see there if the number of
> roots increases over time, which would indicate if there is something
> like a "root leak", for example by using xfree instead of igc_xfree.

I noticed that creating a new frame took longer and longer over time
recently. Up to a dozen of seconds.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Gerd Möllmann]

Ihor Radchenko <yantar92@posteo.net> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Don't know if that helps, but M-x igc-root-stats can be used to display
>> information about known roots. Maybe one can see there if the number of
>> roots increases over time, which would indicate if there is something
>> like a "root leak", for example by using xfree instead of igc_xfree.
>
> I noticed that creating a new frame took longer and longer over time
> recently. Up to a dozen of seconds.

M-x igc-stats could perhaps also be useful to see if objects accumulate
over time.

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors]

"Ihor Radchenko" <yantar92@posteo.net> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Don't know if that helps, but M-x igc-root-stats can be used to display
>> information about known roots. Maybe one can see there if the number of
>> roots increases over time, which would indicate if there is something
>> like a "root leak", for example by using xfree instead of igc_xfree.
>
> I noticed that creating a new frame took longer and longer over time
> recently. Up to a dozen of seconds.

Thanks! Trying to reproduce that here with:

./src/emacs -Q --eval '(run-with-timer 1.0 1.0 (lambda () (delete-frame (make-frame))))'

indicates 8 xzalloc-ambig roots apparently leaked per frame created
(after the fix I just pushed).  Ouch.  Even if we xfree() those, that's
a great number of heap words incorrectly declared to be ambiguous roots,
which may hide other bugs.

No apparent leak with --with-x-toolkit=no, so we know where to look.

Maybe we should move to a new bug for that?  I think xfree should check
it is not called on an IGC root, and we may want to record the __LINE__
where igc_xzalloc_ambig is called.

Pip

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Pip Cet <pipcet@protonmail.com> writes:

> "Ihor Radchenko" <yantar92@posteo.net> writes:
>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>>> Don't know if that helps, but M-x igc-root-stats can be used to display
>>> information about known roots. Maybe one can see there if the number of
>>> roots increases over time, which would indicate if there is something
>>> like a "root leak", for example by using xfree instead of igc_xfree.
>>
>> I noticed that creating a new frame took longer and longer over time
>> recently. Up to a dozen of seconds.
>
> Thanks! Trying to reproduce that here with:
>
> ./src/emacs -Q --eval '(run-with-timer 1.0 1.0 (lambda () (delete-frame (make-frame))))'
>
> indicates 8 xzalloc-ambig roots apparently leaked per frame created
> (after the fix I just pushed).  Ouch.  Even if we xfree() those, that's
> a great number of heap words incorrectly declared to be ambiguous roots,
> which may hide other bugs.
>
> No apparent leak with --with-x-toolkit=no, so we know where to look.

Or not.  It's down to one leak/frame now, which is still bad, but I
thought I'd push the partial fix for now.  If the latest commit causes
abort()s, please consider reporting them rather than simply reverting
the commit :-)

Pip

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Ihor Radchenko]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> M-x igc-stats could perhaps also be useful to see if objects accumulate
> over time.

What is it supposed to do?
It always shows an empty buffer for me.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors]

"Ihor Radchenko" <yantar92@posteo.net> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> M-x igc-stats could perhaps also be useful to see if objects accumulate
>> over time.
>
> What is it supposed to do?
> It always shows an empty buffer for me.

Hit 's' (repeatedly).

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Ihor Radchenko]

Pip Cet <pipcet@protonmail.com> writes:

>>> M-x igc-stats could perhaps also be useful to see if objects accumulate
>>> over time.
>>
>> What is it supposed to do?
>> It always shows an empty buffer for me.
>
> Hit 's' (repeatedly).

CPU load increases. That's all.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors]

"Ihor Radchenko" <yantar92@posteo.net> writes:

> Pip Cet <pipcet@protonmail.com> writes:
>
>>>> M-x igc-stats could perhaps also be useful to see if objects accumulate
>>>> over time.
>>>
>>> What is it supposed to do?
>>> It always shows an empty buffer for me.
>>
>> Hit 's' (repeatedly).
>
> CPU load increases. That's all.

Weird.  Always worked here.  Does M-x igc-snapshot work?  Or M-x
igc--roots-snapshot ? (Note: double dash for the latter).

(igc.el uses display-buffer, not switch-to-buffer.  Maybe we should
change that if it causes problems?)

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Ihor Radchenko]

Pip Cet <pipcet@protonmail.com> writes:

> Weird.  Always worked here.  Does M-x igc-snapshot work?  Or M-x
> igc--roots-snapshot ? (Note: double dash for the latter).

No, and no.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Ihor Radchenko]

Pip Cet <pipcet@protonmail.com> writes:

>> CPU load increases. That's all.
>
> Weird.  Always worked here.  Does M-x igc-snapshot work?  Or M-x
> igc--roots-snapshot ? (Note: double dash for the latter).

Just checked with emacs -Q and it is working there. Something in my config...

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Pip Cet <pipcet@protonmail.com> writes:

> Pip Cet <pipcet@protonmail.com> writes:
>
>> "Ihor Radchenko" <yantar92@posteo.net> writes:
>>
>>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>>
>>>> Don't know if that helps, but M-x igc-root-stats can be used to display
>>>> information about known roots. Maybe one can see there if the number of
>>>> roots increases over time, which would indicate if there is something
>>>> like a "root leak", for example by using xfree instead of igc_xfree.
>>>
>>> I noticed that creating a new frame took longer and longer over time
>>> recently. Up to a dozen of seconds.
>>
>> Thanks! Trying to reproduce that here with:
>>
>> ./src/emacs -Q --eval '(run-with-timer 1.0 1.0 (lambda () (delete-frame (make-frame))))'
>>
>> indicates 8 xzalloc-ambig roots apparently leaked per frame created
>> (after the fix I just pushed).  Ouch.  Even if we xfree() those, that's
>> a great number of heap words incorrectly declared to be ambiguous roots,
>> which may hide other bugs.
>>
>> No apparent leak with --with-x-toolkit=no, so we know where to look.
>
> Or not.  It's down to one leak/frame now, which is still bad, but I

It's weird bug day: I'm seeing one leak/frame sometimes, sometimes it's
two leaks/frame, and I expected the following patch to give me a unique
call chain to a root that isn't freed:

diff --git a/src/igc.c b/src/igc.c
index f034aae9460..cac9cd5501c 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -858,6 +858,7 @@ igc_check_fwd (void *client, bool is_vector)
   void *start, *end;
   const char *label;
   bool ambig;
+  void *caller[4];
 };
 
 typedef struct igc_root igc_root;
@@ -3217,7 +3218,11 @@ igc_xzalloc_ambig (size_t size)
   void *end = (char *) p + size;
   if (end == p)
     end = (char *) p + IGC_ALIGN_DFLT;
-  root_create_ambig (global_igc, p, end, "xzalloc-ambig");
+  struct igc_root_list *r = root_create_ambig (global_igc, p, end, "xzalloc-ambig");
+  r->d.caller[0] = __builtin_return_address (0);
+  r->d.caller[1] = __builtin_return_address (1);
+  r->d.caller[2] = __builtin_return_address (2);
+  r->d.caller[3] = __builtin_return_address (3);
   return p;
 }
 

However, while I do see what I think are the 100 leaks after running

./src/emacs -Q --eval '(dotimes (i 100) (delete-frame (make-frame)))'

they have different call chains.

I'm using

p global_igc->roots[0]
while 1
p *$.next
end

in GDB, and I was expecting the leaked roots to be among the first
values printed.

Is there something obvious I'm doing wrong?  Or are we really creating
menuitems in such a way that we usually leak one, but it's random which
one?

Pip

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Gerd Möllmann]

Ihor Radchenko <yantar92@posteo.net> writes:

> Pip Cet <pipcet@protonmail.com> writes:
>
>>> CPU load increases. That's all.
>>
>> Weird.  Always worked here.  Does M-x igc-snapshot work?  Or M-x
>> igc--roots-snapshot ? (Note: double dash for the latter).
>
> Just checked with emacs -Q and it is working there. Something in my config...

The stats buffers work like this: there are 3 displays A, B, and D.
A and B are snapshots which one can take with 's'. D shows the
difference between A and B. 'a', 'b', and 'd' to switch between A, B, D.
'? for help. And certainly something I don't think of at the moement.

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Ihor Radchenko]

Ihor Radchenko <yantar92@posteo.net> writes:

>> Weird.  Always worked here.  Does M-x igc-snapshot work?  Or M-x
>> igc--roots-snapshot ? (Note: double dash for the latter).
>
> Just checked with emacs -Q and it is working there. Something in my config...
>

... or not. Fresh Emacs did show something in that buffer.

I figured that I automatically used M-r (revert-buffer) and that emptied
the buffer.

After trying to kill it, next invocation of M-x igc-root-stats gave me

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  (igc--roots-diff (("committed" 1 509386752 0) ("commit-limit" 1 -1 0) ("spare-committed" 1 316694528 0) ("reserved" 1 805310464 0) ("spare" nil 0.75 nil) ("pause-time" nil 0.1 nil) ("PVEC_FONT" 8280 1041320 312) ("PVEC_RECORD" 9782 646936 472) ("PVEC_SUB_CHAR_TABLE" 11983 11089896 1048) ("PVEC_CHAR_TABLE" 604 348472 656) ("PVEC_CLOSURE" 37132 1968992 64) ("PVEC_SQLITE" 0 0 0) ("PVEC_TS_COMPILED_QUERY" 0 0 0) ("PVEC_TS_NODE" 0 0 0) ("PVEC_TS_PARSER" 0 0 0) ("PVEC_NATIVE_COMP_UNIT" 725 127600 176) ("PVEC_MODULE_GLOBAL_REFERENCE" 52 1664 32) ("PVEC_MODULE_FUNCTION" 9 720 80) ("PVEC_CONDVAR" 0 0 0) ("PVEC_MUTEX" 0 0 0) ("PVEC_THREAD" 0 0 0) ("PVEC_XWIDGET_VIEW" 0 0 0) ("PVEC_XWIDGET" 0 0 0) ("PVEC_OTHER" 1 80 80) ("PVEC_SUBR" 50250 4824000 96) ("PVEC_WINDOW_CONFIGURATION" 8 960 120) ("PVEC_TERMINAL" 1 552 552) ("PVEC_OBARRAY" 166 5312 32) ("PVEC_WEAK_HASH_TABLE" 26 1040 40) ("PVEC_HASH_TABLE" 5505 484440 88) ("PVEC_BUFFER" 194 192448 992) ("PVEC_BOOL_VECTOR" 429 17152 40) ("PVEC_WINDOW" 23 12696 552) ("PVEC_FRAME" 1 664 664) ("PVEC_PROCESS" 2 752 376) ("PVEC_USER_PTR" 0 0 0) ("PVEC_MISC_PTR" 0 0 0) ("PVEC_SYMBOL_WITH_POS" 0 0 0) ("PVEC_FINALIZER" 0 0 0) ("PVEC_OVERLAY" 361 14440 40) ("PVEC_MARKER" 5118 286608 56) ("PVEC_BIGNUM" 234 7488 32) ("PVEC_FREE" 493 18376 312) ("PVEC_NORMAL_VECTOR" 81105 12569104 1048592) ("IGC_OBJ_WEAK_HASH_TABLE_STRONG_PART" 26 283792 82784) ("IGC_OBJ_WEAK_HASH_TABLE_WEAK_PART" 26 64912 16656) ("IGC_OBJ_DUMPED_BYTES" 1 19520 19520) ("IGC_OBJ_DUMPED_BIGNUM_DATA" 0 0 0) ("IGC_OBJ_DUMPED_BUFFER_TEXT" 0 0 0) ("IGC_OBJ_DUMPED_CODE_SPACE_MASKS" 1 10248 10248) ...) (("committed" 1 509386752 0) ("commit-limit" 1 -1 0) ("spare-committed" 1 323715072 0) ("reserved" 1 805310464 0) ("spare" nil 0.75 nil) ("pause-time" nil 0.1 nil) ("PVEC_FONT" 8280 1041320 312) ("PVEC_RECORD" 9755 644808 472) ("PVEC_SUB_CHAR_TABLE" 11983 11089896 1048) ("PVEC_CHAR_TABLE" 603 347848 656) ("PVEC_CLOSURE" 34530 1829304 64) ("PVEC_SQLITE" 0 0 0) ("PVEC_TS_COMPILED_QUERY" 0 0 0) ("PVEC_TS_NODE" 0 0 0) ("PVEC_TS_PARSER" 0 0 0) ("PVEC_NATIVE_COMP_UNIT" 725 127600 176) ("PVEC_MODULE_GLOBAL_REFERENCE" 52 1664 32) ("PVEC_MODULE_FUNCTION" 9 720 80) ("PVEC_CONDVAR" 0 0 0) ("PVEC_MUTEX" 0 0 0) ("PVEC_THREAD" 0 0 0) ("PVEC_XWIDGET_VIEW" 0 0 0) ("PVEC_XWIDGET" 0 0 0) ("PVEC_OTHER" 1 80 80) ("PVEC_SUBR" 50250 4824000 96) ("PVEC_WINDOW_CONFIGURATION" 5 600 120) ("PVEC_TERMINAL" 1 552 552) ("PVEC_OBARRAY" 166 5312 32) ("PVEC_WEAK_HASH_TABLE" 26 1040 40) ("PVEC_HASH_TABLE" 5502 484176 88) ("PVEC_BUFFER" 126 124992 992) ("PVEC_BOOL_VECTOR" 429 17152 40) ("PVEC_WINDOW" 17 9384 552) ("PVEC_FRAME" 1 664 664) ("PVEC_PROCESS" 2 752 376) ("PVEC_USER_PTR" 0 0 0) ("PVEC_MISC_PTR" 0 0 0) ("PVEC_SYMBOL_WITH_POS" 0 0 0) ("PVEC_FINALIZER" 0 0 0) ("PVEC_OVERLAY" 327 13080 40) ("PVEC_MARKER" 3783 211848 56) ("PVEC_BIGNUM" 200 6400 32) ("PVEC_FREE" 493 18376 312) ("PVEC_NORMAL_VECTOR" 78251 12435208 1048592) ("IGC_OBJ_WEAK_HASH_TABLE_STRONG_PART" 26 283792 82784) ("IGC_OBJ_WEAK_HASH_TABLE_WEAK_PART" 26 64912 16656) ("IGC_OBJ_DUMPED_BYTES" 1 19520 19520) ("IGC_OBJ_DUMPED_BIGNUM_DATA" 0 0 0) ("IGC_OBJ_DUMPED_BUFFER_TEXT" 0 0 0) ("IGC_OBJ_DUMPED_CODE_SPACE_MASKS" 1 10248 10248) ...))
  (igc--roots-info-to-display)
  (igc-roots-stats)
  (funcall-interactively igc-roots-stats)
  (command-execute igc-roots-stats record)
  (execute-extended-command nil "igc-roots-stats" nil)
  (funcall-interactively execute-extended-command nil "igc-roots-stats" nil)
  (command-execute execute-extended-command)

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#75477: 31.0.50; scratch/igc: crash on the latest commit

[Ihor Radchenko]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> The stats buffers work like this: there are 3 displays A, B, and D.
> A and B are snapshots which one can take with 's'. D shows the
> difference between A and B. 'a', 'b', and 'd' to switch between A, B, D.
> '? for help. And certainly something I don't think of at the moement.

I guess that explains a lot. But then just doing M-x igc-root-stats is
not enough to see anything. Need more detailed instructions.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>