* bug#63495: 28.2; menu crashes on macos
@ 2023-05-13 15:36 David O'Brien
2023-05-14 9:18 ` Eli Zaretskii
2023-07-08 18:18 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 19+ messages in thread
From: David O'Brien @ 2023-05-13 15:36 UTC (permalink / raw)
To: 63495
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))
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-05-13 15:36 bug#63495: 28.2; menu crashes on macos David O'Brien
@ 2023-05-14 9:18 ` Eli Zaretskii
2023-07-08 18:18 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2023-05-14 9:18 UTC (permalink / raw)
To: David O'Brien; +Cc: 63495
> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-05-13 15:36 bug#63495: 28.2; menu crashes on macos David O'Brien
2023-05-14 9:18 ` Eli Zaretskii
@ 2023-07-08 18:18 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-09 7:29 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 19+ messages in thread
From: Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-07-08 18:18 UTC (permalink / raw)
To: David O'Brien; +Cc: 63495
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-07-08 18:18 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-07-09 7:29 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-10 21:00 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 19+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-07-09 7:29 UTC (permalink / raw)
To: 63495; +Cc: obriendavid1, mardani29
>> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-07-09 7:29 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-07-10 21:00 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-10 22:33 ` Alan Third
0 siblings, 1 reply; 19+ messages in thread
From: Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-07-10 21:00 UTC (permalink / raw)
To: 63495; +Cc: alan, obriendavid1, me
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-07-10 21:00 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-07-10 22:33 ` Alan Third
2023-07-11 5:40 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 19+ messages in thread
From: Alan Third @ 2023-07-10 22:33 UTC (permalink / raw)
To: Daniel Martín; +Cc: obriendavid1, me, 63495
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-07-10 22:33 ` Alan Third
@ 2023-07-11 5:40 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-12 17:25 ` Alan Third
0 siblings, 1 reply; 19+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-07-11 5:40 UTC (permalink / raw)
To: Alan Third; +Cc: obriendavid1, 63495, Daniel Martín
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 :(
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-07-11 5:40 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-07-12 17:25 ` Alan Third
2023-07-12 17:44 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 19+ messages in thread
From: Alan Third @ 2023-07-12 17:25 UTC (permalink / raw)
To: Eshel Yaron; +Cc: obriendavid1, 63495, Daniel Martín
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-07-12 17:25 ` Alan Third
@ 2023-07-12 17:44 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-12 19:37 ` Alan Third
0 siblings, 1 reply; 19+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-07-12 17:44 UTC (permalink / raw)
To: Alan Third; +Cc: obriendavid1, 63495, Daniel Martín
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?
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-07-12 17:44 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-07-12 19:37 ` Alan Third
2023-07-13 6:16 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 19+ messages in thread
From: Alan Third @ 2023-07-12 19:37 UTC (permalink / raw)
To: Eshel Yaron; +Cc: obriendavid1, 63495, Daniel Martín
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-07-12 19:37 ` Alan Third
@ 2023-07-13 6:16 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-13 8:47 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 19+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-07-13 6:16 UTC (permalink / raw)
To: Alan Third; +Cc: obriendavid1, 63495, Daniel Martín
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-07-13 6:16 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-07-13 8:47 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-13 19:41 ` Alan Third
2023-07-25 16:16 ` Alan Third
0 siblings, 2 replies; 19+ messages in thread
From: Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-07-13 8:47 UTC (permalink / raw)
To: 63495; +Cc: alan, obriendavid1, me
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
^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-07-13 8:47 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-07-13 19:41 ` Alan Third
2023-07-25 16:16 ` Alan Third
1 sibling, 0 replies; 19+ messages in thread
From: Alan Third @ 2023-07-13 19:41 UTC (permalink / raw)
To: Daniel Martín; +Cc: 63495, obriendavid1, me
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-07-13 8:47 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-13 19:41 ` Alan Third
@ 2023-07-25 16:16 ` Alan Third
2023-07-25 17:47 ` Eli Zaretskii
1 sibling, 1 reply; 19+ messages in thread
From: Alan Third @ 2023-07-25 16:16 UTC (permalink / raw)
To: Daniel Martín; +Cc: 63495, obriendavid1, me
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-07-25 16:16 ` Alan Third
@ 2023-07-25 17:47 ` Eli Zaretskii
2023-09-06 20:16 ` Stefan Kangas
0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2023-07-25 17:47 UTC (permalink / raw)
To: Alan Third; +Cc: 63495, obriendavid1, me, mardani29
> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-07-25 17:47 ` Eli Zaretskii
@ 2023-09-06 20:16 ` Stefan Kangas
2023-09-06 20:29 ` Alan Third
2023-09-07 5:23 ` Eli Zaretskii
0 siblings, 2 replies; 19+ messages in thread
From: Stefan Kangas @ 2023-09-06 20:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Alan Third, obriendavid1, me, 63495, mardani29
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-09-06 20:16 ` Stefan Kangas
@ 2023-09-06 20:29 ` Alan Third
2023-09-06 22:34 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-07 5:23 ` Eli Zaretskii
1 sibling, 1 reply; 19+ messages in thread
From: Alan Third @ 2023-09-06 20:29 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Eli Zaretskii, obriendavid1, me, 63495, mardani29
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-09-06 20:29 ` Alan Third
@ 2023-09-06 22:34 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 19+ messages in thread
From: Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-09-06 22:34 UTC (permalink / raw)
To: Alan Third; +Cc: Eli Zaretskii, obriendavid1, me, Stefan Kangas, 63495
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#63495: 28.2; menu crashes on macos
2023-09-06 20:16 ` Stefan Kangas
2023-09-06 20:29 ` Alan Third
@ 2023-09-07 5:23 ` Eli Zaretskii
1 sibling, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2023-09-07 5:23 UTC (permalink / raw)
To: Stefan Kangas; +Cc: alan, obriendavid1, me, 63495-done, mardani29
> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2023-09-07 5:23 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-13 15:36 bug#63495: 28.2; menu crashes on macos David O'Brien
2023-05-14 9:18 ` Eli Zaretskii
2023-07-08 18:18 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-09 7:29 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-10 21:00 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-10 22:33 ` Alan Third
2023-07-11 5:40 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-12 17:25 ` Alan Third
2023-07-12 17:44 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-12 19:37 ` Alan Third
2023-07-13 6:16 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-13 8:47 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-13 19:41 ` Alan Third
2023-07-25 16:16 ` Alan Third
2023-07-25 17:47 ` Eli Zaretskii
2023-09-06 20:16 ` Stefan Kangas
2023-09-06 20:29 ` Alan Third
2023-09-06 22:34 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-07 5:23 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).