bug#63495: 28.2; menu crashes on macos

bug#63495: 28.2; menu crashes on macos

[David O'Brien]

When using the menu - I can call up and see the menu, but if I try to
select a menu item this always results in emacs crashing.
I copy in below the system message



-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               Emacs-x86_64-10_14 [58491]
Path:                  /Applications/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14
Identifier:            Emacs-x86_64-10_14
Version:               ???
Code Type:             X86-64 (Native)
Parent Process:        launchd [1]
User ID:               501

Date/Time:             2023-05-13 08:35:25.5733 -0700
OS Version:            macOS 12.6.3 (21G419)
Report Version:        12
Bridge OS Version:     7.2 (20P3045)
Anonymous UUID:        CCCDA783-D27E-114E-B131-A9A0ED385750

Sleep/Wake UUID:       E3FB27AC-1DF3-4DC0-A485-251164CADFAD

Time Awake Since Boot: 300000 seconds
Time Since Wake:       1362 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGABRT)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000003
Exception Codes:       0x0000000000000001, 0x0000000000000003
Exception Note:        EXC_CORPSE_NOTIFY

VM Region Info: 0x3 is not in any region.  Bytes before following region: 140737488134141
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->  
      VM_ALLOCATE              7ffffffca000-7ffffffcb000 [    4K] r-x/r-x SM=ALI  

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	    0x7ff81d85e00e __pthread_kill + 10
1   libsystem_pthread.dylib       	    0x7ff81d8941ff pthread_kill + 263
2   libsystem_c.dylib             	    0x7ff81d7a22d8 raise + 26
3   Emacs-x86_64-10_14            	       0x105374a3a terminate_due_to_signal + 170
4   Emacs-x86_64-10_14            	       0x1053753ab emacs_abort + 15
5   Emacs-x86_64-10_14            	       0x10533a7f0 ns_term_shutdown + 80
6   Emacs-x86_64-10_14            	       0x105224084 shut_down_emacs + 340
7   Emacs-x86_64-10_14            	       0x105374a07 terminate_due_to_signal + 119
8   Emacs-x86_64-10_14            	       0x10524494e handle_fatal_signal + 14
9   Emacs-x86_64-10_14            	       0x1052449d1 deliver_thread_signal + 129
10  Emacs-x86_64-10_14            	       0x1052430d9 deliver_fatal_thread_signal + 9
11  Emacs-x86_64-10_14            	       0x105244a88 handle_sigsegv + 168
12  libsystem_platform.dylib      	    0x7ff81d8a9dfd _sigtramp + 29
13  ???                           	               0x0 ???
14  Emacs-x86_64-10_14            	       0x105356ed1 -[EmacsMenu runMenuAt:forFrame:keymaps:] + 321
15  Emacs-x86_64-10_14            	       0x105357476 ns_menu_show + 1414
16  Emacs-x86_64-10_14            	       0x1051c1e4f x_popup_menu_1 + 1439
17  Emacs-x86_64-10_14            	       0x1052b4b01 funcall_subr + 257
18  Emacs-x86_64-10_14            	       0x1052b40eb Ffuncall + 843
19  Emacs-x86_64-10_14            	       0x1052fa41b exec_byte_code + 1675
20  Emacs-x86_64-10_14            	       0x1052b4089 Ffuncall + 745
21  Emacs-x86_64-10_14            	       0x1052fa41b exec_byte_code + 1675
22  Emacs-x86_64-10_14            	       0x1052b4089 Ffuncall + 745
23  Emacs-x86_64-10_14            	       0x1052acd69 Ffuncall_interactively + 73
24  Emacs-x86_64-10_14            	       0x1052b40eb Ffuncall + 843
25  Emacs-x86_64-10_14            	       0x1052b3c3c Fapply + 588
26  Emacs-x86_64-10_14            	       0x1052ad23e Fcall_interactively + 1214
27  Emacs-x86_64-10_14            	       0x1052b4b21 funcall_subr + 289
28  Emacs-x86_64-10_14            	       0x1052b40eb Ffuncall + 843
29  Emacs-x86_64-10_14            	       0x1052fa41b exec_byte_code + 1675
30  Emacs-x86_64-10_14            	       0x1052b4089 Ffuncall + 745
31  Emacs-x86_64-10_14            	       0x1052b475c call1 + 44
32  Emacs-x86_64-10_14            	       0x1052280aa command_loop_1 + 2010
33  Emacs-x86_64-10_14            	       0x1052b2087 internal_condition_case + 263
34  Emacs-x86_64-10_14            	       0x1052278be command_loop_2 + 46
35  Emacs-x86_64-10_14            	       0x1052b16fb internal_catch + 267
36  Emacs-x86_64-10_14            	       0x105374e08 command_loop.cold.1 + 72
37  Emacs-x86_64-10_14            	       0x105227166 command_loop + 134
38  Emacs-x86_64-10_14            	       0x105227076 recursive_edit_1 + 118
39  Emacs-x86_64-10_14            	       0x1052272eb Frecursive_edit + 347
40  Emacs-x86_64-10_14            	       0x105225e86 main + 7574
41  dyld                          	       0x1082ea52e start + 462

Thread 1:
0   libsystem_kernel.dylib        	    0x7ff81d85fd5a __select + 10
1   Emacs-x86_64-10_14            	       0x10533bdcc -[EmacsApp fd_handler:] + 236
2   Foundation                    	    0x7ff81e7af994 __NSThread__start__ + 1009
3   libsystem_pthread.dylib       	    0x7ff81d8944e1 _pthread_start + 125
4   libsystem_pthread.dylib       	    0x7ff81d88ff6b thread_start + 15

Thread 2:: com.apple.NSEventThread
0   libsystem_kernel.dylib        	    0x7ff81d85797a mach_msg_trap + 10
1   libsystem_kernel.dylib        	    0x7ff81d857ce8 mach_msg + 56
2   CoreFoundation                	    0x7ff81d95b36d __CFRunLoopServiceMachPort + 319
3   CoreFoundation                	    0x7ff81d9599f8 __CFRunLoopRun + 1276
4   CoreFoundation                	    0x7ff81d958e3c CFRunLoopRunSpecific + 562
5   AppKit                        	    0x7ff8205009ce _NSEventThread + 132
6   libsystem_pthread.dylib       	    0x7ff81d8944e1 _pthread_start + 125
7   libsystem_pthread.dylib       	    0x7ff81d88ff6b thread_start + 15

Thread 3:
0   libsystem_pthread.dylib       	    0x7ff81d88ff48 start_wqthread + 0

Thread 4:
0   libsystem_pthread.dylib       	    0x7ff81d88ff48 start_wqthread + 0

Thread 5:
0   libsystem_pthread.dylib       	    0x7ff81d88ff48 start_wqthread + 0


Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x0000000108365600  rcx: 0x00000001057b4698  rdx: 0x0000000000000000
  rdi: 0x0000000000000103  rsi: 0x0000000000000006  rbp: 0x00000001057b46c0  rsp: 0x00000001057b4698
   r8: 0x0000000000000000   r9: 0x00007f9ccd900000  r10: 0x0000000108365600  r11: 0x0000000000000246
  r12: 0x0000000000000103  r13: 0x0000000000000000  r14: 0x0000000000000006  r15: 0x0000000000000016
  rip: 0x00007ff81d85e00e  rfl: 0x0000000000000246  cr2: 0x000000010e158014
  
Logical CPU:     0
Error Code:      0x02000148 
Trap Number:     133

Thread 0 instruction stream:
  00 80 48 99 48 f7 ff 48-83 f8 08 0f 8c 22 02 00  ..H.H..H....."..
  00 49 89 e6 48 8d 04 fd-0f 00 00 00 48 83 e0 f0  .I..H.......H...
  49 29 c6 4c 89 f4 48 c1-fb 03 49 b8 cd cc cc cc  I).L..H...I.....
  cc cc cc cc 4c 0f af c3-85 ff 0f 8e 99 00 00 00  ....L...........
  48 8d 05 c7 d7 61 00 4c-8b 08 49 83 c1 fb 45 31  H....a.L..I...E1
  e4 31 c9 45 31 ff 45 31-ed 0f 1f 44 00 00 89 c8  .1.E1.E1...D....
 [49]8b 5c c1 08 ba 01 00-00 00 48 81 fb bf 00 00  I.\.......H.....	<==
  00 7f 1b 48 85 db 74 41-48 83 fb 30 75 22 4d 8b  ...H..tAH..0u"M.
  6c c1 18 ba 03 00 00 00-eb 49 0f 1f 40 00 48 81  l........I..@.H.
  fb c0 00 00 00 74 31 48-81 fb f0 b7 00 00 74 33  .....t1H......t3
  49 8d 5c c1 08 4d 8b 7c-c1 18 ba 08 00 00 00 4c  I.\..M.|.......L
  39 d3 75 1f e9 aa 00 00-00 49 63 c4 41 ff c4 4d  9.u......Ic.A..M

Binary Images:
    0x7ff81d856000 -     0x7ff81d88dfff libsystem_kernel.dylib (*) <e2477724-bccf-3a8c-9c75-c774c569f36e> /usr/lib/system/libsystem_kernel.dylib
    0x7ff81d88e000 -     0x7ff81d899fff libsystem_pthread.dylib (*) <b5454e27-e8c7-3fdb-b77f-714f1e82e70b> /usr/lib/system/libsystem_pthread.dylib
    0x7ff81d75e000 -     0x7ff81d7e6fff libsystem_c.dylib (*) <e42e9d7a-03b4-340b-b61e-dcd45fd4acc0> /usr/lib/system/libsystem_c.dylib
       0x10515e000 -        0x1053b5fff Emacs-x86_64-10_14 (*) <8ed10e62-8a5b-3367-9113-597488bcf4cb> /Applications/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14
    0x7ff81d8a6000 -     0x7ff81d8affff libsystem_platform.dylib (*) <a8a33774-6d44-35e9-ad2a-bad9e4d5192a> /usr/lib/system/libsystem_platform.dylib
               0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???
       0x1082e5000 -        0x108350fff dyld (*) <006a3e6f-3cd3-34d9-b0f2-ed6bd67a95a6> /usr/lib/dyld
    0x7ff81e757000 -     0x7ff81eb13fff com.apple.Foundation (6.9) <e22e60bb-ab77-3120-862f-92fa74feffcf> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
    0x7ff81d8db000 -     0x7ff81ddddfff com.apple.CoreFoundation (6.9) <93c48919-68af-367e-9a67-db4159bc962c> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7ff820354000 -     0x7ff8211e3fff com.apple.AppKit (6.9) <11be8778-f5e5-3ccb-bcc3-10ffea3bf44b> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=1.1G resident=0K(0%) swapped_out_or_unallocated=1.1G(100%)
Writable regions: Total=222.5M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=222.5M(100%)

                                VIRTUAL   REGION 
REGION TYPE                        SIZE    COUNT (non-coalesced) 
===========                     =======  ======= 
Accelerate framework               384K        3 
Activity Tracing                   256K        1 
CG backing stores                 2528K        4 
CG image                          3560K       20 
ColorSync                          220K       26 
CoreAnimation                     14.8M       20 
CoreGraphics                        12K        2 
CoreUI image data                 1260K       11 
Dispatch continuations            64.0M        1 
Foundation                          32K        2 
Kernel Alloc Once                    8K        1 
MALLOC                           125.4M      104 
MALLOC guard page                   32K        8 
MALLOC_LARGE (reserved)            116K        2         reserved VM address space (unallocated)
ObjC additional data                15K        1 
STACK GUARD                         20K        5 
Stack                             10.5M        6 
Stack (reserved)                  1596K        1         reserved VM address space (unallocated)
Stack Guard                       54.4M        1 
VM_ALLOCATE                         60K       12 
__CTF                               756        1 
__DATA                            33.1M      491 
__DATA_CONST                      28.8M      310 
__DATA_DIRTY                      1535K      193 
__FONT_DATA                          4K        1 
__LINKEDIT                       647.6M       18 
__TEXT                           485.1M      505 
__UNICODE                          592K        1 
dyld private memory               1024K        1 
mapped file                      893.1M      209 
shared memory                      800K       22 
===========                     =======  ======= 
TOTAL                              2.3G     1983 
TOTAL, minus reserved VM space     2.3G     1983 



-----------
Full Report
-----------

{"app_name":"Emacs-x86_64-10_14","timestamp":"2023-05-13 08:35:25.00 -0700","app_version":"","slice_uuid":"8ed10e62-8a5b-3367-9113-597488bcf4cb","build_version":"","platform":1,"share_with_app_devs":0,"is_first_party":1,"bug_type":"309","os_version":"macOS 12.6.3 (21G419)","incident_id":"2E543ACA-70E6-4CE4-B8BB-5C926BA15B3A","name":"Emacs-x86_64-10_14"}
{
  "uptime" : 300000,
  "procLaunch" : "2023-05-13 08:20:30.3830 -0700",
  "procRole" : "Foreground",
  "version" : 2,
  "userID" : 501,
  "deployVersion" : 210,
  "modelCode" : "MacBookAir9,1",
  "procStartAbsTime" : 301832581338460,
  "coalitionID" : 29889,
  "osVersion" : {
    "train" : "macOS 12.6.3",
    "build" : "21G419",
    "releaseType" : "User"
  },
  "captureTime" : "2023-05-13 08:35:25.5733 -0700",
  "incident" : "2E543ACA-70E6-4CE4-B8BB-5C926BA15B3A",
  "bug_type" : "309",
  "pid" : 58491,
  "procExitAbsTime" : 302727765713321,
  "cpuType" : "X86-64",
  "procName" : "Emacs-x86_64-10_14",
  "procPath" : "\/Applications\/Emacs.app\/Contents\/MacOS\/Emacs-x86_64-10_14",
  "parentProc" : "launchd",
  "parentPid" : 1,
  "crashReporterKey" : "CCCDA783-D27E-114E-B131-A9A0ED385750",
  "wakeTime" : 1362,
  "bridgeVersion" : {"build":"20P3045","train":"7.2"},
  "sleepWakeUUID" : "E3FB27AC-1DF3-4DC0-A485-251164CADFAD",
  "sip" : "enabled",
  "vmRegionInfo" : "0x3 is not in any region.  Bytes before following region: 140737488134141\n      REGION TYPE                    START - END         [ VSIZE] PRT\/MAX SHRMOD  REGION DETAIL\n      UNUSED SPACE AT START\n--->  \n      VM_ALLOCATE              7ffffffca000-7ffffffcb000 [    4K] r-x\/r-x SM=ALI  ",
  "isCorpse" : 1,
  "exception" : {"codes":"0x0000000000000001, 0x0000000000000003","rawCodes":[1,3],"type":"EXC_BAD_ACCESS","signal":"SIGABRT","subtype":"KERN_INVALID_ADDRESS at 0x0000000000000003"},
  "vmregioninfo" : "0x3 is not in any region.  Bytes before following region: 140737488134141\n      REGION TYPE                    START - END         [ VSIZE] PRT\/MAX SHRMOD  REGION DETAIL\n      UNUSED SPACE AT START\n--->  \n      VM_ALLOCATE              7ffffffca000-7ffffffcb000 [    4K] r-x\/r-x SM=ALI  ",
  "extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0},
  "faultingThread" : 0,
  "threads" : [{"triggered":true,"id":3047362,"instructionState":{"instructionStream":{"bytes":[0,128,72,153,72,247,255,72,131,248,8,15,140,34,2,0,0,73,137,230,72,141,4,253,15,0,0,0,72,131,224,240,73,41,198,76,137,244,72,193,251,3,73,184,205,204,204,204,204,204,204,204,76,15,175,195,133,255,15,142,153,0,0,0,72,141,5,199,215,97,0,76,139,8,73,131,193,251,69,49,228,49,201,69,49,255,69,49,237,15,31,68,0,0,137,200,73,139,92,193,8,186,1,0,0,0,72,129,251,191,0,0,0,127,27,72,133,219,116,65,72,131,251,48,117,34,77,139,108,193,24,186,3,0,0,0,235,73,15,31,64,0,72,129,251,192,0,0,0,116,49,72,129,251,240,183,0,0,116,51,73,141,92,193,8,77,139,124,193,24,186,8,0,0,0,76,57,211,117,31,233,170,0,0,0,73,99,196,65,255,196,77],"offset":96}},"threadState":{"r13":{"value":0},"rax":{"value":0},"rflags":{"value":582},"cpu":{"value":0},"r14":{"value":6},"rsi":{"value":6},"r8":{"value":0},"cr2":{"value":4531257364},"rdx":{"value":0},"r10":{"value":4432745984,"symbolLocation":0,"symbol":"_main_thread"},"r9":{"value":140311440392192},"r15":{"value":22},"rbx":{"value":4432745984,"symbolLocation":0,"symbol":"_main_thread"},"trap":{"value":133},"err":{"value":33554760},"r11":{"value":582},"rip":{"value":140703623929870,"matchesCrashFrame":1},"rbp":{"value":4386932416,"symbolLocation":61696,"symbol":"sigsegv_stack"},"rsp":{"value":4386932376},"r12":{"value":259},"rcx":{"value":4386932376,"symbolLocation":61656,"symbol":"sigsegv_stack"},"flavor":"x86_THREAD_STATE","rdi":{"value":259}},"queue":"com.apple.main-thread","frames":[{"imageOffset":32782,"symbol":"__pthread_kill","symbolLocation":10,"imageIndex":0},{"imageOffset":25087,"symbol":"pthread_kill","symbolLocation":263,"imageIndex":1},{"imageOffset":279256,"symbol":"raise","symbolLocation":26,"imageIndex":2},{"imageOffset":2189882,"symbol":"terminate_due_to_signal","symbolLocation":170,"imageIndex":3},{"imageOffset":2192299,"symbol":"emacs_abort","symbolLocation":15,"imageIndex":3},{"imageOffset":1951728,"symbol":"ns_term_shutdown","symbolLocation":80,"imageIndex":3},{"imageOffset":811140,"symbol":"shut_down_emacs","symbolLocation":340,"imageIndex":3},{"imageOffset":2189831,"symbol":"terminate_due_to_signal","symbolLocation":119,"imageIndex":3},{"imageOffset":944462,"symbol":"handle_fatal_signal","symbolLocation":14,"imageIndex":3},{"imageOffset":944593,"symbol":"deliver_thread_signal","symbolLocation":129,"imageIndex":3},{"imageOffset":938201,"symbol":"deliver_fatal_thread_signal","symbolLocation":9,"imageIndex":3},{"imageOffset":944776,"symbol":"handle_sigsegv","symbolLocation":168,"imageIndex":3},{"imageOffset":15869,"symbol":"_sigtramp","symbolLocation":29,"imageIndex":4},{"imageOffset":0,"imageIndex":5},{"imageOffset":2068177,"symbol":"-[EmacsMenu runMenuAt:forFrame:keymaps:]","symbolLocation":321,"imageIndex":3},{"imageOffset":2069622,"symbol":"ns_menu_show","symbolLocation":1414,"imageIndex":3},{"imageOffset":409167,"symbol":"x_popup_menu_1","symbolLocation":1439,"imageIndex":3},{"imageOffset":1403649,"symbol":"funcall_subr","symbolLocation":257,"imageIndex":3},{"imageOffset":1401067,"symbol":"Ffuncall","symbolLocation":843,"imageIndex":3},{"imageOffset":1688603,"symbol":"exec_byte_code","symbolLocation":1675,"imageIndex":3},{"imageOffset":1400969,"symbol":"Ffuncall","symbolLocation":745,"imageIndex":3},{"imageOffset":1688603,"symbol":"exec_byte_code","symbolLocation":1675,"imageIndex":3},{"imageOffset":1400969,"symbol":"Ffuncall","symbolLocation":745,"imageIndex":3},{"imageOffset":1371497,"symbol":"Ffuncall_interactively","symbolLocation":73,"imageIndex":3},{"imageOffset":1401067,"symbol":"Ffuncall","symbolLocation":843,"imageIndex":3},{"imageOffset":1399868,"symbol":"Fapply","symbolLocation":588,"imageIndex":3},{"imageOffset":1372734,"symbol":"Fcall_interactively","symbolLocation":1214,"imageIndex":3},{"imageOffset":1403681,"symbol":"funcall_subr","symbolLocation":289,"imageIndex":3},{"imageOffset":1401067,"symbol":"Ffuncall","symbolLocation":843,"imageIndex":3},{"imageOffset":1688603,"symbol":"exec_byte_code","symbolLocation":1675,"imageIndex":3},{"imageOffset":1400969,"symbol":"Ffuncall","symbolLocation":745,"imageIndex":3},{"imageOffset":1402716,"symbol":"call1","symbolLocation":44,"imageIndex":3},{"imageOffset":827562,"symbol":"command_loop_1","symbolLocation":2010,"imageIndex":3},{"imageOffset":1392775,"symbol":"internal_condition_case","symbolLocation":263,"imageIndex":3},{"imageOffset":825534,"symbol":"command_loop_2","symbolLocation":46,"imageIndex":3},{"imageOffset":1390331,"symbol":"internal_catch","symbolLocation":267,"imageIndex":3},{"imageOffset":2190856,"symbol":"command_loop.cold.1","symbolLocation":72,"imageIndex":3},{"imageOffset":823654,"symbol":"command_loop","symbolLocation":134,"imageIndex":3},{"imageOffset":823414,"symbol":"recursive_edit_1","symbolLocation":118,"imageIndex":3},{"imageOffset":824043,"symbol":"Frecursive_edit","symbolLocation":347,"imageIndex":3},{"imageOffset":818822,"symbol":"main","symbolLocation":7574,"imageIndex":3},{"imageOffset":21806,"symbol":"start","symbolLocation":462,"imageIndex":6}]},{"id":3047512,"frames":[{"imageOffset":40282,"symbol":"__select","symbolLocation":10,"imageIndex":0},{"imageOffset":1957324,"symbol":"-[EmacsApp fd_handler:]","symbolLocation":236,"imageIndex":3},{"imageOffset":362900,"symbol":"__NSThread__start__","symbolLocation":1009,"imageIndex":7},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":3047526,"name":"com.apple.NSEventThread","frames":[{"imageOffset":6522,"symbol":"mach_msg_trap","symbolLocation":10,"imageIndex":0},{"imageOffset":7400,"symbol":"mach_msg","symbolLocation":56,"imageIndex":0},{"imageOffset":525165,"symbol":"__CFRunLoopServiceMachPort","symbolLocation":319,"imageIndex":8},{"imageOffset":518648,"symbol":"__CFRunLoopRun","symbolLocation":1276,"imageIndex":8},{"imageOffset":515644,"symbol":"CFRunLoopRunSpecific","symbolLocation":562,"imageIndex":8},{"imageOffset":1755598,"symbol":"_NSEventThread","symbolLocation":132,"imageIndex":9},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":3056719,"frames":[{"imageOffset":8008,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":1}]},{"id":3056759,"frames":[{"imageOffset":8008,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":1}]},{"id":3056762,"frames":[{"imageOffset":8008,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":1}]}],
  "usedImages" : [
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 140703623897088,
    "size" : 229376,
    "uuid" : "e2477724-bccf-3a8c-9c75-c774c569f36e",
    "path" : "\/usr\/lib\/system\/libsystem_kernel.dylib",
    "name" : "libsystem_kernel.dylib"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 140703624126464,
    "size" : 49152,
    "uuid" : "b5454e27-e8c7-3fdb-b77f-714f1e82e70b",
    "path" : "\/usr\/lib\/system\/libsystem_pthread.dylib",
    "name" : "libsystem_pthread.dylib"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 140703622881280,
    "size" : 561152,
    "uuid" : "e42e9d7a-03b4-340b-b61e-dcd45fd4acc0",
    "path" : "\/usr\/lib\/system\/libsystem_c.dylib",
    "name" : "libsystem_c.dylib"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 4380286976,
    "size" : 2457600,
    "uuid" : "8ed10e62-8a5b-3367-9113-597488bcf4cb",
    "path" : "\/Applications\/Emacs.app\/Contents\/MacOS\/Emacs-x86_64-10_14",
    "name" : "Emacs-x86_64-10_14"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 140703624224768,
    "size" : 40960,
    "uuid" : "a8a33774-6d44-35e9-ad2a-bad9e4d5192a",
    "path" : "\/usr\/lib\/system\/libsystem_platform.dylib",
    "name" : "libsystem_platform.dylib"
  },
  {
    "size" : 0,
    "source" : "A",
    "base" : 0,
    "uuid" : "00000000-0000-0000-0000-000000000000"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 4432220160,
    "size" : 442368,
    "uuid" : "006a3e6f-3cd3-34d9-b0f2-ed6bd67a95a6",
    "path" : "\/usr\/lib\/dyld",
    "name" : "dyld"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 140703639629824,
    "CFBundleShortVersionString" : "6.9",
    "CFBundleIdentifier" : "com.apple.Foundation",
    "size" : 3919872,
    "uuid" : "e22e60bb-ab77-3120-862f-92fa74feffcf",
    "path" : "\/System\/Library\/Frameworks\/Foundation.framework\/Versions\/C\/Foundation",
    "name" : "Foundation",
    "CFBundleVersion" : "1866"
  },
  {
    "source" : "P",
    "arch" : "x86_64h",
    "base" : 140703624441856,
    "CFBundleShortVersionString" : "6.9",
    "CFBundleIdentifier" : "com.apple.CoreFoundation",
    "size" : 5255168,
    "uuid" : "93c48919-68af-367e-9a67-db4159bc962c",
    "path" : "\/System\/Library\/Frameworks\/CoreFoundation.framework\/Versions\/A\/CoreFoundation",
    "name" : "CoreFoundation",
    "CFBundleVersion" : "1866"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 140703668977664,
    "CFBundleShortVersionString" : "6.9",
    "CFBundleIdentifier" : "com.apple.AppKit",
    "size" : 15269888,
    "uuid" : "11be8778-f5e5-3ccb-bcc3-10ffea3bf44b",
    "path" : "\/System\/Library\/Frameworks\/AppKit.framework\/Versions\/C\/AppKit",
    "name" : "AppKit",
    "CFBundleVersion" : "2113.60.148"
  }
],
  "sharedCache" : {
  "base" : 140703620870144,
  "size" : 19331678208,
  "uuid" : "b6d97ead-9d19-3228-adaa-cca8452c02d2"
},
  "vmSummary" : "ReadOnly portion of Libraries: Total=1.1G resident=0K(0%) swapped_out_or_unallocated=1.1G(100%)\nWritable regions: Total=222.5M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=222.5M(100%)\n\n                                VIRTUAL   REGION \nREGION TYPE                        SIZE    COUNT (non-coalesced) \n===========                     =======  ======= \nAccelerate framework               384K        3 \nActivity Tracing                   256K        1 \nCG backing stores                 2528K        4 \nCG image                          3560K       20 \nColorSync                          220K       26 \nCoreAnimation                     14.8M       20 \nCoreGraphics                        12K        2 \nCoreUI image data                 1260K       11 \nDispatch continuations            64.0M        1 \nFoundation                          32K        2 \nKernel Alloc Once                    8K        1 \nMALLOC                           125.4M      104 \nMALLOC guard page                   32K        8 \nMALLOC_LARGE (reserved)            116K        2         reserved VM address space (unallocated)\nObjC additional data                15K        1 \nSTACK GUARD                         20K        5 \nStack                             10.5M        6 \nStack (reserved)                  1596K        1         reserved VM address space (unallocated)\nStack Guard                       54.4M        1 \nVM_ALLOCATE                         60K       12 \n__CTF                               756        1 \n__DATA                            33.1M      491 \n__DATA_CONST                      28.8M      310 \n__DATA_DIRTY                      1535K      193 \n__FONT_DATA                          4K        1 \n__LINKEDIT                       647.6M       18 \n__TEXT                           485.1M      505 \n__UNICODE                          592K        1 \ndyld private memory               1024K        1 \nmapped file                      893.1M      209 \nshared memory                      800K       22 \n===========                     =======  ======= \nTOTAL                              2.3G     1983 \nTOTAL, minus reserved VM space     2.3G     1983 \n",
  "legacyInfo" : {
  "threadTriggered" : {
    "queue" : "com.apple.main-thread"
  }
},
  "trialInfo" : {
  "rollouts" : [
    {
      "rolloutId" : "60f8ddccefea4203d95cbeef",
      "factorPackIds" : {

      },
      "deploymentId" : 240000025
    },
    {
      "rolloutId" : "6297d96be2c9387df974efa4",
      "factorPackIds" : {

      },
      "deploymentId" : 240000008
    }
  ],
  "experiments" : [
    {
      "treatmentId" : "6dd670af-0633-45e4-ae5f-122ae4df02be",
      "experimentId" : "64406ba83deb637ac8a04419",
      "deploymentId" : 900000005
    }
  ]
}
}

Model: MacBookAir9,1, BootROM 1916.80.2.0.0 (iBridge: 20.16.3045.0.0,0), 4 processors, Quad-Core Intel Core i5, 1.1 GHz, 16 GB, SMC 
Graphics: Intel Iris Plus Graphics, Intel Iris Plus Graphics, Built-In
Display: Color LCD, 2560 x 1600 Retina, Main, MirrorOff, Online
Memory Module: BANK 0/ChannelA-DIMM0, 8 GB, LPDDR4X, 3733 MHz, Micron, MT53E1G64D8NW-053
Memory Module: BANK 2/ChannelB-DIMM0, 8 GB, LPDDR4X, 3733 MHz, Micron, MT53E1G64D8NW-053
AirPort: spairport_wireless_card_type_wifi (0x14E4, 0x870), wl0: Jul 16 2021 18:25:13 version 16.20.328.0.3.6.105 FWID 01-30be2b3a
Bluetooth: Version (null), 0 services, 0 devices, 0 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
USB Device: USB31Bus
USB Device: USB31Bus
USB Device: T2Bus
USB Device: Touch Bar Backlight
USB Device: Apple Internal Keyboard / Trackpad
USB Device: Headset
USB Device: Ambient Light Sensor
USB Device: FaceTime HD Camera (Built-in)
USB Device: Apple T2 Controller
Thunderbolt Bus: MacBook Air, Apple Inc., 86.0



In GNU Emacs 28.2 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G95))
of 2022-09-12 built on builder10-14.lan
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.6.3

Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp' --with-modules'

Configured features:
ACL GMP GNUTLS JSON LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER THREADS
TOOLKIT_SCROLL_BARS ZLIB

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

Major mode: Term

Minor modes in effect:
  which-key-mode: t
  windmove-mode: t
  pdf-occur-global-minor-mode: t
  diredful-mode: t
  openwith-mode: t
  helm-mode: t
  helm-minibuffer-history-mode: t
  dired-hide-details-mode: 1
  async-bytecomp-package-mode: t
  electric-pair-mode: t
  savehist-mode: t
  save-place-mode: t
  shell-dirtrack-mode: t
  recentf-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/Users/davidobrien/.emacs.d/elpa/emacsql-mysql-20230225.2205/emacsql-mysql hides /Users/davidobrien/.emacs.d/elpa/emacsql-20230228.1040/emacsql-mysql

Features:
(shadow sort flyspell ispell mail-extr warnings emacsbug message
rfc822 mml mml-sec gnus-util rmail rmail-loaddefs mm-decode mm-bodies
mm-encode mailabbrev gmm-utils mailheader sendmail term disp-table
ehelp mail-utils gnutls network-stream url-cache dired-aux
company-oddmuse company-keywords company-etags etags fileloop
generator xref project company-gtags company-dabbrev-code
company-dabbrev company-files company-clang company-capf company-cmake
company-semantic company-template company-bbdb company pcase which-key
multiple-cursors mc-separate-operations rectangular-region-mode
mc-mark-pop mc-edit-lines mc-hide-unmatched-lines-mode mc-mark-more
thingatpt mc-cycle-cursors multiple-cursors-core rect buffer-move
windmove pdf-occur ibuf-ext ibuffer ibuffer-loaddefs tablist advice
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 compile cus-edit
pdf-view bookmark text-property-search pp jka-compr pdf-cache pdf-info
tq pdf-util pdf-macs diredful dired-x openwith helm-mode helm-misc
helm-files image-dired image-mode dired dired-loaddefs exif filenotify
helm-buffers helm-occur helm-tags helm-locate helm-grep helm-regexp
helm-utils helm-help helm-types helm helm-global-bindings
helm-easymenu helm-core easy-mmode async-bytecomp helm-source
helm-multi-match helm-lib async finder-inf elec-pair
org-beautify-theme symon battery dbus cus-load epa-file epa derived
epg rfc6068 epg-config edmacro kmacro dokuwiki-mode dokuwiki xml-rpc
url-http url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr url-gw nsm rmc puny xml gpt savehist saveplace
default-black-theme tramp-cache tramp-sh tramp tramp-loaddefs trampver
tramp-integration files-x tramp-compat shell pcomplete comint
ansi-color ring parse-time iso8601 time-date ls-lisp format-spec
recentf tree-widget wid-edit ede/auto eieio-base rx info package
browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib iso-transl tooltip eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode
mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win
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
cl-generic 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
simple abbrev obarray cl-preloaded nadvice button loaddefs faces
cus-face macroexp files window text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote threads kqueue cocoa ns multi-tty make-network-process
emacs)

Memory information:
((conses 16 392803 20482)
(symbols 48 27962 5)
(strings 32 137999 2865)
(string-bytes 1 3929517)
(vectors 16 52695)
(vector-slots 8 1377195 116416)
(floats 8 190 83)
(intervals 56 1006 0)
(buffers 992 18))

bug#63495: 28.2; menu crashes on macos

[Eli Zaretskii]

> From: David O'Brien <obriendavid1@gmail.com>
> Date: Sat, 13 May 2023 08:36:31 -0700
> 
> When using the menu - I can call up and see the menu, but if I try to
> select a menu item this always results in emacs crashing.
> I copy in below the system message

Thank you for your report.

We are in the process of pretesting Emacs 29 for a release that should
happen soon.  Would it be possible for you to try the pretest of Emacs
29, or to build the emacs-29 branch of the Emacs Git repository?  It
is important for us to know whether this problem was meanwhile fixed
or still exists in what will be Emacs 29.

bug#63495: 28.2; menu crashes on macos

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

David O'Brien <obriendavid1@gmail.com> writes:

> When using the menu - I can call up and see the menu, but if I try to
> select a menu item this always results in emacs crashing.

I can't reproduce this bug on Emacs 29.  Could you try to reproduce it
on this version?  I remember fixing some problems with the macOS menu
bar recently, so perhaps this bug is already fixed.

bug#63495: 28.2; menu crashes on macos

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

>> When using the menu - I can call up and see the menu, but if I try to
>> select a menu item this always results in emacs crashing.
>
> I can't reproduce this bug on Emacs 29.  Could you try to reproduce it
> on this version?  I remember fixing some problems with the macOS menu
> bar recently, so perhaps this bug is already fixed.

FWIW this seems very similar to Bug#62402.  At least over here (macOS
13.4, Emacs master), Emacs still reliably crashes when selecting an item
in a popup menu.

bug#63495: 28.2; menu crashes on macos

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

>>> When using the menu - I can call up and see the menu, but if I try to
>>> select a menu item this always results in emacs crashing.
>>
>> I can't reproduce this bug on Emacs 29.  Could you try to reproduce it
>> on this version?  I remember fixing some problems with the macOS menu
>> bar recently, so perhaps this bug is already fixed.
>
> FWIW this seems very similar to Bug#62402.  At least over here (macOS
> 13.4, Emacs master), Emacs still reliably crashes when selecting an item
> in a popup menu.

Thanks, I can reproduce the issue with the recipe in Bug#62402.  I see
that this is a regression in Emacs 28 and Emacs 29.  I can't reproduce
the bug in Emacs 27.

A bisect shows that this is the first commit that introduced the bug:

commit c9b37634b131f3617314bd5a38090e96d0b465cf
Author: Alan Third <alan@idiocy.org>
Date:   Wed Dec 23 20:12:02 2020 +0000

    Remove NS menu synthesized events (bug#44333)
    
    Remove the frame tracking stuff as it's not used for anything, and
    move the update tracking into the EmacsMenu class.
    
    * src/nsmenu.m (ns_update_menubar): Copy the parsing code from xmenu.c
    and rework the NS specific code around to update the existing menus
    instead of rebuilding them completely.
    (ns_activate_menubar):
    ([EmacsMenu trackingNotification:]):
    ([EmacsMenu menuWillOpen:]):
    ([EmacsMenu menuDidClose:]): Remove unused functions.
    ([EmacsMenu menuNeedsUpdate:]): Remove menu tracking code and add code
    to check whether an update is required.
    ([EmacsMenu fillWithWidgetValue:]):
    ([EmacsMenu addSubmenuWithTitle:]):
    ([EmacsMenu initWithTitle:]): Remove references to frame.
    ([EmacsMenu setFrame:]): Remove method.
    ([EmacsMenu clear]): Rename to removeAllItems.
    ([EmacsMenu removeAllItems]): Use built-in removeAllItems, if
    available.
    (syms_of_nsmenu): Remove tracking code.
    * src/nsterm.m (ns_check_menu_open):
    (ns_check_pending_open_menu):
    (ns_create_terminal): Remove unused functions.
    (ns_term_init): Get rid of menu tracking.
    * src/nsterm.h (EmacsMenu): Remove frame, add needsUpdate and update
    method definitions.

One notable thing in that patch is that, in menuNeedsUpdate:,
ns_update_menubar is now called, if needed, in the Cocoa and the GNUstep
build.  If I put the call to ns_update_menubar inside the #ifdef
NS_IMPL_GNUSTEP (so that it's not run in the Cocoa build), I can't
reproduce the crash anymore.  But I don't know if there are any side
effects or what motivated the change in the first place.

I've copied Alan, just in case he has any comments about how we can fix
this issue.

bug#63495: 28.2; menu crashes on macos

[Alan Third]

On Mon, Jul 10, 2023 at 11:00:49PM +0200, Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
> Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs@gnu.org> writes:
> 
> >>> When using the menu - I can call up and see the menu, but if I try to
> >>> select a menu item this always results in emacs crashing.
> >>
> >> I can't reproduce this bug on Emacs 29.  Could you try to reproduce it
> >> on this version?  I remember fixing some problems with the macOS menu
> >> bar recently, so perhaps this bug is already fixed.
> >
> > FWIW this seems very similar to Bug#62402.  At least over here (macOS
> > 13.4, Emacs master), Emacs still reliably crashes when selecting an item
> > in a popup menu.
> 
> Thanks, I can reproduce the issue with the recipe in Bug#62402.  I see
> that this is a regression in Emacs 28 and Emacs 29.  I can't reproduce
> the bug in Emacs 27.
> 
> A bisect shows that this is the first commit that introduced the bug:
> 
> commit c9b37634b131f3617314bd5a38090e96d0b465cf
> Author: Alan Third <alan@idiocy.org>
> Date:   Wed Dec 23 20:12:02 2020 +0000
> 
>     Remove NS menu synthesized events (bug#44333)
>     
>     Remove the frame tracking stuff as it's not used for anything, and
>     move the update tracking into the EmacsMenu class.
>     
>     * src/nsmenu.m (ns_update_menubar): Copy the parsing code from xmenu.c
>     and rework the NS specific code around to update the existing menus
>     instead of rebuilding them completely.
>     (ns_activate_menubar):
>     ([EmacsMenu trackingNotification:]):
>     ([EmacsMenu menuWillOpen:]):
>     ([EmacsMenu menuDidClose:]): Remove unused functions.
>     ([EmacsMenu menuNeedsUpdate:]): Remove menu tracking code and add code
>     to check whether an update is required.
>     ([EmacsMenu fillWithWidgetValue:]):
>     ([EmacsMenu addSubmenuWithTitle:]):
>     ([EmacsMenu initWithTitle:]): Remove references to frame.
>     ([EmacsMenu setFrame:]): Remove method.
>     ([EmacsMenu clear]): Rename to removeAllItems.
>     ([EmacsMenu removeAllItems]): Use built-in removeAllItems, if
>     available.
>     (syms_of_nsmenu): Remove tracking code.
>     * src/nsterm.m (ns_check_menu_open):
>     (ns_check_pending_open_menu):
>     (ns_create_terminal): Remove unused functions.
>     (ns_term_init): Get rid of menu tracking.
>     * src/nsterm.h (EmacsMenu): Remove frame, add needsUpdate and update
>     method definitions.
> 
> One notable thing in that patch is that, in menuNeedsUpdate:,
> ns_update_menubar is now called, if needed, in the Cocoa and the GNUstep
> build.  If I put the call to ns_update_menubar inside the #ifdef
> NS_IMPL_GNUSTEP (so that it's not run in the Cocoa build), I can't
> reproduce the crash anymore.  But I don't know if there are any side
> effects or what motivated the change in the first place.

I can't remember exactly why it was done as it was, but I do remember
there were big problems with getting the menus to update in a timely
manner.

It's interesting that the crash is happening in
runMenuAt:forFrame:keymaps: with it trying to access memory at address
0x3. There's nothing obvious in that function that would be doing
that, so it would be good if we could get a backtrace from a debugger
showing the exact line that's causing the problem and, if possible,
which variable has the value 3.
-- 
Alan Third

bug#63495: 28.2; menu crashes on macos

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

Hi,

Alan Third <alan@idiocy.org> writes:

> It's interesting that the crash is happening in
> runMenuAt:forFrame:keymaps: with it trying to access memory at address
> 0x3. There's nothing obvious in that function that would be doing
> that, so it would be good if we could get a backtrace from a debugger
> showing the exact line that's causing the problem and, if possible,
> which variable has the value 3.

There's this backtrace that I've posted in Bug#62402, HTH:

> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3)
>   * frame #0: 0x00000001000aebad emacs`AREF(array=0x0000000000000000, idx=0) at lisp.h:1947:10
>     frame #1: 0x00000001000af660 emacs`find_and_return_menu_selection(f=0x00000001100dee30, keymaps=true, client_data=0x000000011089b888) at menu.c:985:11
>     frame #2: 0x0000000100380f2b emacs`-[EmacsMenu runMenuAt:forFrame:keymaps:](self=0x00006000017007c0, _cmd="runMenuAt:forFrame:keymaps:", p=(x = 2, y = 506), f=0x00000001100dee30, keymaps=true) at nsmenu.m:767:9
>     frame #3: 0x0000000100381f00 emacs`ns_menu_show(f=0x00000001100dee30, x=2, y=2, menuflags=1, title=0x0000000000000000, error=0x00007ff7bfefce80) at nsmenu.m:1067:9
>     frame #4: 0x00000001000b1203 emacs`x_popup_menu_1(position=0x000000011804dcb3, menu=0x000000011804e003) at menu.c:1410:17
>     frame #5: 0x00000001000b15a2 emacs`Fx_popup_menu(position=0x000000011804dcb3, menu=0x000000011804e003) at menu.c:1474:10
>     frame #6: 0x0000000100247c58 emacs`eval_sub(form=0x000000011804dd23) at eval.c:2503:15
>     ...
> 
> It seems that `find_and_return_menu_selection` in menu.c tries to
> access the global variable `menu_items` before it's initialized.  I'm
> not sure when or where it should be initialized though :(

bug#63495: 28.2; menu crashes on macos

[Alan Third]

On Tue, Jul 11, 2023 at 08:40:46AM +0300, Eshel Yaron wrote:
> Hi,
> 
> Alan Third <alan@idiocy.org> writes:
> 
> > It's interesting that the crash is happening in
> > runMenuAt:forFrame:keymaps: with it trying to access memory at address
> > 0x3. There's nothing obvious in that function that would be doing
> > that, so it would be good if we could get a backtrace from a debugger
> > showing the exact line that's causing the problem and, if possible,
> > which variable has the value 3.
> 
> There's this backtrace that I've posted in Bug#62402, HTH:
> 
> > * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3)
> >   * frame #0: 0x00000001000aebad emacs`AREF(array=0x0000000000000000, idx=0) at lisp.h:1947:10
> >     frame #1: 0x00000001000af660 emacs`find_and_return_menu_selection(f=0x00000001100dee30, keymaps=true, client_data=0x000000011089b888) at menu.c:985:11
> >     frame #2: 0x0000000100380f2b emacs`-[EmacsMenu runMenuAt:forFrame:keymaps:](self=0x00006000017007c0, _cmd="runMenuAt:forFrame:keymaps:", p=(x = 2, y = 506), f=0x00000001100dee30, keymaps=true) at nsmenu.m:767:9
> >     frame #3: 0x0000000100381f00 emacs`ns_menu_show(f=0x00000001100dee30, x=2, y=2, menuflags=1, title=0x0000000000000000, error=0x00007ff7bfefce80) at nsmenu.m:1067:9
> >     frame #4: 0x00000001000b1203 emacs`x_popup_menu_1(position=0x000000011804dcb3, menu=0x000000011804e003) at menu.c:1410:17
> >     frame #5: 0x00000001000b15a2 emacs`Fx_popup_menu(position=0x000000011804dcb3, menu=0x000000011804e003) at menu.c:1474:10
> >     frame #6: 0x0000000100247c58 emacs`eval_sub(form=0x000000011804dd23) at eval.c:2503:15
> >     ...
> > 
> > It seems that `find_and_return_menu_selection` in menu.c tries to
> > access the global variable `menu_items` before it's initialized.  I'm
> > not sure when or where it should be initialized though :(

No, sorry, I need the output from a debugger. That should give the
exact line where the failure happens.

Is anyone able to recreate this while running in a debugger? It can be
lldb, doesn't have to be gcc.
-- 
Alan Third

bug#63495: 28.2; menu crashes on macos

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

Alan Third <alan@idiocy.org> writes:

>> > There's nothing obvious in that function that would be doing that,
>> > so it would be good if we could get a backtrace from a debugger
>> > showing the exact line that's causing the problem and, if possible,
>> > which variable has the value 3.
>> 
>> There's this backtrace that I've posted in Bug#62402, HTH:
>> 
>> > * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3)
>> >   * frame #0: 0x00000001000aebad emacs`AREF(array=0x0000000000000000, idx=0) at lisp.h:1947:10
>> >     frame #1: 0x00000001000af660 emacs`find_and_return_menu_selection(f=0x00000001100dee30, keymaps=true, client_data=0x000000011089b888) at menu.c:985:11
>> >     frame #2: 0x0000000100380f2b emacs`-[EmacsMenu runMenuAt:forFrame:keymaps:](self=0x00006000017007c0, _cmd="runMenuAt:forFrame:keymaps:", p=(x = 2, y = 506), f=0x00000001100dee30, keymaps=true) at nsmenu.m:767:9
>> >     frame #3: 0x0000000100381f00 emacs`ns_menu_show(f=0x00000001100dee30, x=2, y=2, menuflags=1, title=0x0000000000000000, error=0x00007ff7bfefce80) at nsmenu.m:1067:9
>> >     frame #4: 0x00000001000b1203 emacs`x_popup_menu_1(position=0x000000011804dcb3, menu=0x000000011804e003) at menu.c:1410:17
>> >     frame #5: 0x00000001000b15a2 emacs`Fx_popup_menu(position=0x000000011804dcb3, menu=0x000000011804e003) at menu.c:1474:10
>> >     frame #6: 0x0000000100247c58 emacs`eval_sub(form=0x000000011804dd23) at eval.c:2503:15
>> >     ...
>> > 
>> > It seems that `find_and_return_menu_selection` in menu.c tries to
>> > access the global variable `menu_items` before it's initialized.  I'm
>> > not sure when or where it should be initialized though :(
>
> No, sorry, I need the output from a debugger. That should give the
> exact line where the failure happens.

I'm not sure I understand, this *is* the output from a debugger.  I ran
Emacs under lldb and got the above backtrace when it crashed.  It also
includes the exact line number(s).  What am I missing?

bug#63495: 28.2; menu crashes on macos

[Alan Third]

On Wed, Jul 12, 2023 at 08:44:04PM +0300, Eshel Yaron wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> >> > There's nothing obvious in that function that would be doing that,
> >> > so it would be good if we could get a backtrace from a debugger
> >> > showing the exact line that's causing the problem and, if possible,
> >> > which variable has the value 3.
> >> 
> >> There's this backtrace that I've posted in Bug#62402, HTH:
> >> 
> >> > * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3)
> >> >   * frame #0: 0x00000001000aebad emacs`AREF(array=0x0000000000000000, idx=0) at lisp.h:1947:10
> >> >     frame #1: 0x00000001000af660 emacs`find_and_return_menu_selection(f=0x00000001100dee30, keymaps=true, client_data=0x000000011089b888) at menu.c:985:11
> >> >     frame #2: 0x0000000100380f2b emacs`-[EmacsMenu runMenuAt:forFrame:keymaps:](self=0x00006000017007c0, _cmd="runMenuAt:forFrame:keymaps:", p=(x = 2, y = 506), f=0x00000001100dee30, keymaps=true) at nsmenu.m:767:9
> >> >     frame #3: 0x0000000100381f00 emacs`ns_menu_show(f=0x00000001100dee30, x=2, y=2, menuflags=1, title=0x0000000000000000, error=0x00007ff7bfefce80) at nsmenu.m:1067:9
> >> >     frame #4: 0x00000001000b1203 emacs`x_popup_menu_1(position=0x000000011804dcb3, menu=0x000000011804e003) at menu.c:1410:17
> >> >     frame #5: 0x00000001000b15a2 emacs`Fx_popup_menu(position=0x000000011804dcb3, menu=0x000000011804e003) at menu.c:1474:10
> >> >     frame #6: 0x0000000100247c58 emacs`eval_sub(form=0x000000011804dd23) at eval.c:2503:15
> >> >     ...
> >> > 
> >> > It seems that `find_and_return_menu_selection` in menu.c tries to
> >> > access the global variable `menu_items` before it's initialized.  I'm
> >> > not sure when or where it should be initialized though :(
> >
> > No, sorry, I need the output from a debugger. That should give the
> > exact line where the failure happens.
> 
> I'm not sure I understand, this *is* the output from a debugger.  I ran
> Emacs under lldb and got the above backtrace when it crashed.  It also
> includes the exact line number(s).  What am I missing?

Sorry, I misunderstood what I was looking at.

Can you please try this:

modified   src/nsmenu.m
@@ -746,6 +746,8 @@ - (Lisp_Object)runMenuAt: (NSPoint)p forFrame: (struct frame *)f
   NSEvent *e, *event;
   long retVal;
 
+  needsUpdate = NO;
+
   /* p = [view convertPoint:p fromView: nil]; */
   p.y = NSHeight ([view frame]) - p.y;
   e = [[view window] currentEvent];

At a guess, when the menu opens the first thing AppKit does is check if
it needs updated, and since a new menu starts with needsUpdate=YES, it
goes ahead and tries to do it, which overwrites some important
variables from the original "build" of the menu.

The context menu is built and then displayed, as opposed to the
top-menu that is partially built, then when it's to be displayed is
updated and filled in.
-- 
Alan Third

bug#63495: 28.2; menu crashes on macos

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

Alan Third <alan@idiocy.org> writes:

> Can you please try this:
>
> modified   src/nsmenu.m
> @@ -746,6 +746,8 @@ - (Lisp_Object)runMenuAt: (NSPoint)p forFrame: (struct frame *)f
>    NSEvent *e, *event;
>    long retVal;
>  
> +  needsUpdate = NO;
> +
>    /* p = [view convertPoint:p fromView: nil]; */
>    p.y = NSHeight ([view frame]) - p.y;
>    e = [[view window] currentEvent];
>
> At a guess, when the menu opens the first thing AppKit does is check if
> it needs updated, and since a new menu starts with needsUpdate=YES, it
> goes ahead and tries to do it, which overwrites some important
> variables from the original "build" of the menu.
>
> The context menu is built and then displayed, as opposed to the
> top-menu that is partially built, then when it's to be displayed is
> updated and filled in.

I tried it, unfortunately, that doesn't seem to solve the issue.  Emacs
still crashes with a similar backtrace:

--8<---------------cut here---------------start------------->8---
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3)
    frame #0: 0x00000001000af1fd emacs`AREF(array=0x0000000000000000, idx=0) at lisp.h:1941:10
   1938	AREF (Lisp_Object array, ptrdiff_t idx)
   1939	{
   1940	  eassert (0 <= idx && idx < gc_asize (array));
-> 1941	  return XVECTOR (array)->contents[idx];
   1942	}
   1943
   1944	INLINE Lisp_Object *
Target 0: (emacs) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3)
  * frame #0: 0x00000001000af1fd emacs`AREF(array=0x0000000000000000, idx=0) at lisp.h:1941:10
    frame #1: 0x00000001000b079e emacs`find_and_return_menu_selection(f=0x00000001030b0c30, keymaps=true, client_data=0x0000000110277e60) at menu.c:985:11
    frame #2: 0x000000010037cc1a emacs`-[EmacsMenu runMenuAt:forFrame:keymaps:](self=0x000060000179c9c0, _cmd="runMenuAt:forFrame:keymaps:", p=(x = 2, y = 411), f=0x00000001030b0c30, keymaps=true) at nsmenu.m:769:9
    frame #3: 0x0000000100380ac0 emacs`ns_menu_show(f=0x00000001030b0c30, x=2, y=97, menuflags=1, title=0x0000000102416284, error=0x00007ff7bfefcef0) at nsmenu.m:1069:9
    frame #4: 0x00000001000b23f7 emacs`x_popup_menu_1(position=0x0000000118583f83, menu=0x0000000118587313) at menu.c:1410:17
    frame #5: 0x00000001000b27d2 emacs`Fx_popup_menu(position=0x0000000118583f83, menu=0x0000000118587313) at menu.c:1474:10
    frame #6: 0x000000010024e7d7 emacs`funcall_subr(subr=0x0000000100403c28, numargs=2, args=0x0000000118028188) at eval.c:3049:15
--8<---------------cut here---------------end--------------->8---


-- 
Best,

Eshel

bug#63495: 28.2; menu crashes on macos

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Alan Third <alan@idiocy.org> writes:
>
>> Can you please try this:
>>
>> modified   src/nsmenu.m
>> @@ -746,6 +746,8 @@ - (Lisp_Object)runMenuAt: (NSPoint)p forFrame: (struct frame *)f
>>    NSEvent *e, *event;
>>    long retVal;
>>  
>> +  needsUpdate = NO;
>> +
>>    /* p = [view convertPoint:p fromView: nil]; */
>>    p.y = NSHeight ([view frame]) - p.y;
>>    e = [[view window] currentEvent];
>>
>> At a guess, when the menu opens the first thing AppKit does is check if
>> it needs updated, and since a new menu starts with needsUpdate=YES, it
>> goes ahead and tries to do it, which overwrites some important
>> variables from the original "build" of the menu.
>>
>> The context menu is built and then displayed, as opposed to the
>> top-menu that is partially built, then when it's to be displayed is
>> updated and filled in.
>
> I tried it, unfortunately, that doesn't seem to solve the issue.  Emacs
> still crashes with a similar backtrace:
>
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3)
>     frame #0: 0x00000001000af1fd emacs`AREF(array=0x0000000000000000, idx=0) at lisp.h:1941:10
>    1938	AREF (Lisp_Object array, ptrdiff_t idx)
>    1939	{
>    1940	  eassert (0 <= idx && idx < gc_asize (array));
> -> 1941	  return XVECTOR (array)->contents[idx];
>    1942	}
>    1943
>    1944	INLINE Lisp_Object *
> Target 0: (emacs) stopped.
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3)
>   * frame #0: 0x00000001000af1fd emacs`AREF(array=0x0000000000000000, idx=0) at lisp.h:1941:10
>     frame #1: 0x00000001000b079e emacs`find_and_return_menu_selection(f=0x00000001030b0c30, keymaps=true, client_data=0x0000000110277e60) at menu.c:985:11
>     frame #2: 0x000000010037cc1a emacs`-[EmacsMenu runMenuAt:forFrame:keymaps:](self=0x000060000179c9c0, _cmd="runMenuAt:forFrame:keymaps:", p=(x = 2, y = 411), f=0x00000001030b0c30, keymaps=true) at nsmenu.m:769:9
>     frame #3: 0x0000000100380ac0 emacs`ns_menu_show(f=0x00000001030b0c30, x=2, y=97, menuflags=1, title=0x0000000102416284, error=0x00007ff7bfefcef0) at nsmenu.m:1069:9
>     frame #4: 0x00000001000b23f7 emacs`x_popup_menu_1(position=0x0000000118583f83, menu=0x0000000118587313) at menu.c:1410:17
>     frame #5: 0x00000001000b27d2 emacs`Fx_popup_menu(position=0x0000000118583f83, menu=0x0000000118587313) at menu.c:1474:10
>     frame #6: 0x000000010024e7d7 emacs`funcall_subr(subr=0x0000000100403c28, numargs=2, args=0x0000000118028188) at eval.c:3049:15

One fundamental problem I see with the current logic (or maybe I'm
misunderstanding something) is that, menuNeedsUpdate: is called for both
the menubar and for context menus.  However, the ns_update_menubar
routine does not even use the NSMenu that AppKit passed to
menuNeedsUpdate:, it always does this:

id menu = [NSApp mainMenu];

This means that the menu variable will always be the menubar.  The code
in ns_update_menubar is only prepared to handle menubar updates, but as
this function updates menu_items, a data structure that is used later by
the context menu in find_and_return_menu_selection, Emacs crashes
because of inconsistencies.

Is there any reason we need to do something for context menus in
menuNeedsUpdate:?  Alan said that context menus are completely built in
advance (as opposed to the menubar, which is partially built), so I
propose the following patch (which does seem to fix the crash for me and
doesn't cause regressions with the menubar):

diff --git a/src/nsmenu.m b/src/nsmenu.m
index 2c1f575bdf2..ca367d1abd1 100644
--- a/src/nsmenu.m
+++ b/src/nsmenu.m
@@ -477,6 +477,16 @@ - (instancetype)initWithTitle: (NSString *)title
    call to ns_update_menubar.  */
 - (void)menuNeedsUpdate: (NSMenu *)menu
 {
+
+  /* The context menu is built and then displayed, as opposed to the
+     top-menu, which is partially built and then updated and filled in
+     when it's time to display it.  Therefore, we don't call
+     ns_update_menubar if a context menu is active. */
+  if (context_menu_value != 0)
+    {
+      return;
+    }
+
 #ifdef NS_IMPL_GNUSTEP
   static int inside = 0;
 #endif

bug#63495: 28.2; menu crashes on macos

[Alan Third]

On Thu, Jul 13, 2023 at 10:47:35AM +0200, Daniel Martín wrote:
> One fundamental problem I see with the current logic (or maybe I'm
> misunderstanding something) is that, menuNeedsUpdate: is called for both
> the menubar and for context menus.  However, the ns_update_menubar
> routine does not even use the NSMenu that AppKit passed to
> menuNeedsUpdate:, it always does this:
> 
> id menu = [NSApp mainMenu];
>
> This means that the menu variable will always be the menubar.  The code
> in ns_update_menubar is only prepared to handle menubar updates, but as
> this function updates menu_items, a data structure that is used later by
> the context menu in find_and_return_menu_selection, Emacs crashes
> because of inconsistencies.

Indeed, it looks like context menus don't go anywhere near
ns_update_menubar and use similar, but not identical, code in
ns_menu_show to construct the menu contents.

> Is there any reason we need to do something for context menus in
> menuNeedsUpdate:?  Alan said that context menus are completely built in
> advance (as opposed to the menubar, which is partially built), so I
> propose the following patch (which does seem to fix the crash for me and
> doesn't cause regressions with the menubar):
> 
> diff --git a/src/nsmenu.m b/src/nsmenu.m
> index 2c1f575bdf2..ca367d1abd1 100644
> --- a/src/nsmenu.m
> +++ b/src/nsmenu.m
> @@ -477,6 +477,16 @@ - (instancetype)initWithTitle: (NSString *)title
>     call to ns_update_menubar.  */
>  - (void)menuNeedsUpdate: (NSMenu *)menu
>  {
> +
> +  /* The context menu is built and then displayed, as opposed to the
> +     top-menu, which is partially built and then updated and filled in
> +     when it's time to display it.  Therefore, we don't call
> +     ns_update_menubar if a context menu is active. */
> +  if (context_menu_value != 0)
> +    {
> +      return;
> +    }
> +
>  #ifdef NS_IMPL_GNUSTEP
>    static int inside = 0;
>  #endif

This was going to be my next suggestion, after checking that
context_menu_value is always non-zero when using the context menu and
zero when using the main menu. Which I haven't done.

The next best thing I can think of is to add a flag that marks it
specifically as a context menu, or create a specific context menu
class that over-rides menuNeedsUpdate, but I dislike the former as we
can probably work out it's a context menu in other ways, and the
latter is a bit ridiculous.
-- 
Alan Third

bug#63495: 28.2; menu crashes on macos

[Alan Third]

On Thu, Jul 13, 2023 at 10:47:35AM +0200, Daniel Martín wrote:
> One fundamental problem I see with the current logic (or maybe I'm
> misunderstanding something) is that, menuNeedsUpdate: is called for both
> the menubar and for context menus.  However, the ns_update_menubar
> routine does not even use the NSMenu that AppKit passed to
> menuNeedsUpdate:, it always does this:
> 
> id menu = [NSApp mainMenu];
> 
> This means that the menu variable will always be the menubar.  The code
> in ns_update_menubar is only prepared to handle menubar updates, but as
> this function updates menu_items, a data structure that is used later by
> the context menu in find_and_return_menu_selection, Emacs crashes
> because of inconsistencies.
> 
> Is there any reason we need to do something for context menus in
> menuNeedsUpdate:?  Alan said that context menus are completely built in
> advance (as opposed to the menubar, which is partially built), so I
> propose the following patch (which does seem to fix the crash for me and
> doesn't cause regressions with the menubar):
> 
> diff --git a/src/nsmenu.m b/src/nsmenu.m
> index 2c1f575bdf2..ca367d1abd1 100644
> --- a/src/nsmenu.m
> +++ b/src/nsmenu.m
> @@ -477,6 +477,16 @@ - (instancetype)initWithTitle: (NSString *)title
>     call to ns_update_menubar.  */
>  - (void)menuNeedsUpdate: (NSMenu *)menu
>  {
> +
> +  /* The context menu is built and then displayed, as opposed to the
> +     top-menu, which is partially built and then updated and filled in
> +     when it's time to display it.  Therefore, we don't call
> +     ns_update_menubar if a context menu is active. */
> +  if (context_menu_value != 0)
> +    {
> +      return;
> +    }
> +
>  #ifdef NS_IMPL_GNUSTEP
>    static int inside = 0;
>  #endif

If it hasn't already, this should probably be pushed into the emacs-29
branch, unless someone's noticed a problem with it, as I understand
the first(?) rc has already been released.

This fixes a crash.

Eli/Lars? Is it too late?

-- 
Alan Third

bug#63495: 28.2; menu crashes on macos

[Eli Zaretskii]

> Cc: 63495@debbugs.gnu.org, obriendavid1@gmail.com, me@eshelyaron.com
> Date: Tue, 25 Jul 2023 17:16:17 +0100
> From: Alan Third <alan@idiocy.org>
> 
> If it hasn't already, this should probably be pushed into the emacs-29
> branch, unless someone's noticed a problem with it, as I understand
> the first(?) rc has already been released.

RC1 is not a "release", it's a tentative release.  The release itself
will happen a few days from now, fingers crossed.

> This fixes a crash.
> 
> Eli/Lars? Is it too late?

Too late for Emacs 29.1, yes.  Unless a much more serious catastrophe
will be uncovered soon, in which case I will have to make one more
pretest.

bug#63495: 28.2; menu crashes on macos

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 63495@debbugs.gnu.org, obriendavid1@gmail.com, me@eshelyaron.com
>> Date: Tue, 25 Jul 2023 17:16:17 +0100
>> From: Alan Third <alan@idiocy.org>
>>
>> If it hasn't already, this should probably be pushed into the emacs-29
>> branch, unless someone's noticed a problem with it, as I understand
>> the first(?) rc has already been released.
>
> RC1 is not a "release", it's a tentative release.  The release itself
> will happen a few days from now, fingers crossed.
>
>> This fixes a crash.
>>
>> Eli/Lars? Is it too late?
>
> Too late for Emacs 29.1, yes.  Unless a much more serious catastrophe
> will be uncovered soon, in which case I will have to make one more
> pretest.

Would it make sense to install it on the emacs-29 now?  I don't see it
installed on master either.

bug#63495: 28.2; menu crashes on macos

[Alan Third]

On Wed, Sep 06, 2023 at 01:16:07PM -0700, Stefan Kangas wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Cc: 63495@debbugs.gnu.org, obriendavid1@gmail.com, me@eshelyaron.com
> >> Date: Tue, 25 Jul 2023 17:16:17 +0100
> >> From: Alan Third <alan@idiocy.org>
> >>
> >> If it hasn't already, this should probably be pushed into the emacs-29
> >> branch, unless someone's noticed a problem with it, as I understand
> >> the first(?) rc has already been released.
> >
> > RC1 is not a "release", it's a tentative release.  The release itself
> > will happen a few days from now, fingers crossed.
> >
> >> This fixes a crash.
> >>
> >> Eli/Lars? Is it too late?
> >
> > Too late for Emacs 29.1, yes.  Unless a much more serious catastrophe
> > will be uncovered soon, in which case I will have to make one more
> > pretest.
> 
> Would it make sense to install it on the emacs-29 now?  I don't see it
> installed on master either.

I think so.

I had assumed Daniel would have pushed it, since it was his patch, so
I didn't follow up on it.
-- 
Alan Third

bug#63495: 28.2; menu crashes on macos

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Alan Third <alan@idiocy.org> writes:

>
> I think so.
>
> I had assumed Daniel would have pushed it, since it was his patch, so
> I didn't follow up on it.

Sorry, I don't have commit rights.  I don't know if someone would want
to give me those rights, but I'd just use them to push accepted and code
reviewed patches that I send to this list.

bug#63495: 28.2; menu crashes on macos

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 6 Sep 2023 13:16:07 -0700
> Cc: Alan Third <alan@idiocy.org>, 63495@debbugs.gnu.org, obriendavid1@gmail.com, 
> 	me@eshelyaron.com, mardani29@yahoo.es
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > RC1 is not a "release", it's a tentative release.  The release itself
> > will happen a few days from now, fingers crossed.
> >
> >> This fixes a crash.
> >>
> >> Eli/Lars? Is it too late?
> >
> > Too late for Emacs 29.1, yes.  Unless a much more serious catastrophe
> > will be uncovered soon, in which case I will have to make one more
> > pretest.
> 
> Would it make sense to install it on the emacs-29 now?  I don't see it
> installed on master either.

Installed on the emacs-29 branch, and closing the bug.

(I usually rely on people who have interest in a bug to ping about its
resolution when the time comes...)

Thanks.