Package: emacs;
Reported by: Aaron Jensen <aaronjensen <at> gmail.com>
Date: Tue, 20 Dec 2022 15:12:01 UTC
Severity: normal
Found in version 29.0.60
To reply to this bug, email your comments to 60220 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Tue, 20 Dec 2022 15:12:01 GMT) Full text and rfc822 format available.Aaron Jensen <aaronjensen <at> gmail.com>:bug-gnu-emacs <at> gnu.org.
(Tue, 20 Dec 2022 15:12:01 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: bug-gnu-emacs <at> gnu.org Subject: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Tue, 20 Dec 2022 10:11:17 -0500
I've been seeing this crash somewhat frequently recently on emacs-29
master. It's possibly since updating to macOS Ventura (13.1). I can't
seem to reproduce it with debug symbols and a debugger attached, so this
may be the best I can provide right now. It tends to happen shortly
after I restart Emacs using `restart-emacs'. It also just happened
randomly while I didn't even have Emacs focused. I believe I have seen
it happen once when starting Emacs without a restart.
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Process: Emacs [600]
Path: /opt/homebrew/*/Emacs.app/Contents/MacOS/Emacs
Identifier: org.gnu.Emacs
Version: Version 29.0.60 (9.0)
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
User ID: 501
Date/Time: 2022-12-20 10:06:15.9650 -0500
OS Version: macOS 13.1 (22C65)
Report Version: 12
Anonymous UUID: CD1F31D7-5E61-2935-643D-55F58CD29C12
Sleep/Wake UUID: 254FA28B-6F01-412E-8D38-DE2EC5BE8B25
Time Awake Since Boot: 16000 seconds
Time Since Wake: 559 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x1820921b0 __pthread_kill + 8
1 libsystem_pthread.dylib 0x1820c8cec pthread_kill + 288
2 libsystem_c.dylib 0x181fcaa50 raise + 32
3 Emacs 0x100309af4 terminate_due_to_signal + 204
4 Emacs 0x10030a2f0 emacs_abort + 20
5 Emacs 0x1002d8db8 ns_term_shutdown + 132
6 Emacs 0x1001c4b9c shut_down_emacs + 332
7 Emacs 0x100309abc terminate_due_to_signal + 148
8 Emacs 0x1001e708c handle_fatal_signal + 16
9 Emacs 0x1001e7108 deliver_thread_signal + 124
10 Emacs 0x1001e5708 deliver_fatal_thread_signal + 12
11 libsystem_platform.dylib 0x1820f72a4 _sigtramp + 56
12 dyld 0x181e15a00 abort_with_payload_wrapper_internal + 104
13 dyld 0x181e15a34 abort_with_payload + 16
14 dyld 0x181da40a4 dyld4::halt(char const*) + 328
15 dyld 0x181e14584 abort_report_np + 80
16 dyld 0x181e145c0 __assert_rtn + 60
17 dyld 0x181e11794 dyld4::Loader::contains(dyld4::RuntimeState&, void const*, void const**, unsigned long long*, unsigned char*) const (.cold.1) + 44
18 dyld 0x181db3328 dyld4::Loader::contains(dyld4::RuntimeState&, void const*, void const**, unsigned long long*, unsigned char*) const + 92
19 dyld 0x181dd3af4 invocation function for block in dyld4::APIs::findImageMappedAt(void const*, dyld3::MachOLoaded const**, bool*, char const**, void const**, unsigned long long*, unsigned char*) + 144
20 dyld 0x181da744c dyld4::RuntimeState::withLoadersReadLock(void () block_pointer) + 92
21 dyld 0x181dd3904 dyld4::APIs::findImageMappedAt(void const*, dyld3::MachOLoaded const**, bool*, char const**, void const**, unsigned long long*, unsigned char*) + 720
22 dyld 0x181dd3c6c dyld4::APIs::dyld_image_path_containing_address(void const*) + 72
23 libsystem_trace.dylib 0x181e702e8 _os_trace_dylib_or_main_executable_was_loaded + 84
24 dyld 0x181dac624 invocation function for block in dyld4::RuntimeState::notifyLoad(std::__1::span<dyld4::Loader const*, 18446744073709551615ul> const&) + 248
25 dyld 0x181da79f0 dyld4::RuntimeState::withNotifiersReadLock(void () block_pointer) + 96
26 dyld 0x181dac2cc dyld4::RuntimeState::notifyLoad(std::__1::span<dyld4::Loader const*, 18446744073709551615ul> const&) + 356
27 dyld 0x181dd4a9c dyld4::APIs::dlopen_from(char const*, int, void*) + 1200
28 Emacs 0x10028cdb8 Fnative_elisp_load + 356
29 Emacs 0x100283948 exec_byte_code + 2988
30 Emacs 0x10024272c Ffuncall + 316
31 Emacs 0x100244f30 Fapply + 612
32 Emacs 0x10023feb0 apply1 + 52
33 Emacs 0x1002433c0 internal_condition_case_1 + 100
34 Emacs 0x100298e48 exec_sentinel + 292
35 Emacs 0x10029012c status_notify + 780
36 Emacs 0x1002967a8 wait_reading_process_output + 1580
37 Emacs 0x1001cd1e8 read_char + 8656
38 Emacs 0x1001c9550 read_key_sequence + 1056
39 Emacs 0x1001c7dc0 command_loop_1 + 700
40 Emacs 0x100243334 internal_condition_case + 96
41 Emacs 0x1001c7af0 command_loop_2 + 52
42 Emacs 0x100242d58 internal_catch + 88
43 Emacs 0x100309f18 command_loop.cold.1 + 80
44 Emacs 0x1001c7490 command_loop + 152
45 Emacs 0x1001c734c recursive_edit_1 + 148
46 Emacs 0x1001c75b0 Frecursive_edit + 264
47 Emacs 0x1001c692c main + 7484
48 dyld 0x181d9fe50 start + 2544
Thread 1:: gmain
0 libsystem_kernel.dylib 0x182094a00 __select + 8
1 libglib-2.0.0.dylib 0x10116bb20 g_poll + 424
2 libglib-2.0.0.dylib 0x10115ecc4 g_main_context_iterate + 340
3 libglib-2.0.0.dylib 0x10115ed8c g_main_context_iteration + 60
4 libglib-2.0.0.dylib 0x101160124 glib_worker_main + 48
5 libglib-2.0.0.dylib 0x1011833a8 g_thread_proxy + 68
6 libsystem_pthread.dylib 0x1820c906c _pthread_start + 148
7 libsystem_pthread.dylib 0x1820c3e2c thread_start + 8
Thread 2:
0 libsystem_kernel.dylib 0x18208ffa4 __pselect + 8
1 libsystem_kernel.dylib 0x18208fe7c pselect$DARWIN_EXTSN + 64
2 Emacs 0x1002d9e98 -[EmacsApp fd_handler:] + 184
3 Foundation 0x1830a9470 __NSThread__start__ + 716
4 libsystem_pthread.dylib 0x1820c906c _pthread_start + 148
5 libsystem_pthread.dylib 0x1820c3e2c thread_start + 8
Thread 3:: com.apple.NSEventThread
0 libsystem_kernel.dylib 0x182089d70 mach_msg2_trap + 8
1 libsystem_kernel.dylib 0x18209b8a4 mach_msg2_internal + 80
2 libsystem_kernel.dylib 0x1820925c4 mach_msg_overwrite + 540
3 libsystem_kernel.dylib 0x18208a0ec mach_msg + 24
4 CoreFoundation 0x1821a8bc0 __CFRunLoopServiceMachPort + 160
5 CoreFoundation 0x1821a74ac __CFRunLoopRun + 1232
6 CoreFoundation 0x1821a6888 CFRunLoopRunSpecific + 612
7 AppKit 0x185552410 _NSEventThread + 172
8 libsystem_pthread.dylib 0x1820c906c _pthread_start + 148
9 libsystem_pthread.dylib 0x1820c3e2c thread_start + 8
Thread 4:
0 libsystem_pthread.dylib 0x1820c3e18 start_wqthread + 0
Thread 5:
0 libsystem_pthread.dylib 0x1820c3e18 start_wqthread + 0
Thread 0 crashed with ARM Thread State (64-bit):
x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0x00006000012bfbc0
x4: 0x00006000012bfba0 x5: 0x0000000000000000 x6: 0x0000000000000000 x7: 0x0000000000000690
x8: 0x476e5febae5bb0c0 x9: 0x476e5fea73194a40 x10: 0x0000000000000001 x11: 0x0000000000000003
x12: 0x0000000000000001 x13: 0x000060000087d480 x14: 0x01000001dd44fee9 x15: 0x00000001dd44fee8
x16: 0x0000000000000148 x17: 0x00000001e22707f0 x18: 0x0000000000000000 x19: 0x0000000000000006
x20: 0x00000001dd42fa80 x21: 0x0000000000000103 x22: 0x00000001dd42fb60 x23: 0x0000000000000009
x24: 0x0000000000000006 x25: 0x000000016fd00a17 x26: 0x000000016fd00a18 x27: 0x0000000181cfc000
x28: 0x0000000000000000 fp: 0x000000016fcff270 lr: 0x00000001820c8cec
sp: 0x000000016fcff250 pc: 0x00000001820921b0 cpsr: 0x40001000
far: 0x000060000111c030 esr: 0x56000080 Address size fault
Binary Images:
0x182089000 - 0x1820c1ff3 libsystem_kernel.dylib (*) <aebf397e-e2ef-3a49-be58-23d4558511f6> /usr/lib/system/libsystem_kernel.dylib
0x1820c2000 - 0x1820ceffb libsystem_pthread.dylib (*) <132084c6-c347-3489-9ac2-fcaad21cdb73> /usr/lib/system/libsystem_pthread.dylib
0x181f89000 - 0x182009ff3 libsystem_c.dylib (*) <756cd0d2-3241-3a74-8c59-02632dcee221> /usr/lib/system/libsystem_c.dylib
0x1000fc000 - 0x100353fff org.gnu.Emacs (Version 29.0.60) <96c2c81f-a22d-3b5c-b9bc-7b549603be41> /opt/homebrew/*/Emacs.app/Contents/MacOS/Emacs
0x1820f3000 - 0x1820faffb libsystem_platform.dylib (*) <b215ae90-4ed2-3fcd-8ccc-6c0d93cc4f41> /usr/lib/system/libsystem_platform.dylib
0x181d9a000 - 0x181e24b63 dyld (*) <487cfdeb-9b07-39bf-bfb9-970b61aea2d1> /usr/lib/dyld
0x181e6e000 - 0x181e87fff libsystem_trace.dylib (*) <616f473a-eb21-377d-b3b4-f1581f127f0d> /usr/lib/system/libsystem_trace.dylib
0x101128000 - 0x10120ffff libglib-2.0.0.dylib (*) <f593e720-37ac-3b64-8d96-f9c330062fec> /opt/homebrew/*/libglib-2.0.0.dylib
0x183053000 - 0x183a8bfff com.apple.Foundation (6.9) <f1f5f857-8c3c-36d5-bc27-7702d6795468> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x182127000 - 0x1825fefff com.apple.CoreFoundation (6.9) <fd16d6d9-10c0-323b-b43b-9781c4a4d268> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x1853ef000 - 0x1862f9fff com.apple.AppKit (6.9) <dbbd4dea-6c68-3200-a81b-79b6a62f4669> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 10321
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: 203103
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=2.1G written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=2.1G(100%)
VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
Accelerate framework 256K 2
Activity Tracing 256K 1
CG backing stores 7104K 8
CG image 336K 11
ColorSync 544K 27
CoreAnimation 96K 6
CoreGraphics 48K 3
CoreUI image data 1104K 9
Foundation 16K 1
Kernel Alloc Once 32K 1
MALLOC 585.3M 124
MALLOC guard page 192K 10
MALLOC_MEDIUM (reserved) 1.1G 10 reserved VM address space (unallocated)
MALLOC_NANO (reserved) 384.0M 1 reserved VM address space (unallocated)
STACK GUARD 54.5M 6
Stack 12.2M 7
VM_ALLOCATE 336K 21
__AUTH 680K 181
__AUTH_CONST 12.4M 348
__CTF 756 1
__DATA 45.5M 1178
__DATA_CONST 23.8M 773
__DATA_DIRTY 709K 112
__FONT_DATA 2352 1
__LINKEDIT 803.5M 701
__OBJC_CONST 1375K 152
__OBJC_RO 65.4M 1
__OBJC_RW 1986K 1
__TEXT 315.6M 1063
dyld private memory 1792K 8
mapped file 1.0G 362
shared memory 912K 16
=========== ======= =======
TOTAL 4.4G 5146
TOTAL, minus reserved VM space 2.9G 5146
-----------
Full Report
-----------
{"app_name":"Emacs","timestamp":"2022-12-20 10:06:19.00 -0500","app_version":"Version 29.0.60","slice_uuid":"96c2c81f-a22d-3b5c-b9bc-7b549603be41","build_version":"9.0","platform":1,"bundleID":"org.gnu.Emacs","share_with_app_devs":0,"is_first_party":0,"bug_type":"309","os_version":"macOS 13.1 (22C65)","roots_installed":0,"name":"Emacs","incident_id":"0E200848-007D-431C-8807-01515F5BC71A"}
{
"uptime" : 16000,
"procRole" : "Background",
"version" : 2,
"userID" : 501,
"deployVersion" : 210,
"modelCode" : "MacBookPro18,2",
"coalitionID" : 590,
"osVersion" : {
"train" : "macOS 13.1",
"build" : "22C65",
"releaseType" : "User"
},
"captureTime" : "2022-12-20 10:06:15.9650 -0500",
"incident" : "0E200848-007D-431C-8807-01515F5BC71A",
"pid" : 600,
"translated" : false,
"cpuType" : "ARM-64",
"roots_installed" : 0,
"bug_type" : "309",
"procLaunch" : "2022-12-20 01:35:41.4017 -0500",
"procStartAbsTime" : 730668820,
"procExitAbsTime" : 392482092785,
"procName" : "Emacs",
"procPath" : "\/opt\/homebrew\/*\/Emacs.app\/Contents\/MacOS\/Emacs",
"bundleInfo" : {"CFBundleShortVersionString":"Version 29.0.60","CFBundleVersion":"9.0","CFBundleIdentifier":"org.gnu.Emacs"},
"storeInfo" : {"deviceIdentifierForVendor":"3C400CCD-6334-555D-B7DD-B0EF9E071C95","thirdParty":true},
"parentProc" : "launchd",
"parentPid" : 1,
"coalitionName" : "org.gnu.Emacs",
"crashReporterKey" : "CD1F31D7-5E61-2935-643D-55F58CD29C12",
"throttleTimeout" : 2147483647,
"wakeTime" : 559,
"sleepWakeUUID" : "254FA28B-6F01-412E-8D38-DE2EC5BE8B25",
"sip" : "enabled",
"exception" : {"codes":"0x0000000000000000, 0x0000000000000000","rawCodes":[0,0],"type":"EXC_CRASH","signal":"SIGABRT"},
"extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":0,"task_for_pid":203103},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":10321},"warnings":0},
"faultingThread" : 0,
"threads" : [{"triggered":true,"id":5557,"threadState":{"x":[{"value":0},{"value":0},{"value":0},{"value":105553135926208},{"value":105553135926176},{"value":0},{"value":0},{"value":1680},{"value":5147156889978253504},{"value":5147156884689078848},{"value":1},{"value":3},{"value":1},{"value":105553125168256},{"value":72057602045181673,"symbolLocation":72057594037927937,"symbol":"OBJC_CLASS_$_NSAutoreleasePool"},{"value":8007253736,"symbolLocation":0,"symbol":"OBJC_CLASS_$_NSAutoreleasePool"},{"value":328},{"value":8089176048},{"value":0},{"value":6},{"value":8007121536,"symbolLocation":0,"symbol":"_main_thread"},{"value":259},{"value":8007121760,"symbolLocation":224,"symbol":"_main_thread"},{"value":9},{"value":6},{"value":6170872343},{"value":6170872344},{"value":6472843264},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6476827884},"cpsr":{"value":1073745920},"fp":{"value":6170866288},"sp":{"value":6170866256},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6476603824,"matchesCrashFrame":1},"far":{"value":105553134207024}},"queue":"com.apple.main-thread","frames":[{"imageOffset":37296,"symbol":"__pthread_kill","symbolLocation":8,"imageIndex":0},{"imageOffset":27884,"symbol":"pthread_kill","symbolLocation":288,"imageIndex":1},{"imageOffset":268880,"symbol":"raise","symbolLocation":32,"imageIndex":2},{"imageOffset":2153204,"symbol":"terminate_due_to_signal","symbolLocation":204,"imageIndex":3},{"imageOffset":2155248,"symbol":"emacs_abort","symbolLocation":20,"imageIndex":3},{"imageOffset":1953208,"symbol":"ns_term_shutdown","symbolLocation":132,"imageIndex":3},{"imageOffset":822172,"symbol":"shut_down_emacs","symbolLocation":332,"imageIndex":3},{"imageOffset":2153148,"symbol":"terminate_due_to_signal","symbolLocation":148,"imageIndex":3},{"imageOffset":962700,"symbol":"handle_fatal_signal","symbolLocation":16,"imageIndex":3},{"imageOffset":962824,"symbol":"deliver_thread_signal","symbolLocation":124,"imageIndex":3},{"imageOffset":956168,"symbol":"deliver_fatal_thread_signal","symbolLocation":12,"imageIndex":3},{"imageOffset":17060,"symbol":"_sigtramp","symbolLocation":56,"imageIndex":4},{"imageOffset":506368,"symbol":"abort_with_payload_wrapper_internal","symbolLocation":104,"imageIndex":5},{"imageOffset":506420,"symbol":"abort_with_payload","symbolLocation":16,"imageIndex":5},{"imageOffset":41124,"symbol":"dyld4::halt(char const*)","symbolLocation":328,"imageIndex":5},{"imageOffset":501124,"symbol":"abort_report_np","symbolLocation":80,"imageIndex":5},{"imageOffset":501184,"symbol":"__assert_rtn","symbolLocation":60,"imageIndex":5},{"imageOffset":489364,"symbol":"dyld4::Loader::contains(dyld4::RuntimeState&, void const*, void const**, unsigned long long*, unsigned char*) const (.cold.1)","symbolLocation":44,"imageIndex":5},{"imageOffset":103208,"symbol":"dyld4::Loader::contains(dyld4::RuntimeState&, void const*, void const**, unsigned long long*, unsigned char*) const","symbolLocation":92,"imageIndex":5},{"imageOffset":236276,"symbol":"invocation function for block in dyld4::APIs::findImageMappedAt(void const*, dyld3::MachOLoaded const**, bool*, char const**, void const**, unsigned long long*, unsigned char*)","symbolLocation":144,"imageIndex":5},{"imageOffset":54348,"symbol":"dyld4::RuntimeState::withLoadersReadLock(void () block_pointer)","symbolLocation":92,"imageIndex":5},{"imageOffset":235780,"symbol":"dyld4::APIs::findImageMappedAt(void const*, dyld3::MachOLoaded const**, bool*, char const**, void const**, unsigned long long*, unsigned char*)","symbolLocation":720,"imageIndex":5},{"imageOffset":236652,"symbol":"dyld4::APIs::dyld_image_path_containing_address(void const*)","symbolLocation":72,"imageIndex":5},{"imageOffset":8936,"symbol":"_os_trace_dylib_or_main_executable_was_loaded","symbolLocation":84,"imageIndex":6},{"imageOffset":75300,"symbol":"invocation function for block in dyld4::RuntimeState::notifyLoad(std::__1::span<dyld4::Loader const*, 18446744073709551615ul> const&)","symbolLocation":248,"imageIndex":5},{"imageOffset":55792,"symbol":"dyld4::RuntimeState::withNotifiersReadLock(void () block_pointer)","symbolLocation":96,"imageIndex":5},{"imageOffset":74444,"symbol":"dyld4::RuntimeState::notifyLoad(std::__1::span<dyld4::Loader const*, 18446744073709551615ul> const&)","symbolLocation":356,"imageIndex":5},{"imageOffset":240284,"symbol":"dyld4::APIs::dlopen_from(char const*, int, void*)","symbolLocation":1200,"imageIndex":5},{"imageOffset":1641912,"symbol":"Fnative_elisp_load","symbolLocation":356,"imageIndex":3},{"imageOffset":1603912,"symbol":"exec_byte_code","symbolLocation":2988,"imageIndex":3},{"imageOffset":1337132,"symbol":"Ffuncall","symbolLocation":316,"imageIndex":3},{"imageOffset":1347376,"symbol":"Fapply","symbolLocation":612,"imageIndex":3},{"imageOffset":1326768,"symbol":"apply1","symbolLocation":52,"imageIndex":3},{"imageOffset":1340352,"symbol":"internal_condition_case_1","symbolLocation":100,"imageIndex":3},{"imageOffset":1691208,"symbol":"exec_sentinel","symbolLocation":292,"imageIndex":3},{"imageOffset":1655084,"symbol":"status_notify","symbolLocation":780,"imageIndex":3},{"imageOffset":1681320,"symbol":"wait_reading_process_output","symbolLocation":1580,"imageIndex":3},{"imageOffset":856552,"symbol":"read_char","symbolLocation":8656,"imageIndex":3},{"imageOffset":841040,"symbol":"read_key_sequence","symbolLocation":1056,"imageIndex":3},{"imageOffset":835008,"symbol":"command_loop_1","symbolLocation":700,"imageIndex":3},{"imageOffset":1340212,"symbol":"internal_condition_case","symbolLocation":96,"imageIndex":3},{"imageOffset":834288,"symbol":"command_loop_2","symbolLocation":52,"imageIndex":3},{"imageOffset":1338712,"symbol":"internal_catch","symbolLocation":88,"imageIndex":3},{"imageOffset":2154264,"symbol":"command_loop.cold.1","symbolLocation":80,"imageIndex":3},{"imageOffset":832656,"symbol":"command_loop","symbolLocation":152,"imageIndex":3},{"imageOffset":832332,"symbol":"recursive_edit_1","symbolLocation":148,"imageIndex":3},{"imageOffset":832944,"symbol":"Frecursive_edit","symbolLocation":264,"imageIndex":3},{"imageOffset":829740,"symbol":"main","symbolLocation":7484,"imageIndex":3},{"imageOffset":24144,"symbol":"start","symbolLocation":2544,"imageIndex":5}]},{"id":6350,"name":"gmain","frames":[{"imageOffset":47616,"symbol":"__select","symbolLocation":8,"imageIndex":0},{"imageOffset":277280,"symbol":"g_poll","symbolLocation":424,"imageIndex":7},{"imageOffset":224452,"symbol":"g_main_context_iterate","symbolLocation":340,"imageIndex":7},{"imageOffset":224652,"symbol":"g_main_context_iteration","symbolLocation":60,"imageIndex":7},{"imageOffset":229668,"symbol":"glib_worker_main","symbolLocation":48,"imageIndex":7},{"imageOffset":373672,"symbol":"g_thread_proxy","symbolLocation":68,"imageIndex":7},{"imageOffset":28780,"symbol":"_pthread_start","symbolLocation":148,"imageIndex":1},{"imageOffset":7724,"symbol":"thread_start","symbolLocation":8,"imageIndex":1}]},{"id":6354,"frames":[{"imageOffset":28580,"symbol":"__pselect","symbolLocation":8,"imageIndex":0},{"imageOffset":28284,"symbol":"pselect$DARWIN_EXTSN","symbolLocation":64,"imageIndex":0},{"imageOffset":1957528,"symbol":"-[EmacsApp fd_handler:]","symbolLocation":184,"imageIndex":3},{"imageOffset":353392,"symbol":"__NSThread__start__","symbolLocation":716,"imageIndex":8},{"imageOffset":28780,"symbol":"_pthread_start","symbolLocation":148,"imageIndex":1},{"imageOffset":7724,"symbol":"thread_start","symbolLocation":8,"imageIndex":1}]},{"id":6360,"name":"com.apple.NSEventThread","frames":[{"imageOffset":3440,"symbol":"mach_msg2_trap","symbolLocation":8,"imageIndex":0},{"imageOffset":75940,"symbol":"mach_msg2_internal","symbolLocation":80,"imageIndex":0},{"imageOffset":38340,"symbol":"mach_msg_overwrite","symbolLocation":540,"imageIndex":0},{"imageOffset":4332,"symbol":"mach_msg","symbolLocation":24,"imageIndex":0},{"imageOffset":531392,"symbol":"__CFRunLoopServiceMachPort","symbolLocation":160,"imageIndex":9},{"imageOffset":525484,"symbol":"__CFRunLoopRun","symbolLocation":1232,"imageIndex":9},{"imageOffset":522376,"symbol":"CFRunLoopRunSpecific","symbolLocation":612,"imageIndex":9},{"imageOffset":1455120,"symbol":"_NSEventThread","symbolLocation":172,"imageIndex":10},{"imageOffset":28780,"symbol":"_pthread_start","symbolLocation":148,"imageIndex":1},{"imageOffset":7724,"symbol":"thread_start","symbolLocation":8,"imageIndex":1}]},{"id":187481,"frames":[{"imageOffset":7704,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":1}]},{"id":188009,"frames":[{"imageOffset":7704,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":1}]}],
"usedImages" : [
{
"source" : "P",
"arch" : "arm64e",
"base" : 6476566528,
"size" : 233460,
"uuid" : "aebf397e-e2ef-3a49-be58-23d4558511f6",
"path" : "\/usr\/lib\/system\/libsystem_kernel.dylib",
"name" : "libsystem_kernel.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 6476800000,
"size" : 53244,
"uuid" : "132084c6-c347-3489-9ac2-fcaad21cdb73",
"path" : "\/usr\/lib\/system\/libsystem_pthread.dylib",
"name" : "libsystem_pthread.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 6475517952,
"size" : 528372,
"uuid" : "756cd0d2-3241-3a74-8c59-02632dcee221",
"path" : "\/usr\/lib\/system\/libsystem_c.dylib",
"name" : "libsystem_c.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4295999488,
"CFBundleShortVersionString" : "Version 29.0.60",
"CFBundleIdentifier" : "org.gnu.Emacs",
"size" : 2457600,
"uuid" : "96c2c81f-a22d-3b5c-b9bc-7b549603be41",
"path" : "\/opt\/homebrew\/*\/Emacs.app\/Contents\/MacOS\/Emacs",
"name" : "Emacs",
"CFBundleVersion" : "9.0"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 6477000704,
"size" : 32764,
"uuid" : "b215ae90-4ed2-3fcd-8ccc-6c0d93cc4f41",
"path" : "\/usr\/lib\/system\/libsystem_platform.dylib",
"name" : "libsystem_platform.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 6473490432,
"size" : 568164,
"uuid" : "487cfdeb-9b07-39bf-bfb9-970b61aea2d1",
"path" : "\/usr\/lib\/dyld",
"name" : "dyld"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 6474358784,
"size" : 106496,
"uuid" : "616f473a-eb21-377d-b3b4-f1581f127f0d",
"path" : "\/usr\/lib\/system\/libsystem_trace.dylib",
"name" : "libsystem_trace.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4312956928,
"size" : 950272,
"uuid" : "f593e720-37ac-3b64-8d96-f9c330062fec",
"path" : "\/opt\/homebrew\/*\/libglib-2.0.0.dylib",
"name" : "libglib-2.0.0.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 6493122560,
"CFBundleShortVersionString" : "6.9",
"CFBundleIdentifier" : "com.apple.Foundation",
"size" : 10719232,
"uuid" : "f1f5f857-8c3c-36d5-bc27-7702d6795468",
"path" : "\/System\/Library\/Frameworks\/Foundation.framework\/Versions\/C\/Foundation",
"name" : "Foundation",
"CFBundleVersion" : "1953.300"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 6477213696,
"CFBundleShortVersionString" : "6.9",
"CFBundleIdentifier" : "com.apple.CoreFoundation",
"size" : 5079040,
"uuid" : "fd16d6d9-10c0-323b-b43b-9781c4a4d268",
"path" : "\/System\/Library\/Frameworks\/CoreFoundation.framework\/Versions\/A\/CoreFoundation",
"name" : "CoreFoundation",
"CFBundleVersion" : "1953.300"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 6530461696,
"CFBundleShortVersionString" : "6.9",
"CFBundleIdentifier" : "com.apple.AppKit",
"size" : 15773696,
"uuid" : "dbbd4dea-6c68-3200-a81b-79b6a62f4669",
"path" : "\/System\/Library\/Frameworks\/AppKit.framework\/Versions\/C\/AppKit",
"name" : "AppKit",
"CFBundleVersion" : "2299.30.116"
}
],
"sharedCache" : {
"base" : 6472843264,
"size" : 3434283008,
"uuid" : "00a1fbb6-43e1-3c11-8483-faf0db659249"
},
"vmSummary" : "ReadOnly portion of Libraries: Total=1.1G resident=0K(0%) swapped_out_or_unallocated=1.1G(100%)\nWritable regions: Total=2.1G written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=2.1G(100%)\n\n VIRTUAL REGION \nREGION TYPE SIZE COUNT (non-coalesced) \n=========== ======= ======= \nAccelerate framework 256K 2 \nActivity Tracing 256K 1 \nCG backing stores 7104K 8 \nCG image 336K 11 \nColorSync 544K 27 \nCoreAnimation 96K 6 \nCoreGraphics 48K 3 \nCoreUI image data 1104K 9 \nFoundation 16K 1 \nKernel Alloc Once 32K 1 \nMALLOC 585.3M 124 \nMALLOC guard page 192K 10 \nMALLOC_MEDIUM (reserved) 1.1G 10 reserved VM address space (unallocated)\nMALLOC_NANO (reserved) 384.0M 1 reserved VM address space (unallocated)\nSTACK GUARD 54.5M 6 \nStack 12.2M 7 \nVM_ALLOCATE 336K 21 \n__AUTH 680K 181 \n__AUTH_CONST 12.4M 348 \n__CTF 756 1 \n__DATA 45.5M 1178 \n__DATA_CONST 23.8M 773 \n__DATA_DIRTY 709K 112 \n__FONT_DATA 2352 1 \n__LINKEDIT 803.5M 701 \n__OBJC_CONST 1375K 152 \n__OBJC_RO 65.4M 1 \n__OBJC_RW 1986K 1 \n__TEXT 315.6M 1063 \ndyld private memory 1792K 8 \nmapped file 1.0G 362 \nshared memory 912K 16 \n=========== ======= ======= \nTOTAL 4.4G 5146 \nTOTAL, minus reserved VM space 2.9G 5146 \n",
"legacyInfo" : {
"threadTriggered" : {
"queue" : "com.apple.main-thread"
}
},
"trialInfo" : {
"rollouts" : [
{
"rolloutId" : "5fb4245a1bbfe8005e33a1e1",
"factorPackIds" : {
},
"deploymentId" : 240000021
},
{
"rolloutId" : "610d52e1fc54bc3389840408",
In GNU Emacs 29.0.60 (build 1, aarch64-apple-darwin22.2.0, NS
appkit-2299.30 Version 13.1 (Build 22C65)) of 2022-12-20 built on
Aarons-Laptop.local
Windowing system distributor 'Apple', version 10.3.2299
System Description: macOS 13.1
Configured using:
'configure --disable-dependency-tracking --disable-silent-rules
--enable-locallisppath=/opt/homebrew/share/emacs/site-lisp
--infodir=/opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/info/emacs
--prefix=/opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60 --with-xml2
--with-gnutls --with-native-compilation --without-compress-install
--without-dbus --without-imagemagick --with-modules --with-rsvg
--with-ns --disable-ns-self-contained 'CFLAGS=-Os -w -pipe
-mmacosx-version-min=13
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk
-DFD_SETSIZE=10000 -DDARWIN_UNLIMITED_SELECT'
'CPPFLAGS=-I/opt/homebrew/opt/zlib/include
-I/opt/homebrew/opt/jpeg/include -I/opt/homebrew/opt/icu4c/include
-I/opt/homebrew/opt/openssl <at> 1.1/include
-I/opt/homebrew/opt/readline/include -isystem/opt/homebrew/include
-F/opt/homebrew/Frameworks
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk'
'LDFLAGS=-L/opt/homebrew/opt/zlib/lib -L/opt/homebrew/opt/jpeg/lib
-L/opt/homebrew/opt/icu4c/lib -L/opt/homebrew/opt/openssl <at> 1.1/lib
-L/opt/homebrew/opt/readline/lib -L/opt/homebrew/lib
-F/opt/homebrew/Frameworks -Wl,-headerpad_max_install_names
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk''
Configured features:
ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Text
Minor modes in effect:
eval-sexp-fu-flash-mode: t
global-git-commit-mode: t
global-evil-mc-mode: t
evil-mc-mode: t
org-roam-db-autosync-mode: t
corfu-history-mode: t
gcmh-mode: t
transient-posframe-mode: t
save-place-mode: t
tabspaces-mode: t
winner-mode: t
savehist-mode: t
yas-global-mode: t
yas-minor-mode: t
mini-frame-mode: t
global-flycheck-mode: t
flycheck-mode: t
global-auto-revert-mode: t
global-anzu-mode: t
anzu-mode: t
which-key-posframe-mode: t
which-key-mode: t
recentf-mode: t
better-jumper-mode: t
better-jumper-local-mode: t
repeat-mode: t
server-mode: t
vertico-mouse-mode: t
vertico-mode: t
+popup-mode: t
shell-dirtrack-mode: t
evil-mode: t
evil-local-mode: t
windmove-mode: t
ns-auto-titlebar-mode: t
nano-modeline-mode: t
override-global-mode: t
leader-key-leader-override-mode: t
global-leader-key-leader-override-mode: t
delete-selection-mode: t
pixel-scroll-precision-mode: t
xterm-mouse-mode: t
straight-use-package-mode: t
straight-package-neutering-mode: t
global-display-line-numbers-mode: t
display-line-numbers-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tab-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
window-divider-mode: t
line-number-mode: t
auto-fill-function: yas--auto-fill
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
/Users/aaronjensen/.emacs.d/straight/build/ivy/elpa hides /Users/aaronjensen/.emacs.d/straight/build/lispy/elpa
/Users/aaronjensen/.emacs.d/straight/build/transient/transient hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/transient
/Users/aaronjensen/.emacs.d/straight/build/org/ob-comint hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-comint
/Users/aaronjensen/.emacs.d/straight/build/org/ob-exp hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-exp
/Users/aaronjensen/.emacs.d/straight/build/org/org-ctags hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-ctags
/Users/aaronjensen/.emacs.d/straight/build/org/ob-emacs-lisp hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-emacs-lisp
/Users/aaronjensen/.emacs.d/straight/build/org/oc hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/oc
/Users/aaronjensen/.emacs.d/straight/build/org/ox-texinfo hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ox-texinfo
/Users/aaronjensen/.emacs.d/straight/build/org/ol-irc hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ol-irc
/Users/aaronjensen/.emacs.d/straight/build/org/ol-doi hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ol-doi
/Users/aaronjensen/.emacs.d/straight/build/org/ob hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob
/Users/aaronjensen/.emacs.d/straight/build/org/org-refile hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-refile
/Users/aaronjensen/.emacs.d/straight/build/org/org-version hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-version
/Users/aaronjensen/.emacs.d/straight/build/org/org-num hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-num
/Users/aaronjensen/.emacs.d/straight/build/org/ol-mhe hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ol-mhe
/Users/aaronjensen/.emacs.d/straight/build/org/ob-shell hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-shell
/Users/aaronjensen/.emacs.d/straight/build/org/org-attach hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-attach
/Users/aaronjensen/.emacs.d/straight/build/org/ob-C hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-C
/Users/aaronjensen/.emacs.d/straight/build/org/org-macs hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-macs
/Users/aaronjensen/.emacs.d/straight/build/org/org-entities hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-entities
/Users/aaronjensen/.emacs.d/straight/build/org/ob-dot hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-dot
/Users/aaronjensen/.emacs.d/straight/build/org/ob-sql hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-sql
/Users/aaronjensen/.emacs.d/straight/build/org/ol-eww hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ol-eww
/Users/aaronjensen/.emacs.d/straight/build/org/org-datetree hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-datetree
/Users/aaronjensen/.emacs.d/straight/build/org/org-macro hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-macro
/Users/aaronjensen/.emacs.d/straight/build/org/ob-eval hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-eval
/Users/aaronjensen/.emacs.d/straight/build/org/ob-haskell hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-haskell
/Users/aaronjensen/.emacs.d/straight/build/org/ox-org hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ox-org
/Users/aaronjensen/.emacs.d/straight/build/org/ol-rmail hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ol-rmail
/Users/aaronjensen/.emacs.d/straight/build/org/ob-awk hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-awk
/Users/aaronjensen/.emacs.d/straight/build/org/ob-groovy hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-groovy
/Users/aaronjensen/.emacs.d/straight/build/org/ox-icalendar hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ox-icalendar
/Users/aaronjensen/.emacs.d/straight/build/org/ob-octave hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-octave
/Users/aaronjensen/.emacs.d/straight/build/org/ob-scheme hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-scheme
/Users/aaronjensen/.emacs.d/straight/build/org/org-mobile hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-mobile
/Users/aaronjensen/.emacs.d/straight/build/org/ob-processing hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-processing
/Users/aaronjensen/.emacs.d/straight/build/org/oc-biblatex hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/oc-biblatex
/Users/aaronjensen/.emacs.d/straight/build/org/oc-csl hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/oc-csl
/Users/aaronjensen/.emacs.d/straight/build/org/org-colview hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-colview
/Users/aaronjensen/.emacs.d/straight/build/org/ob-R hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-R
/Users/aaronjensen/.emacs.d/straight/build/org/org-table hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-table
/Users/aaronjensen/.emacs.d/straight/build/org/ox-html hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ox-html
/Users/aaronjensen/.emacs.d/straight/build/org/ob-fortran hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-fortran
/Users/aaronjensen/.emacs.d/straight/build/org/ol hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ol
/Users/aaronjensen/.emacs.d/straight/build/org/ob-plantuml hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-plantuml
/Users/aaronjensen/.emacs.d/straight/build/org/ol-docview hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ol-docview
/Users/aaronjensen/.emacs.d/straight/build/org/ob-perl hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-perl
/Users/aaronjensen/.emacs.d/straight/build/org/ob-sqlite hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-sqlite
/Users/aaronjensen/.emacs.d/straight/build/org/oc-basic hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/oc-basic
/Users/aaronjensen/.emacs.d/straight/build/org/ob-sed hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-sed
/Users/aaronjensen/.emacs.d/straight/build/org/org-fold-core hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-fold-core
/Users/aaronjensen/.emacs.d/straight/build/org/ob-ditaa hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-ditaa
/Users/aaronjensen/.emacs.d/straight/build/org/ob-ruby hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-ruby
/Users/aaronjensen/.emacs.d/straight/build/org/oc-bibtex hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/oc-bibtex
/Users/aaronjensen/.emacs.d/straight/build/org/org-habit hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-habit
/Users/aaronjensen/.emacs.d/straight/build/org/org-loaddefs hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-loaddefs
/Users/aaronjensen/.emacs.d/straight/build/org/ol-gnus hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ol-gnus
/Users/aaronjensen/.emacs.d/straight/build/org/ob-screen hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-screen
/Users/aaronjensen/.emacs.d/straight/build/org/org-mouse hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-mouse
/Users/aaronjensen/.emacs.d/straight/build/org/ob-css hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-css
/Users/aaronjensen/.emacs.d/straight/build/org/org-inlinetask hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-inlinetask
/Users/aaronjensen/.emacs.d/straight/build/org/ob-lisp hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-lisp
/Users/aaronjensen/.emacs.d/straight/build/org/ol-eshell hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ol-eshell
/Users/aaronjensen/.emacs.d/straight/build/org/org-pcomplete hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-pcomplete
/Users/aaronjensen/.emacs.d/straight/build/org/org-lint hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-lint
/Users/aaronjensen/.emacs.d/straight/build/org/org-id hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-id
/Users/aaronjensen/.emacs.d/straight/build/org/org-capture hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-capture
/Users/aaronjensen/.emacs.d/straight/build/org/ob-sass hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-sass
/Users/aaronjensen/.emacs.d/straight/build/org/ob-tangle hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-tangle
/Users/aaronjensen/.emacs.d/straight/build/org/ob-calc hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-calc
/Users/aaronjensen/.emacs.d/straight/build/org/ob-java hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-java
/Users/aaronjensen/.emacs.d/straight/build/org/org-compat hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-compat
/Users/aaronjensen/.emacs.d/straight/build/org/org-attach-git hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-attach-git
/Users/aaronjensen/.emacs.d/straight/build/org/ox-beamer hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ox-beamer
/Users/aaronjensen/.emacs.d/straight/build/org/org-protocol hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-protocol
/Users/aaronjensen/.emacs.d/straight/build/org/org-element hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-element
/Users/aaronjensen/.emacs.d/straight/build/org/ob-lob hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-lob
/Users/aaronjensen/.emacs.d/straight/build/org/org-tempo hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-tempo
/Users/aaronjensen/.emacs.d/straight/build/org/ob-python hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-python
/Users/aaronjensen/.emacs.d/straight/build/org/ob-latex hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-latex
/Users/aaronjensen/.emacs.d/straight/build/org/ol-w3m hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ol-w3m
/Users/aaronjensen/.emacs.d/straight/build/org/org-agenda hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-agenda
/Users/aaronjensen/.emacs.d/straight/build/org/org-persist hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-persist
/Users/aaronjensen/.emacs.d/straight/build/org/ob-ocaml hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-ocaml
/Users/aaronjensen/.emacs.d/straight/build/org/ob-ref hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-ref
/Users/aaronjensen/.emacs.d/straight/build/org/org-fold hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-fold
/Users/aaronjensen/.emacs.d/straight/build/org/ob-julia hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-julia
/Users/aaronjensen/.emacs.d/straight/build/org/ob-lilypond hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-lilypond
/Users/aaronjensen/.emacs.d/straight/build/org/ob-table hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-table
/Users/aaronjensen/.emacs.d/straight/build/org/ob-clojure hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-clojure
/Users/aaronjensen/.emacs.d/straight/build/org/org-indent hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-indent
/Users/aaronjensen/.emacs.d/straight/build/org/org-plot hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-plot
/Users/aaronjensen/.emacs.d/straight/build/org/ox-latex hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ox-latex
/Users/aaronjensen/.emacs.d/straight/build/org/org-src hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-src
/Users/aaronjensen/.emacs.d/straight/build/org/org-duration hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-duration
/Users/aaronjensen/.emacs.d/straight/build/org/ob-makefile hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-makefile
/Users/aaronjensen/.emacs.d/straight/build/org/ol-info hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ol-info
/Users/aaronjensen/.emacs.d/straight/build/org/org-clock hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-clock
/Users/aaronjensen/.emacs.d/straight/build/org/ob-forth hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-forth
/Users/aaronjensen/.emacs.d/straight/build/org/ox-odt hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ox-odt
/Users/aaronjensen/.emacs.d/straight/build/org/ol-man hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ol-man
/Users/aaronjensen/.emacs.d/straight/build/org/ox-publish hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ox-publish
/Users/aaronjensen/.emacs.d/straight/build/org/org-archive hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-archive
/Users/aaronjensen/.emacs.d/straight/build/org/ob-org hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-org
/Users/aaronjensen/.emacs.d/straight/build/org/ob-lua hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-lua
/Users/aaronjensen/.emacs.d/straight/build/org/org-keys hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-keys
/Users/aaronjensen/.emacs.d/straight/build/org/ob-eshell hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-eshell
/Users/aaronjensen/.emacs.d/straight/build/org/org-faces hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-faces
/Users/aaronjensen/.emacs.d/straight/build/org/ox-man hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ox-man
/Users/aaronjensen/.emacs.d/straight/build/org/org-list hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-list
/Users/aaronjensen/.emacs.d/straight/build/org/ox-md hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ox-md
/Users/aaronjensen/.emacs.d/straight/build/org/org-goto hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-goto
/Users/aaronjensen/.emacs.d/straight/build/org/ol-bbdb hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ol-bbdb
/Users/aaronjensen/.emacs.d/straight/build/org/org hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org
/Users/aaronjensen/.emacs.d/straight/build/org/ol-bibtex hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ol-bibtex
/Users/aaronjensen/.emacs.d/straight/build/org/ox-koma-letter hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ox-koma-letter
/Users/aaronjensen/.emacs.d/straight/build/org/ox-ascii hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ox-ascii
/Users/aaronjensen/.emacs.d/straight/build/org/ob-matlab hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-matlab
/Users/aaronjensen/.emacs.d/straight/build/org/ox hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ox
/Users/aaronjensen/.emacs.d/straight/build/org/org-timer hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-timer
/Users/aaronjensen/.emacs.d/straight/build/org/oc-natbib hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/oc-natbib
/Users/aaronjensen/.emacs.d/straight/build/org/ob-core hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-core
/Users/aaronjensen/.emacs.d/straight/build/org/org-feed hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-feed
/Users/aaronjensen/.emacs.d/straight/build/org/ob-gnuplot hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-gnuplot
/Users/aaronjensen/.emacs.d/straight/build/org/ob-js hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-js
/Users/aaronjensen/.emacs.d/straight/build/org/org-footnote hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-footnote
/Users/aaronjensen/.emacs.d/straight/build/org/ob-maxima hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/ob-maxima
/Users/aaronjensen/.emacs.d/straight/build/org/org-cycle hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-cycle
/Users/aaronjensen/.emacs.d/straight/build/org/org-crypt hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/org/org-crypt
/Users/aaronjensen/.emacs.d/straight/build/let-alist/let-alist hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/emacs-lisp/let-alist
/Users/aaronjensen/.emacs.d/straight/build/eldoc/eldoc hides /opt/homebrew/Cellar/emacs-plus <at> 29/29.0.60/share/emacs/29.0.60/lisp/emacs-lisp/eldoc
Features:
(shadow sort mail-extr emacsbug evil-nerd-commenter
evil-nerd-commenter-operator evil-nerd-commenter-sdk sgml-mode facemenu
multi-vterm evil-collection-vterm vterm tramp-cmds tramp tramp-loaddefs
trampver tramp-integration cus-start tramp-compat ls-lisp term ehelp
vterm-module term/xterm xterm sh-script treesit diary-lib diary-loaddefs
org-appear orgonomic org-indent org-superstar form-feed eval-sexp-fu
eros lispyville lispy lispy-inline avy etags fileloop lispy-tags
mode-local zoutline elisp-def ert ewoc evil-collection-xref xref sotlisp
skeleton consult-vertico consult compat-28 magit-bookmark bookmark
executable magit-delta xterm-color evil-collection-magit magit-submodule
magit-obsolete magit-blame magit-stash magit-reflog magit-bisect
magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-files magit-refs magit-status magit
package url-handlers magit-repos magit-apply magit-wip magit-log
which-func magit-diff smerge-mode diff git-commit log-edit
evil-collection-helpful helpful cc-langs cc-vars cc-defs trace
evil-collection-edebug edebug evil-collection-debug debug backtrace
info-look elisp-refs evil-terminal-cursor-changer evil-mc
evil-mc-command-execute evil-mc-command-record evil-mc-cursor-make
evil-mc-region evil-mc-cursor-state evil-mc-undo evil-mc-vars
evil-mc-known-commands evil-mc-common dabbrev company-rg company tabify
imenu ox-odt rng-loc rng-uri rng-parse rng-match rng-dt rng-util
rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-latex
ox-icalendar org-agenda ox-ascii ox-gfm ox-md ox-html table ox-publish
ox org-download url-http url-auth url-gw nsm async vulpea vulpea-meta
vulpea-select vulpea-buffer vulpea-db vulpea-utils vulpea-note oc-basic
ol-eww eww url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus
nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig
gnus-sum shr pixel-fill kinsoku url-file svg dom browse-url gnus-group
gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail
mail-source utf7 nnoo parse-time gnus-spec gnus-int gnus-range message
gnus-win gnus nnheader range ol-docview doc-view jka-compr image-mode
exif ol-bibtex bibtex iso8601 ol-bbdb ol-w3m ol-doi org-link-doi
org-roam-migrate org-roam-log org-roam-mode org-roam-capture org-roam-id
org-roam-node org-roam-db org-roam-utils org-roam-compat org-roam
org-mac-link org-goto org-capture org-attach org-tempo tempo
evil-org-agenda evil-org org-element org-persist xdg org-id org-refile
avl-tree generator ob-shell org ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-macro org-src ob-comint org-pcomplete org-list org-footnote
org-faces org-entities noutline outline ob-emacs-lisp ob-core ob-eval
org-cycle org-table ol emacsql-sqlite emacsql emacsql-compiler
tree-sitter-langs tree-sitter-langs-build tar-mode
evil-collection-arc-mode arc-mode archive-mode url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util url-parse auth-source url-vars tree-sitter-hl
tree-sitter tree-sitter-load tree-sitter-cli tsc tsc-dyn tsc-dyn-get
dired-aux tsc-obsolete cape corfu-history corfu evil-ruby-text-objects
ruby-refactor envrc inheritenv evil-surround evil-matchit-evil-setup
evil-vimish-fold vimish-fold f f-shortdoc shortdoc s dtrt-indent
elec-pair help-fns radix-tree bundler inf-ruby ruby-mode smie compile
enh-ruby-mode color undo-fu-session ws-butler vc-git diff-mode
vertico-directory gcmh sendmail mailcap yank-media puny rfc822 mml
mml-sec password-cache gnus-util time-date text-property-search
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
pcvs-util add-log magit-core magit-autorevert magit-margin
magit-transient magit-process with-editor magit-mode transient-posframe
transient magit-git magit-base magit-section crm eieio eieio-core
compat-27 compat-26 org-fold org-fold-core org-keys oc org-loaddefs
org-version saveplace tabspaces dired-x dired dired-loaddefs vc
vc-dispatcher winner cursor-sensor org-compat org-macs format-spec epa
epg rfc6068 epg-config cal-iso cal-menu calendar cal-loaddefs savehist
yasnippet mini-frame flycheck json map dash find-func autorevert
filenotify evil-anzu anzu popup-mode-hacks which-key-posframe posframe
evil-collection-which-key which-key hide-mode-line popup-mode-core
recentf tree-widget better-jumper repeat vc-svn project server
gcmh-autoloads copy-as-format-autoloads pcase pdf-tools-autoloads
tablist-autoloads restclient-autoloads multi-vterm-autoloads
vterm-autoloads dumb-jump-autoloads popup-autoloads haml-mode-autoloads
emmet-mode-autoloads terraform-mode-autoloads hcl-mode-autoloads
dockerfile-mode-autoloads yaml-mode-autoloads json-snatcher-autoloads
lua-mode-autoloads bundler-autoloads inf-ruby-autoloads
ruby-refactor-autoloads evil-ruby-text-objects-autoloads
enh-ruby-mode-autoloads sotlisp-autoloads elisp-def-autoloads
lispyville-autoloads lispy-autoloads zoutline-autoloads swiper-autoloads
ivy-autoloads iedit-autoloads eros-autoloads eval-sexp-fu-autoloads
eslintd-fix-autoloads web-mode-autoloads typescript-mode-autoloads
company-rg-autoloads company-autoloads git-link-autoloads
consult-git-commit-autoloads git-timemachine-autoloads
magit-delta-autoloads xterm-color-autoloads prettier-autoloads
editorconfig-autoloads nvm-autoloads iter2-autoloads flycheck-autoloads
let-alist-autoloads pkg-info-autoloads epl-autoloads
tree-sitter-langs-autoloads tree-sitter-autoloads tsc-autoloads
lsp-ui-autoloads lsp-mode-autoloads eldoc-autoloads
markdown-mode-autoloads spinner-autoloads imenu-list-autoloads
org-superstar-autoloads ox-gfm-autoloads org-pandoc-import-autoloads
gnuplot-autoloads org-download-autoloads async-autoloads
org-journal-autoloads deft-autoloads vulpea-autoloads org-roam-autoloads
emacsql-sqlite-autoloads emacsql-autoloads orgonomic-autoloads
org-drill-autoloads persist-autoloads org-appear-autoloads
org-mac-link-autoloads evil-org-autoloads
evil-terminal-cursor-changer-autoloads transient-posframe-autoloads
better-jumper-autoloads hydra lv buffer-move-autoloads rotate-autoloads
mini-frame-autoloads embark-consult-autoloads embark-autoloads
consult-autoloads orderless orderless-autoloads cape-autoloads
corfu-autoloads vertico-mouse vertico vertico-autoloads
tabspaces-autoloads which-key-posframe-autoloads which-key-autoloads
popup-mode popup-mode-settings popup-mode-autoloads
hide-mode-line-autoloads evil-anzu-autoloads anzu-autoloads
titlecase-autoloads wgrep-autoloads yasnippet-autoloads
form-feed-autoloads drag-stuff-autoloads dtrt-indent-autoloads
ws-butler-autoloads evil-vimish-fold-autoloads vimish-fold-autoloads
evil-collection annalist evil-collection-autoloads annalist-autoloads
evil-mc-autoloads evil-numbers-autoloads speeddating-autoloads
evil-matchit-autoloads evil-nerd-commenter-autoloads
evil-visualstar-autoloads evil-surround-autoloads cus-edit cus-load
wid-edit evil evil-integration evil-maps evil-commands reveal flyspell
ispell evil-jumps evil-command-window evil-search evil-ex shell
pcomplete comint ansi-osc ansi-color evil-types evil-macros evil-repeat
evil-states evil-core byte-opt advice evil-common windmove calc
calc-loaddefs calc-macs thingatpt rect evil-digraphs evil-vars pp
vundo-autoloads undo-fu-session-autoloads ztree-autoloads
dwim-shell-command-autoloads doom-themes-autoloads
treemacs-tab-bar-autoloads treemacs-magit-autoloads magit-autoloads
magit-section-autoloads git-commit-autoloads with-editor-autoloads
transient-autoloads treemacs-all-the-icons-autoloads
all-the-icons-autoloads treemacs-evil-autoloads evil-autoloads
goto-chg-autoloads treemacs-autoloads cfrs-autoloads ht-autoloads
pfuture-autoloads ace-window-autoloads avy-autoloads
rainbow-mode-autoloads posframe-autoloads ns-auto-titlebar
ns-auto-titlebar-autoloads nano-modeline memoize nano-modeline-autoloads
memoize-autoloads nano-light-theme face-remap nano-theme disp-table
nano-theme-autoloads envrc-autoloads inheritenv-autoloads compdef
derived compdef-autoloads helpful-autoloads elisp-refs-autoloads
f-autoloads s-autoloads edmacro kmacro dired-subtree-autoloads
dired-hacks-utils-autoloads dash-autoloads use-package-bind-key bind-key
easy-mmode hydra-autoloads lv-autoloads finder-inf leader-key bind-map
leader-key-autoloads bind-map-autoloads delsel pixel-scroll cua-base
ring xt-mouse no-littering compat compat-macs no-littering-autoloads
compat-autoloads use-package-core info files-x straight-autoloads
straight comp comp-cstr warnings subr-x rx cl-seq cl-macs gv bytecomp
byte-compile cl-extra help-mode icons cl-loaddefs cl-lib
display-line-numbers rmc iso-transl tooltip cconv 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 nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process native-compile emacs)
Memory information:
((conses 16 845438 822622)
(symbols 48 57647 1197)
(strings 32 207647 111777)
(string-bytes 1 8074129)
(vectors 16 111921)
(vector-slots 8 2484182 1346264)
(floats 8 798 3393)
(intervals 56 13725 596)
(buffers 984 15))
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Tue, 20 Dec 2022 15:26:01 GMT) Full text and rfc822 format available.Message #8 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: 60220 <at> debbugs.gnu.org Subject: Re: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Tue, 20 Dec 2022 10:25:39 -0500
Here is another trace I just got during a restart. It's slightly
different. This one seems to point to rng-loc at least as part of the
trace.
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Process: Emacs [18694]
Path: /opt/homebrew/*/Emacs.app/Contents/MacOS/Emacs
Identifier: org.gnu.Emacs
Version: Version 29.0.60 (9.0)
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
User ID: 501
Date/Time: 2022-12-20 10:22:50.8160 -0500
OS Version: macOS 13.1 (22C65)
Report Version: 12
Anonymous UUID: CD1F31D7-5E61-2935-643D-55F58CD29C12
Sleep/Wake UUID: 254FA28B-6F01-412E-8D38-DE2EC5BE8B25
Time Awake Since Boot: 17000 seconds
Time Since Wake: 1554 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 0x612f737265735627 ->
0x0000737265735627 (possible pointer authentication failure)
Exception Codes: 0x0000000000000001, 0x612f737265735627
VM Region Info: 0x737265735627 is not in any region. Bytes after
previous region: 21381512386088
REGION TYPE START - END [ VSIZE]
PRT/MAX SHRMOD REGION DETAIL
MALLOC_NANO (reserved) 600018000000-600020000000 [128.0M]
rw-/rwx SM=NUL ...(unallocated)
--->
UNUSED SPACE AT END
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x1820921b0 __pthread_kill + 8
1 libsystem_pthread.dylib 0x1820c8cec pthread_kill + 288
2 libsystem_c.dylib 0x181fcaa50 raise + 32
3 Emacs 0x1045f5af4
terminate_due_to_signal + 204
4 Emacs 0x1045f62f0 emacs_abort + 20
5 Emacs 0x1045c4db8 ns_term_shutdown + 132
6 Emacs 0x1044b0b9c shut_down_emacs + 332
7 Emacs 0x1045f5abc
terminate_due_to_signal + 148
8 Emacs 0x1044d308c handle_fatal_signal + 16
9 Emacs 0x1044d3108
deliver_thread_signal + 124
10 Emacs 0x1044d1708
deliver_fatal_thread_signal + 12
11 Emacs 0x1044d3168 handle_sigsegv + 96
12 libsystem_platform.dylib 0x1820f72a4 _sigtramp + 56
13 ??? 0xffff800181dce730 ???
14 dyld 0x181dc9a7c
lsl::PersistentAllocator::reserveRange(lsl::BTree<lsl::Allocator::Buffer,
lsl::PersistentAllocator::RegionSizeCompare, false>::const_iterator&,
lsl::Allocator::Buffer) + 392
15 dyld 0x181dca0b0
lsl::PersistentAllocator::allocate_buffer(unsigned long, unsigned
long, unsigned long, lsl::Allocator**) + 624
16 dyld 0x181dc91e0
lsl::Allocator::aligned_alloc(unsigned long, unsigned long) + 180
17 dyld 0x181dc9230
lsl::Allocator::strdup(char const*) + 48
18 dyld 0x181dc68b8
dyld4::FileManager::fileRecordForPath(char const*) + 40
19 dyld 0x181de4624
dyld4::Atlas::ProcessSnapshot::Serializer::readMappedFileInfo(std::__1::span<std::byte,
18446744073709551615ul>&, unsigned long long&, lsl::UUID&,
dyld4::FileRecord&) + 132
20 dyld 0x181de3170
dyld4::Atlas::ProcessSnapshot::Serializer::deserialize(std::__1::span<std::byte,
18446744073709551615ul>) + 928
21 dyld 0x181de2cec
dyld4::Atlas::ProcessSnapshot::ProcessSnapshot(lsl::Allocator&,
dyld4::FileManager&, bool, std::__1::span<std::byte,
18446744073709551615ul>) + 304
22 dyld 0x181daef64
lsl::UniquePtr<dyld4::Atlas::ProcessSnapshot>
lsl::Allocator::makeUnique<dyld4::Atlas::ProcessSnapshot,
lsl::EphemeralAllocator&, dyld4::FileManager&, bool,
std::__1::span<std::byte, 18446744073709551615ul>
const&>(lsl::EphemeralAllocator&, dyld4::FileManager&, bool&&,
std::__1::span<std::byte, 18446744073709551615ul> const&) + 80
23 dyld 0x181dabafc
dyld4::RuntimeState::getCurrentProcessSnapshot() + 96
24 dyld 0x181dab8cc
dyld4::RuntimeState::notifyDebuggerLoad(std::__1::span<dyld4::Loader
const*, 18446744073709551615ul> const&) + 72
25 dyld 0x181ddaf3c
dyld4::APIs::dlopen_from(char const*, int, void*)::$_0::operator()()
const + 748
26 dyld 0x181dd4968
dyld4::APIs::dlopen_from(char const*, int, void*) + 892
27 Emacs 0x104578db8 Fnative_elisp_load + 356
28 Emacs 0x104554894 Fload + 2104
29 Emacs 0x1045565f8 save_match_data_load + 92
30 Emacs 0x104530930
load_with_autoload_queue + 120
31 Emacs 0x10453cd8c Frequire + 560
32 Emacs 0x10456f948 exec_byte_code + 2988
33 Emacs 0x10456ed6c Fbyte_code + 140
34 Emacs 0x10452ca38 eval_sub + 2236
35 Emacs 0x104530a54 Feval + 88
36 rng-loc-798ea863-2dd98436.eln 0x13e19abdc top_level_run + 172
37 Emacs 0x1045785cc load_comp_unit + 844
38 Emacs 0x104578e10 Fnative_elisp_load + 444
39 Emacs 0x104554894 Fload + 2104
40 Emacs 0x1045565f8 save_match_data_load + 92
41 Emacs 0x104530930
load_with_autoload_queue + 120
42 Emacs 0x10453cd8c Frequire + 560
43 Emacs 0x10456f948 exec_byte_code + 2988
44 Emacs 0x10456ed6c Fbyte_code + 140
45 Emacs 0x10452ca38 eval_sub + 2236
46 Emacs 0x104530a54 Feval + 88
47 ox-odt-c6038b82-f0fa0d16.eln 0x14e65dab4 top_level_run + 2628
48 Emacs 0x1045785cc load_comp_unit + 844
49 Emacs 0x104578e10 Fnative_elisp_load + 444
50 Emacs 0x104554894 Fload + 2104
51 Emacs 0x1045565f8 save_match_data_load + 92
52 Emacs 0x104530930
load_with_autoload_queue + 120
53 Emacs 0x10453cd8c Frequire + 560
54 Emacs 0x10456f948 exec_byte_code + 2988
55 Emacs 0x10452e72c Ffuncall + 316
56 Emacs 0x1045312dc funcall_nil + 12
57 Emacs 0x1045311f8 run_hook_with_args + 320
58 subr-13adf6a6-818c6388.eln 0x108906c50
F646f2d61667465722d6c6f61642d6576616c756174696f6e_do_after_load_evaluation_0
+ 576
59 Emacs 0x10452e72c Ffuncall + 316
60 Emacs 0x10455493c Fload + 2272
61 Emacs 0x1045565f8 save_match_data_load + 92
62 Emacs 0x104530930
load_with_autoload_queue + 120
63 Emacs 0x10453cd8c Frequire + 560
64 Emacs 0x10452ca38 eval_sub + 2236
65 Emacs 0x10452c734 eval_sub + 1464
66 Emacs 0x10452cb58 Fif + 24
67 Emacs 0x10452c8a4 eval_sub + 1832
68 Emacs 0x10452cbb4 Fprogn + 48
69 Emacs 0x104532114 funcall_lambda + 1316
70 Emacs 0x10456f7c8 exec_byte_code + 2604
71 Emacs 0x10452e72c Ffuncall + 316
72 Emacs 0x1045312dc funcall_nil + 12
73 Emacs 0x1045311f8 run_hook_with_args + 320
74 subr-13adf6a6-818c6388.eln 0x108906c50
F646f2d61667465722d6c6f61642d6576616c756174696f6e_do_after_load_evaluation_0
+ 576
75 Emacs 0x10452e72c Ffuncall + 316
76 Emacs 0x10455493c Fload + 2272
77 Emacs 0x1045565f8 save_match_data_load + 92
78 Emacs 0x104530930
load_with_autoload_queue + 120
79 Emacs 0x10453cd8c Frequire + 560
80 Emacs 0x10452ca38 eval_sub + 2236
81 Emacs 0x10452f160
internal_lisp_condition_case + 884
82 Emacs 0x10452c8a4 eval_sub + 1832
83 Emacs 0x10452cbb4 Fprogn + 48
84 Emacs 0x10452e3b0 Fwhile + 80
85 Emacs 0x10452c8a4 eval_sub + 1832
86 Emacs 0x10452cbb4 Fprogn + 48
87 Emacs 0x104532114 funcall_lambda + 1316
88 Emacs 0x10452e72c Ffuncall + 316
89 Emacs 0x10452e72c Ffuncall + 316
90 timer-3ee7cfd9-d55357b5.eln 0x10b3dce44
F74696d65722d6576656e742d68616e646c6572_timer_event_handler_0 + 832
91 Emacs 0x10452e72c Ffuncall + 316
92 Emacs 0x1044bd290 timer_check + 892
93 Emacs 0x1044bb63c readable_events + 36
94 Emacs 0x1044bcebc get_input_pending + 56
95 Emacs 0x1044b7b50 read_char + 2872
96 Emacs 0x1044b5550 read_key_sequence + 1056
97 Emacs 0x1044b3dc0 command_loop_1 + 700
98 Emacs 0x10452f334
internal_condition_case + 96
99 Emacs 0x1044b3af0 command_loop_2 + 52
100 Emacs 0x10452ed58 internal_catch + 88
101 Emacs 0x1045f5f18 command_loop.cold.1 + 80
102 Emacs 0x1044b3490 command_loop + 152
103 Emacs 0x1044b334c recursive_edit_1 + 148
104 Emacs 0x1044b35b0 Frecursive_edit + 264
105 Emacs 0x1044b292c main + 7484
106 dyld 0x181d9fe50 start + 2544
Thread 1:
0 libsystem_pthread.dylib 0x1820c3e18 start_wqthread + 0
Thread 2:
0 libsystem_pthread.dylib 0x1820c3e18 start_wqthread + 0
Thread 3:: gmain
0 libsystem_kernel.dylib 0x182094a00 __select + 8
1 libglib-2.0.0.dylib 0x105457b20 g_poll + 424
2 libglib-2.0.0.dylib 0x10544acc4
g_main_context_iterate + 340
3 libglib-2.0.0.dylib 0x10544ad8c
g_main_context_iteration + 60
4 libglib-2.0.0.dylib 0x10544c124 glib_worker_main + 48
5 libglib-2.0.0.dylib 0x10546f3a8 g_thread_proxy + 68
6 libsystem_pthread.dylib 0x1820c906c _pthread_start + 148
7 libsystem_pthread.dylib 0x1820c3e2c thread_start + 8
Thread 4:
0 libsystem_pthread.dylib 0x1820c3e18 start_wqthread + 0
Thread 5:
0 libsystem_pthread.dylib 0x1820c3e18 start_wqthread + 0
Thread 6:
0 libsystem_kernel.dylib 0x18208ffa4 __pselect + 8
1 libsystem_kernel.dylib 0x18208fe7c pselect$DARWIN_EXTSN + 64
2 Emacs 0x1045c5e98 -[EmacsApp
fd_handler:] + 184
3 Foundation 0x1830a9470 __NSThread__start__ + 716
4 libsystem_pthread.dylib 0x1820c906c _pthread_start + 148
5 libsystem_pthread.dylib 0x1820c3e2c thread_start + 8
Thread 7:: com.apple.NSEventThread
0 libsystem_kernel.dylib 0x182089d70 mach_msg2_trap + 8
1 libsystem_kernel.dylib 0x18209b8a4 mach_msg2_internal + 80
2 libsystem_kernel.dylib 0x1820925c4 mach_msg_overwrite + 540
3 libsystem_kernel.dylib 0x18208a0ec mach_msg + 24
4 CoreFoundation 0x1821a8bc0
__CFRunLoopServiceMachPort + 160
5 CoreFoundation 0x1821a74ac __CFRunLoopRun + 1232
6 CoreFoundation 0x1821a6888 CFRunLoopRunSpecific + 612
7 AppKit 0x185552410 _NSEventThread + 172
8 libsystem_pthread.dylib 0x1820c906c _pthread_start + 148
9 libsystem_pthread.dylib 0x1820c3e2c thread_start + 8
Thread 0 crashed with ARM Thread State (64-bit):
x0: 0x0000000000000000 x1: 0x0000000000000000 x2:
0x0000000000000000 x3: 0x0000600003f886c0
x4: 0x0000600003f886a0 x5: 0x0000000000000000 x6:
0x0000000000000000 x7: 0x0000000000000710
x8: 0xb04c5173d21794d4 x9: 0xb04c51720f556e54 x10:
0x0000000000000001 x11: 0x0000000000000003
x12: 0x0000000000000001 x13: 0x0000600002a99480 x14:
0x01000001dd44fee9 x15: 0x00000001dd44fee8
x16: 0x0000000000000148 x17: 0x00000001e22707f0 x18:
0x0000000000000000 x19: 0x0000000000000006
x20: 0x00000001dd42fa80 x21: 0x0000000000000103 x22:
0x00000001dd42fb60 x23: 0x0000000000000003
x24: 0x000000016ba12308 x25: 0x0000000000000006 x26:
0x0000000000000020 x27: 0x0000000104d52d70
x28: 0x0000000104d52de0 fp: 0x0000000104bb1910 lr: 0x00000001820c8cec
sp: 0x0000000104bb18f0 pc: 0x00000001820921b0 cpsr: 0x40001000
far: 0x0000000104ba79f0 esr: 0x56000080 Address size fault
Binary Images:
0x182089000 - 0x1820c1ff3 libsystem_kernel.dylib (*)
<aebf397e-e2ef-3a49-be58-23d4558511f6>
/usr/lib/system/libsystem_kernel.dylib
0x1820c2000 - 0x1820ceffb libsystem_pthread.dylib (*)
<132084c6-c347-3489-9ac2-fcaad21cdb73>
/usr/lib/system/libsystem_pthread.dylib
0x181f89000 - 0x182009ff3 libsystem_c.dylib (*)
<756cd0d2-3241-3a74-8c59-02632dcee221>
/usr/lib/system/libsystem_c.dylib
0x1043e8000 - 0x10463ffff org.gnu.Emacs (Version
29.0.60) <96c2c81f-a22d-3b5c-b9bc-7b549603be41>
/opt/homebrew/*/Emacs.app/Contents/MacOS/Emacs
0x1820f3000 - 0x1820faffb libsystem_platform.dylib (*)
<b215ae90-4ed2-3fcd-8ccc-6c0d93cc4f41>
/usr/lib/system/libsystem_platform.dylib
0x0 - 0xffffffffffffffff ??? (*)
<00000000-0000-0000-0000-000000000000> ???
0x181d9a000 - 0x181e24b63 dyld (*)
<487cfdeb-9b07-39bf-bfb9-970b61aea2d1> /usr/lib/dyld
0x13e194000 - 0x13e19bfff rng-loc-798ea863-2dd98436.eln
(*) <99fc78aa-c562-3a97-b250-b4eafbfb9457>
/Users/USER/*/rng-loc-798ea863-2dd98436.eln
0x14e640000 - 0x14e663fff ox-odt-c6038b82-f0fa0d16.eln
(*) <b70c4abe-ae3f-3f4d-9de8-eeb718dc2f8d>
/Users/USER/*/ox-odt-c6038b82-f0fa0d16.eln
0x1088e8000 - 0x10891bfff subr-13adf6a6-818c6388.eln (*)
<7350297a-5236-3262-aa1f-9e88e72dfa8b>
/opt/homebrew/*/Emacs.app/Contents/native-lisp/29.0.60-c7b10636/preloaded/subr-13adf6a6-818c6388.eln
0x10b3d8000 - 0x10b3dffff timer-3ee7cfd9-d55357b5.eln
(*) <0f550bba-4a80-3546-98fe-a92aa0d14158>
/opt/homebrew/*/Emacs.app/Contents/native-lisp/29.0.60-c7b10636/preloaded/timer-3ee7cfd9-d55357b5.eln
0x105414000 - 0x1054fbfff libglib-2.0.0.dylib (*)
<f593e720-37ac-3b64-8d96-f9c330062fec>
/opt/homebrew/*/libglib-2.0.0.dylib
0x183053000 - 0x183a8bfff com.apple.Foundation (6.9)
<f1f5f857-8c3c-36d5-bc27-7702d6795468>
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x182127000 - 0x1825fefff com.apple.CoreFoundation (6.9)
<fd16d6d9-10c0-323b-b43b-9781c4a4d268>
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x1853ef000 - 0x1862f9fff com.apple.AppKit (6.9)
<dbbd4dea-6c68-3200-a81b-79b6a62f4669>
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 628
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: 216650
thread_create: 0
thread_set_state: 14824
VM Region Summary:
ReadOnly portion of Libraries: Total=1.1G resident=0K(0%)
swapped_out_or_unallocated=1.1G(100%)
Writable regions: Total=1.5G written=0K(0%) resident=0K(0%)
swapped_out=0K(0%) unallocated=1.5G(100%)
VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
Accelerate framework 128K 1
Activity Tracing 256K 1
CG backing stores 3072K 4
CG image 48K 2
ColorSync 528K 26
CoreAnimation 96K 6
CoreGraphics 32K 2
CoreUI image data 832K 5
Foundation 16K 1
Kernel Alloc Once 32K 1
MALLOC 371.3M 77
MALLOC guard page 192K 10
MALLOC_MEDIUM (reserved) 720.0M 6 reserved VM
address space (unallocated)
MALLOC_NANO (reserved) 384.0M 1 reserved VM
address space (unallocated)
STACK GUARD 112K 7
Stack 13.3M 8
Stack Guard 54.4M 1
VM_ALLOCATE 208K 13
__AUTH 646K 164
__AUTH_CONST 11.3M 321
__CTF 756 1
__DATA 31.0M 842
__DATA_CONST 21.1M 610
__DATA_DIRTY 709K 110
__FONT_DATA 2352 1
__LINKEDIT 797.7M 447
__OBJC_CONST 1334K 138
__OBJC_RO 65.4M 1
__OBJC_RW 1986K 1
__TEXT 285.5M 782
dyld private memory 1024K 4
mapped file 233.1M 42
shared memory 864K 15
=========== ======= =======
TOTAL 2.9G 3651
TOTAL, minus reserved VM space 1.9G 3651
Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Tue, 20 Dec 2022 15:32:01 GMT) Full text and rfc822 format available.Message #11 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Aaron Jensen <aaronjensen <at> gmail.com> Cc: 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Tue, 20 Dec 2022 17:32:02 +0200
> From: Aaron Jensen <aaronjensen <at> gmail.com> > Date: Tue, 20 Dec 2022 10:11:17 -0500 > > > I've been seeing this crash somewhat frequently recently on emacs-29 > master. It's possibly since updating to macOS Ventura (13.1). I can't > seem to reproduce it with debug symbols and a debugger attached, so this > may be the best I can provide right now. It tends to happen shortly > after I restart Emacs using `restart-emacs'. It also just happened > randomly while I didn't even have Emacs focused. I believe I have seen > it happen once when starting Emacs without a restart. I guess it means restarting Emacs on macOS is not safe.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Tue, 20 Dec 2022 15:37:01 GMT) Full text and rfc822 format available.Message #14 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Tue, 20 Dec 2022 10:36:09 -0500
On Tue, Dec 20, 2022 at 10:31 AM Eli Zaretskii <eliz <at> gnu.org> wrote: > > > From: Aaron Jensen <aaronjensen <at> gmail.com> > > Date: Tue, 20 Dec 2022 10:11:17 -0500 > > > > > > I've been seeing this crash somewhat frequently recently on emacs-29 > > master. It's possibly since updating to macOS Ventura (13.1). I can't > > seem to reproduce it with debug symbols and a debugger attached, so this > > may be the best I can provide right now. It tends to happen shortly > > after I restart Emacs using `restart-emacs'. It also just happened > > randomly while I didn't even have Emacs focused. I believe I have seen > > it happen once when starting Emacs without a restart. > > I guess it means restarting Emacs on macOS is not safe. Possibly. There's a lot going on in my config so I'm trying to pare it down. I'll see if I can narrow it or eliminate it. It could be some stale bytecode or binaries from my previous version of Emacs and/or macOS dependencies. I'll effectively start from scratch and see if that helps. Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Tue, 20 Dec 2022 15:41:01 GMT) Full text and rfc822 format available.Message #17 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Aaron Jensen <aaronjensen <at> gmail.com> Cc: 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Tue, 20 Dec 2022 17:41:00 +0200
> From: Aaron Jensen <aaronjensen <at> gmail.com> > Date: Tue, 20 Dec 2022 10:25:39 -0500 > > Here is another trace I just got during a restart. It's slightly > different. This one seems to point to rng-loc at least as part of the > trace. AFAIU, it says that Emacs was _loading_ rng-loc. That doesn't mean the problem is in rng-loc's code. The fatal signal comes from the maxOS implementation of dlopen, so I suspect that the way we restart Emacs messes up some OS data structures regarding loaded shared libraries or something. Note that the previous crash you posted also crashes inside dlopen. So I think it's safe to say that restarting Emacs makes loading of *.eln files (and maybe share libraries in general) fragile and tending to crash, for some reason. Maybe we should explicitly unload all the *.eln files when we restart?
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Tue, 20 Dec 2022 16:00:02 GMT) Full text and rfc822 format available.Message #20 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Tue, 20 Dec 2022 10:59:20 -0500
On Tue, Dec 20, 2022 at 10:40 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen <at> gmail.com>
> > Date: Tue, 20 Dec 2022 10:25:39 -0500
> >
> > Here is another trace I just got during a restart. It's slightly
> > different. This one seems to point to rng-loc at least as part of the
> > trace.
>
> AFAIU, it says that Emacs was _loading_ rng-loc. That doesn't mean
> the problem is in rng-loc's code. The fatal signal comes from the
> maxOS implementation of dlopen, so I suspect that the way we restart
> Emacs messes up some OS data structures regarding loaded shared
> libraries or something.
>
> Note that the previous crash you posted also crashes inside dlopen.
>
> So I think it's safe to say that restarting Emacs makes loading of
> *.eln files (and maybe share libraries in general) fragile and tending
> to crash, for some reason. Maybe we should explicitly unload all the
> *.eln files when we restart?
Interesting. If I restart while launched from lldb, I get the below.
It happens right away and it doesn't actually restart. This is not the
behavior I see if I launch it normally or in xcode. I should note that
occasionally when I restart Emacs it just quits and does not restart.
I have to restart it manually. Perhaps this is all connected to the
issue you're suggesting.
(lldb) process launch
Process 19414 launched: 'src/emacs' (arm64)
Process 19414 stopped
* thread #8, stop reason = exec
frame #0: 0x0000000100b2c950 dyld`_dyld_start
dyld`:
-> 0x100b2c950 <+0>: mov x0, sp
0x100b2c954 <+4>: and sp, x0, #0xfffffffffffffff0
0x100b2c958 <+8>: mov x29, #0x0
0x100b2c95c <+12>: mov x30, #0x0
Target 0: (emacs) stopped.
(lldb) thread list
Process 19414 stopped
* thread #8: tid = 0x3026c, 0x0000000100b2c950 dyld`_dyld_start, stop
reason = exec
(lldb) thread backtrace
* thread #8, stop reason = exec
* frame #0: 0x0000000100b2c950 dyld`_dyld_start
(lldb) continue
Process 19414 resuming
Process 19414 exited with status = 14 (0x0000000e) Terminated due to signal 14
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Tue, 20 Dec 2022 17:23:01 GMT) Full text and rfc822 format available.Message #23 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Aaron Jensen <aaronjensen <at> gmail.com> Cc: 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Tue, 20 Dec 2022 19:23:00 +0200
> From: Aaron Jensen <aaronjensen <at> gmail.com> > Date: Tue, 20 Dec 2022 10:59:20 -0500 > Cc: 60220 <at> debbugs.gnu.org > > On Tue, Dec 20, 2022 at 10:40 AM Eli Zaretskii <eliz <at> gnu.org> wrote: > > > > AFAIU, it says that Emacs was _loading_ rng-loc. That doesn't mean > > the problem is in rng-loc's code. The fatal signal comes from the > > maxOS implementation of dlopen, so I suspect that the way we restart > > Emacs messes up some OS data structures regarding loaded shared > > libraries or something. > > > > Note that the previous crash you posted also crashes inside dlopen. > > > > So I think it's safe to say that restarting Emacs makes loading of > > *.eln files (and maybe share libraries in general) fragile and tending > > to crash, for some reason. Maybe we should explicitly unload all the > > *.eln files when we restart? > > Interesting. If I restart while launched from lldb, I get the below. > It happens right away and it doesn't actually restart. This is not the > behavior I see if I launch it normally or in xcode. I should note that > occasionally when I restart Emacs it just quits and does not restart. > I have to restart it manually. Perhaps this is all connected to the > issue you're suggesting. > > (lldb) process launch > Process 19414 launched: 'src/emacs' (arm64) > Process 19414 stopped > * thread #8, stop reason = exec > frame #0: 0x0000000100b2c950 dyld`_dyld_start > dyld`: > -> 0x100b2c950 <+0>: mov x0, sp > 0x100b2c954 <+4>: and sp, x0, #0xfffffffffffffff0 > 0x100b2c958 <+8>: mov x29, #0x0 > 0x100b2c95c <+12>: mov x30, #0x0 > Target 0: (emacs) stopped. > (lldb) thread list > Process 19414 stopped > * thread #8: tid = 0x3026c, 0x0000000100b2c950 dyld`_dyld_start, stop > reason = exec > (lldb) thread backtrace > * thread #8, stop reason = exec > * frame #0: 0x0000000100b2c950 dyld`_dyld_start > (lldb) continue > Process 19414 resuming > Process 19414 exited with status = 14 (0x0000000e) Terminated due to signal 14 What is "signal 14" on macOS? Anyway, look at the code: we restart by calling execvp. You or someone who knowns macOS internals should take a look at what that means for shared libraries which were loaded by the program that calls execvp -- what happens with those libraries in the execvp'ed process. I'm guessing that they are not being unloaded and re-loaded by the new process, or something to that effect. Or maybe the way we load the *.eln files causes this, triggered by 'execvp'? Can you try running for a while Emacs built without native compilation and restarting it? That could tell us whether the *.eln files are the problem.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Wed, 21 Dec 2022 03:49:02 GMT) Full text and rfc822 format available.Message #26 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Tue, 20 Dec 2022 22:47:46 -0500
On Tue, Dec 20, 2022 at 12:22 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen <at> gmail.com>
> > Date: Tue, 20 Dec 2022 10:59:20 -0500
> > Cc: 60220 <at> debbugs.gnu.org
> >
> > On Tue, Dec 20, 2022 at 10:40 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > >
> > > AFAIU, it says that Emacs was _loading_ rng-loc. That doesn't mean
> > > the problem is in rng-loc's code. The fatal signal comes from the
> > > maxOS implementation of dlopen, so I suspect that the way we restart
> > > Emacs messes up some OS data structures regarding loaded shared
> > > libraries or something.
> > >
> > > Note that the previous crash you posted also crashes inside dlopen.
> > >
> > > So I think it's safe to say that restarting Emacs makes loading of
> > > *.eln files (and maybe share libraries in general) fragile and tending
> > > to crash, for some reason. Maybe we should explicitly unload all the
> > > *.eln files when we restart?
> >
> > Interesting. If I restart while launched from lldb, I get the below.
> > It happens right away and it doesn't actually restart. This is not the
> > behavior I see if I launch it normally or in xcode. I should note that
> > occasionally when I restart Emacs it just quits and does not restart.
> > I have to restart it manually. Perhaps this is all connected to the
> > issue you're suggesting.
> >
> > (lldb) process launch
> > Process 19414 launched: 'src/emacs' (arm64)
> > Process 19414 stopped
> > * thread #8, stop reason = exec
> > frame #0: 0x0000000100b2c950 dyld`_dyld_start
> > dyld`:
> > -> 0x100b2c950 <+0>: mov x0, sp
> > 0x100b2c954 <+4>: and sp, x0, #0xfffffffffffffff0
> > 0x100b2c958 <+8>: mov x29, #0x0
> > 0x100b2c95c <+12>: mov x30, #0x0
> > Target 0: (emacs) stopped.
> > (lldb) thread list
> > Process 19414 stopped
> > * thread #8: tid = 0x3026c, 0x0000000100b2c950 dyld`_dyld_start, stop
> > reason = exec
> > (lldb) thread backtrace
> > * thread #8, stop reason = exec
> > * frame #0: 0x0000000100b2c950 dyld`_dyld_start
> > (lldb) continue
> > Process 19414 resuming
> > Process 19414 exited with status = 14 (0x0000000e) Terminated due to signal 14
>
> What is "signal 14" on macOS?
This is all I could find:
14 SIGALRM terminate process real-time timer expired
I'm able to reproduce the above without native compilation as well.
This particular thing only happens when in a lldb and doesn't affect
me in practice.
> Anyway, look at the code: we restart by calling execvp. You or
> someone who knowns macOS internals should take a look at what that
> means for shared libraries which were loaded by the program that calls
> execvp -- what happens with those libraries in the execvp'ed process.
> I'm guessing that they are not being unloaded and re-loaded by the new
> process, or something to that effect.
>
> Or maybe the way we load the *.eln files causes this, triggered by
> 'execvp'?
This is out of my depth. I did a tiny bit of digging and didn't find
anything. I'll keep looking but if someone is more familiar w/ this
they'd have more luck than me I'm sure.
> Can you try running for a while Emacs built without native compilation
> and restarting it? That could tell us whether the *.eln files are the
> problem.
I wasn't able to reproduce it w/o native compilation. I'm going to try
running w/ native compilation for a while *without* doing any restarts
and see if I can get it to crash. I've seen crashes take an hour+
after a restart (though most happen w/in 30 seconds). I can't say
definitively that all crashes have happened in a restarted process.
Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Wed, 21 Dec 2022 12:23:01 GMT) Full text and rfc822 format available.Message #29 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Aaron Jensen <aaronjensen <at> gmail.com>, Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Wed, 21 Dec 2022 14:22:06 +0200
> From: Aaron Jensen <aaronjensen <at> gmail.com> > Date: Tue, 20 Dec 2022 22:47:46 -0500 > Cc: 60220 <at> debbugs.gnu.org > > > > Process 19414 exited with status = 14 (0x0000000e) Terminated due to signal 14 > > > > What is "signal 14" on macOS? > > This is all I could find: > > 14 SIGALRM terminate process real-time timer expired > > I'm able to reproduce the above without native compilation as well. > This particular thing only happens when in a lldb and doesn't affect > me in practice. The only place we use SIGALRM in Emacs is in interval timesr (see atimer.c), which are used for stuff like hour-glass cursor and input polling. Once again, this might mean we are not cleaning up the process state before calling execvp. But that is just a speculation. > > Anyway, look at the code: we restart by calling execvp. You or > > someone who knowns macOS internals should take a look at what that > > means for shared libraries which were loaded by the program that calls > > execvp -- what happens with those libraries in the execvp'ed process. > > I'm guessing that they are not being unloaded and re-loaded by the new > > process, or something to that effect. > > > > Or maybe the way we load the *.eln files causes this, triggered by > > 'execvp'? > > This is out of my depth. Mine as well. Gerd, any ideas or hints? > I did a tiny bit of digging and didn't find anything. Likewise. > > Can you try running for a while Emacs built without native compilation > > and restarting it? That could tell us whether the *.eln files are the > > problem. > > I wasn't able to reproduce it w/o native compilation. I'm going to try > running w/ native compilation for a while *without* doing any restarts > and see if I can get it to crash. I've seen crashes take an hour+ > after a restart (though most happen w/in 30 seconds). I can't say > definitively that all crashes have happened in a restarted process. OK, thanks.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Wed, 21 Dec 2022 13:30:02 GMT) Full text and rfc822 format available.Message #32 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 60220 <at> debbugs.gnu.org, Aaron Jensen <aaronjensen <at> gmail.com> Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Wed, 21 Dec 2022 14:29:27 +0100
If I remember that correctly, installed signal handlers don’t survive process replacement. The man pages for execve and sigaction should tell. If that’s the case the new process has a default handler for SIGALRM which terminates. But please check the man pages if that’s true. Sent from my iPhone > On 21. Dec 2022, at 13:22, Eli Zaretskii <eliz <at> gnu.org> wrote: > > >> >> From: Aaron Jensen <aaronjensen <at> gmail.com> >> Date: Tue, 20 Dec 2022 22:47:46 -0500 >> Cc: 60220 <at> debbugs.gnu.org >> >>>> Process 19414 exited with status = 14 (0x0000000e) Terminated due to signal 14 >>> >>> What is "signal 14" on macOS? >> >> This is all I could find: >> >> 14 SIGALRM terminate process real-time timer expired >> >> I'm able to reproduce the above without native compilation as well. >> This particular thing only happens when in a lldb and doesn't affect >> me in practice. > > The only place we use SIGALRM in Emacs is in interval timesr (see > atimer.c), which are used for stuff like hour-glass cursor and input > polling. > > Once again, this might mean we are not cleaning up the process state > before calling execvp. But that is just a speculation. > >>> Anyway, look at the code: we restart by calling execvp. You or >>> someone who knowns macOS internals should take a look at what that >>> means for shared libraries which were loaded by the program that calls >>> execvp -- what happens with those libraries in the execvp'ed process. >>> I'm guessing that they are not being unloaded and re-loaded by the new >>> process, or something to that effect. >>> >>> Or maybe the way we load the *.eln files causes this, triggered by >>> 'execvp'? >> >> This is out of my depth. > > Mine as well. Gerd, any ideas or hints? > >> I did a tiny bit of digging and didn't find anything. > > Likewise. > >>> Can you try running for a while Emacs built without native compilation >>> and restarting it? That could tell us whether the *.eln files are the >>> problem. >> >> I wasn't able to reproduce it w/o native compilation. I'm going to try >> running w/ native compilation for a while *without* doing any restarts >> and see if I can get it to crash. I've seen crashes take an hour+ >> after a restart (though most happen w/in 30 seconds). I can't say >> definitively that all crashes have happened in a restarted process. > > OK, thanks.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Thu, 22 Dec 2022 05:10:02 GMT) Full text and rfc822 format available.Message #35 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 22 Dec 2022 00:09:22 -0500
On Wed, Dec 21, 2022 at 8:29 AM Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote: > > If I remember that correctly, installed signal handlers don’t survive process replacement. The man pages for execve and sigaction should tell. If I'm reading this correctly, that is the case: Signals set to be ignored in the calling process are set to be ignored in the new process. Signals which are set to be caught in the calling process image are set to default action in the new process image. Blocked signals remain blocked regardless of changes to the signal action. The signal stack is reset to be undefined (see sigaction(2) for more information). I have not had a crash today. I have also not restarted Emacs via restart-emacs. Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Thu, 22 Dec 2022 05:13:01 GMT) Full text and rfc822 format available.Message #38 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 22 Dec 2022 00:12:35 -0500
On Thu, Dec 22, 2022 at 12:09 AM Aaron Jensen <aaronjensen <at> gmail.com> wrote: > > On Wed, Dec 21, 2022 at 8:29 AM Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote: > > > > If I remember that correctly, installed signal handlers don’t survive process replacement. The man pages for execve and sigaction should tell. > > If I'm reading this correctly, that is the case: > > Signals set to be ignored in the calling process are set to be ignored > in the new process. Signals which are set to be caught in the calling > process image are set to default action in the new process image. > Blocked > signals remain blocked regardless of changes to the signal action. > The signal stack is reset to be undefined (see sigaction(2) for more > information). > > > > I have not had a crash today. I have also not restarted Emacs via restart-emacs. Is this of any relevance? File descriptors open in the calling process image remain open in the new process image, except for those for which the close-on-exec flag is set (see close(2) and fcntl(2)). Descriptors that remain open are unaffected by execve(). Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Thu, 22 Dec 2022 05:38:01 GMT) Full text and rfc822 format available.Message #41 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Aaron Jensen <aaronjensen <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 22 Dec 2022 06:36:43 +0100
I was more thinking of something like this: A SIGALRM handler is installed in the original process. SIGALRM continues to be delivered to the new process after execve but the signal handler is now the default handler which terminates the process. The man pages I mentioned should say somewhere if that’s plausible. It looks to me like that could be what’s happening. But it’s a guess. If it is that, one would need to arrange for SIGALRM to be ignored before execve and reinitialize a timers in the new process. Or something like that. Sent from my iPhone > On 22. Dec 2022, at 06:12, Aaron Jensen <aaronjensen <at> gmail.com> wrote: > > On Thu, Dec 22, 2022 at 12:09 AM Aaron Jensen <aaronjensen <at> gmail.com> wrote: >> >>> On Wed, Dec 21, 2022 at 8:29 AM Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote: >>> >>> If I remember that correctly, installed signal handlers don’t survive process replacement. The man pages for execve and sigaction should tell. >> >> If I'm reading this correctly, that is the case: >> >> Signals set to be ignored in the calling process are set to be ignored >> in the new process. Signals which are set to be caught in the calling >> process image are set to default action in the new process image. >> Blocked >> signals remain blocked regardless of changes to the signal action. >> The signal stack is reset to be undefined (see sigaction(2) for more >> information). >> >> >> >> I have not had a crash today. I have also not restarted Emacs via restart-emacs. > > > Is this of any relevance? > > File descriptors open in the calling process image remain open in the > new process image, except for those for which the close-on-exec flag > is set (see close(2) and fcntl(2)). Descriptors that remain open are > unaffected by execve(). > > Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Thu, 22 Dec 2022 08:07:02 GMT) Full text and rfc822 format available.Message #44 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Aaron Jensen <aaronjensen <at> gmail.com> Cc: gerd.moellmann <at> gmail.com, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 22 Dec 2022 10:05:52 +0200
> From: Aaron Jensen <aaronjensen <at> gmail.com> > Date: Thu, 22 Dec 2022 00:12:35 -0500 > Cc: Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org > > Is this of any relevance? > > File descriptors open in the calling process image remain open in the > new process image, except for those for which the close-on-exec flag > is set (see close(2) and fcntl(2)). Descriptors that remain open are > unaffected by execve(). I don't think so. But I'm not really sure what is relevant, especially not on macOS.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Thu, 22 Dec 2022 08:19:01 GMT) Full text and rfc822 format available.Message #47 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu> Cc: 60220 <at> debbugs.gnu.org, aaronjensen <at> gmail.com Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 22 Dec 2022 10:18:09 +0200
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> > Date: Thu, 22 Dec 2022 06:36:43 +0100 > Cc: Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org > > I was more thinking of something like this: > > A SIGALRM handler is installed in the original process. SIGALRM continues to be delivered to the new process after execve but the signal handler is now the default handler which terminates the process. > > The man pages I mentioned should say somewhere if that’s plausible. It looks to me like that could be what’s happening. But it’s a guess. > > If it is that, one would need to arrange for SIGALRM to be ignored before execve and reinitialize a timers in the new process. Or something like that. Yes, I think our implementation of restart-emacs might be too naïve. Paul, could you perhaps audit the code which implements restart-emacs, and see if we need to make it safer, in particular wrt signals and *.eln files loaded via dynlib. Note that on Posix platforms we currently load *.eln files with RTLD_LAZY and without RTLD_GLOBAL -- is this of any significance for "restarting" Emacs that was built with native-compilation enabled and has *.eln files loaded? Maybe we need to unload the *.eln before calling execvp? Or maybe we should consider re-implementing restart-emacs in some different way, to avoid these problems? Thanks.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 23 Dec 2022 02:07:02 GMT) Full text and rfc822 format available.Message #50 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Eli Zaretskii <eliz <at> gnu.org>, Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: 60220 <at> debbugs.gnu.org, aaronjensen <at> gmail.com Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 22 Dec 2022 18:05:55 -0800
[Message part 1 (text/plain, inline)]
On 12/22/22 00:18, Eli Zaretskii wrote: > Paul, could you perhaps audit the code which implements restart-emacs, > and see if we need to make it safer, in particular wrt signals and > *.eln files loaded via dynlib. I don't offhand see why anything would need to be done other than turn off timer signals to the execed process. Something like the attached patch, perhaps. Aaron, could you give it a try?
[0001-Fix-restart-emacs-alarms-Bug-60220.patch (text/x-patch, attachment)]
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 23 Dec 2022 02:23:02 GMT) Full text and rfc822 format available.Message #53 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 22 Dec 2022 21:22:38 -0500
On Thu, Dec 22, 2022 at 9:06 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>
> On 12/22/22 00:18, Eli Zaretskii wrote:
> > Paul, could you perhaps audit the code which implements restart-emacs,
> > and see if we need to make it safer, in particular wrt signals and
> > *.eln files loaded via dynlib.
>
> I don't offhand see why anything would need to be done other than turn
> off timer signals to the execed process. Something like the attached
> patch, perhaps. Aaron, could you give it a try?
Thank you, this certainly changes things. I don't get the sig 14
anymore in the debugger and it successfully restarts every time while
in the debugger. I will try using it for a while and see how that
goes.
I don't know if this is significant or not, but when I restart an
Emacs run from the terminal, or in the debugger, I see "Task policy
set failed: 4 ((os/kern) invalid argument)" printed to stderr.
(lldb) process launch
Process 13113 launched: 'src/emacs' (arm64)
Process 13113 stopped
* thread #8, stop reason = exec
frame #0: 0x0000000100934950 dyld`_dyld_start
dyld`:
-> 0x100934950 <+0>: mov x0, sp
0x100934954 <+4>: and sp, x0, #0xfffffffffffffff0
0x100934958 <+8>: mov x29, #0x0
0x10093495c <+12>: mov x30, #0x0
Target 0: (emacs) stopped.
(lldb) thread list
Process 13113 stopped
* thread #8: tid = 0x37d5ee, 0x0000000100934950 dyld`_dyld_start, stop
reason = exec
(lldb) continue
Process 13113 resuming
2022-12-22 21:09:48.439039-0500 emacs[13113:3659246] [assertion] Error
acquiring assertion: <Error Domain=RBSAssertionErrorDomain Code=2
"Specified target process does not exist"
UserInfo={NSLocalizedFailureReason=Specified target process does not
exist}>
2022-12-22 21:09:48.439086-0500 emacs[13113:3659246] [process] Failed
to acquire AppNap adapter assertion with error Error
Domain=RBSAssertionErrorDomain Code=2 "Specified target process does
not exist" UserInfo={NSLocalizedFailureReason=Specified target process
does not exist}
2022-12-22 21:09:48.439102-0500 emacs[13113:3659246] Task policy set
failed: 4 ((os/kern) invalid argument)
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 23 Dec 2022 05:34:02 GMT) Full text and rfc822 format available.Message #56 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Aaron Jensen <aaronjensen <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Fri, 23 Dec 2022 06:33:40 +0100
Can’t say anything useful with regard to these logs I’m afraid.
Sent from my iPhone
> On 23. Dec 2022, at 03:22, Aaron Jensen <aaronjensen <at> gmail.com> wrote:
>
> On Thu, Dec 22, 2022 at 9:06 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>>
>>> On 12/22/22 00:18, Eli Zaretskii wrote:
>>> Paul, could you perhaps audit the code which implements restart-emacs,
>>> and see if we need to make it safer, in particular wrt signals and
>>> *.eln files loaded via dynlib.
>>
>> I don't offhand see why anything would need to be done other than turn
>> off timer signals to the execed process. Something like the attached
>> patch, perhaps. Aaron, could you give it a try?
>
> Thank you, this certainly changes things. I don't get the sig 14
> anymore in the debugger and it successfully restarts every time while
> in the debugger. I will try using it for a while and see how that
> goes.
>
> I don't know if this is significant or not, but when I restart an
> Emacs run from the terminal, or in the debugger, I see "Task policy
> set failed: 4 ((os/kern) invalid argument)" printed to stderr.
>
> (lldb) process launch
> Process 13113 launched: 'src/emacs' (arm64)
> Process 13113 stopped
> * thread #8, stop reason = exec
> frame #0: 0x0000000100934950 dyld`_dyld_start
> dyld`:
> -> 0x100934950 <+0>: mov x0, sp
> 0x100934954 <+4>: and sp, x0, #0xfffffffffffffff0
> 0x100934958 <+8>: mov x29, #0x0
> 0x10093495c <+12>: mov x30, #0x0
> Target 0: (emacs) stopped.
> (lldb) thread list
> Process 13113 stopped
> * thread #8: tid = 0x37d5ee, 0x0000000100934950 dyld`_dyld_start, stop
> reason = exec
> (lldb) continue
> Process 13113 resuming
> 2022-12-22 21:09:48.439039-0500 emacs[13113:3659246] [assertion] Error
> acquiring assertion: <Error Domain=RBSAssertionErrorDomain Code=2
> "Specified target process does not exist"
> UserInfo={NSLocalizedFailureReason=Specified target process does not
> exist}>
> 2022-12-22 21:09:48.439086-0500 emacs[13113:3659246] [process] Failed
> to acquire AppNap adapter assertion with error Error
> Domain=RBSAssertionErrorDomain Code=2 "Specified target process does
> not exist" UserInfo={NSLocalizedFailureReason=Specified target process
> does not exist}
> 2022-12-22 21:09:48.439102-0500 emacs[13113:3659246] Task policy set
> failed: 4 ((os/kern) invalid argument)
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 23 Dec 2022 05:58:02 GMT) Full text and rfc822 format available.Message #59 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Aaron Jensen <aaronjensen <at> gmail.com> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 22 Dec 2022 21:56:56 -0800
On 12/22/22 18:22, Aaron Jensen wrote: > Task policy > set failed: 4 ((os/kern) invalid argument) A Google search reports that message only here: https://developer.apple.com/forums/thread/670595 and that was solved by invoking Apple support. Is that something you can do?
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Sat, 24 Dec 2022 06:47:02 GMT) Full text and rfc822 format available.Message #62 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Sat, 24 Dec 2022 01:45:51 -0500
On Fri, Dec 23, 2022 at 12:56 AM Paul Eggert <eggert <at> cs.ucla.edu> wrote: > > On 12/22/22 18:22, Aaron Jensen wrote: > > Task policy > > set failed: 4 ((os/kern) invalid argument) > > A Google search reports that message only here: > > https://developer.apple.com/forums/thread/670595 > > and that was solved by invoking Apple support. Is that something you can do? I can't say that I've had good experience with Apple support. That person was having problems w/ an Apple app. I'm not sure how they would respond to me raising a concern about Emacs... If I get some time, I'll try opening a ticket just to see what happens. In the interim, I haven't had any crashes since applying the patch. I'll keep testing it. Thanks, Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Sat, 24 Dec 2022 06:58:01 GMT) Full text and rfc822 format available.Message #65 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Aaron Jensen <aaronjensen <at> gmail.com> Cc: gerd.moellmann <at> gmail.com, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Sat, 24 Dec 2022 08:57:13 +0200
> From: Aaron Jensen <aaronjensen <at> gmail.com> > Date: Sat, 24 Dec 2022 01:45:51 -0500 > Cc: Eli Zaretskii <eliz <at> gnu.org>, Gerd Möllmann <gerd.moellmann <at> gmail.com>, > 60220 <at> debbugs.gnu.org > > In the interim, I haven't had any crashes since applying the patch. > I'll keep testing it. Thanks for testing. Does the lack of crashes include the build with native-compilation? In any case, I think we should install Paul's change now. I see no harm from turning off atimers at that point, since even if the restart fails, we are going to exit.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Sat, 24 Dec 2022 07:04:02 GMT) Full text and rfc822 format available.Message #68 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: gerd.moellmann <at> gmail.com, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Sat, 24 Dec 2022 02:03:06 -0500
On Sat, Dec 24, 2022 at 1:57 AM Eli Zaretskii <eliz <at> gnu.org> wrote: > > > From: Aaron Jensen <aaronjensen <at> gmail.com> > > Date: Sat, 24 Dec 2022 01:45:51 -0500 > > Cc: Eli Zaretskii <eliz <at> gnu.org>, Gerd Möllmann <gerd.moellmann <at> gmail.com>, > > 60220 <at> debbugs.gnu.org > > > > In the interim, I haven't had any crashes since applying the patch. > > I'll keep testing it. > > Thanks for testing. Does the lack of crashes include the build with > native-compilation? Yes, I am using native compilation. > In any case, I think we should install Paul's change now. I see no > harm from turning off atimers at that point, since even if the restart > fails, we are going to exit. That would be great. Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Sat, 24 Dec 2022 08:26:02 GMT) Full text and rfc822 format available.Message #71 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Eli Zaretskii <eliz <at> gnu.org>, Aaron Jensen <aaronjensen <at> gmail.com> Cc: gerd.moellmann <at> gmail.com, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Sat, 24 Dec 2022 00:25:00 -0800
On 12/23/22 22:57, Eli Zaretskii wrote: > In any case, I think we should install Paul's change now. OK, installed on emacs-29 branch.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Sat, 24 Dec 2022 15:12:02 GMT) Full text and rfc822 format available.Message #74 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Sat, 24 Dec 2022 10:11:02 -0500
On Fri, Dec 23, 2022 at 12:56 AM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>
> On 12/22/22 18:22, Aaron Jensen wrote:
> > Task policy
> > set failed: 4 ((os/kern) invalid argument)
>
> A Google search reports that message only here:
>
> https://developer.apple.com/forums/thread/670595
>
> and that was solved by invoking Apple support. Is that something you can do?
I don't know if it's related or just because I am running in the
XCode's debugger, but when I do that, I see additional messages:
2022-12-24 10:05:30.309314-0500 emacs[5082:176291] [assertion] Error
acquiring assertion: <Error Domain=RBSAssertionErrorDomain Code=2
"Specified target process does not exist"
UserInfo={NSLocalizedFailureReason=Specified target process does not
exist}>
2022-12-24 10:05:30.309369-0500 emacs[5082:176291] [process] Failed to
acquire AppNap adapter assertion with error Error
Domain=RBSAssertionErrorDomain Code=2 "Specified target process does
not exist" UserInfo={NSLocalizedFailureReason=Specified target process
does not exist}
2022-12-24 10:05:30.309394-0500 emacs[5082:176291] Task policy set
failed: 4 ((os/kern) invalid argument)
Also, when running from the `src/emacs` binary, after a restart the
application icon in macOS changes to the terminal icon with the word
`exec` in it.
Per: https://stackoverflow.com/questions/27479801/restart-application-programmatically
and: http://13bold.com/tutorials/relaunching-your-application/
I wonder if this method of restarting is just not the right idea on
macOS and it either needs to be relaunched with a helper utility or in
a completely separate process directly as described in some of the
further down stackoverflow answers.
Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Sun, 25 Dec 2022 05:31:02 GMT) Full text and rfc822 format available.Message #77 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Aaron Jensen <aaronjensen <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Sun, 25 Dec 2022 06:30:35 +0100
Could well be. I’ve heard that one has to jump to similar hoops of using a helper process to add an app to startup items for instance, to satisfy launchd so to speak. And the application icon is also a launchd thing, as is the whole starting of an an application bundle…
Sent from my iPhone
> On 24. Dec 2022, at 16:11, Aaron Jensen <aaronjensen <at> gmail.com> wrote:
>
> On Fri, Dec 23, 2022 at 12:56 AM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>>
>>> On 12/22/22 18:22, Aaron Jensen wrote:
>>> Task policy
>>> set failed: 4 ((os/kern) invalid argument)
>>
>> A Google search reports that message only here:
>>
>> https://developer.apple.com/forums/thread/670595
>>
>> and that was solved by invoking Apple support. Is that something you can do?
>
> I don't know if it's related or just because I am running in the
> XCode's debugger, but when I do that, I see additional messages:
>
> 2022-12-24 10:05:30.309314-0500 emacs[5082:176291] [assertion] Error
> acquiring assertion: <Error Domain=RBSAssertionErrorDomain Code=2
> "Specified target process does not exist"
> UserInfo={NSLocalizedFailureReason=Specified target process does not
> exist}>
>
> 2022-12-24 10:05:30.309369-0500 emacs[5082:176291] [process] Failed to
> acquire AppNap adapter assertion with error Error
> Domain=RBSAssertionErrorDomain Code=2 "Specified target process does
> not exist" UserInfo={NSLocalizedFailureReason=Specified target process
> does not exist}
>
> 2022-12-24 10:05:30.309394-0500 emacs[5082:176291] Task policy set
> failed: 4 ((os/kern) invalid argument)
>
> Also, when running from the `src/emacs` binary, after a restart the
> application icon in macOS changes to the terminal icon with the word
> `exec` in it.
>
> Per: https://stackoverflow.com/questions/27479801/restart-application-programmatically
> and: http://13bold.com/tutorials/relaunching-your-application/
>
> I wonder if this method of restarting is just not the right idea on
> macOS and it either needs to be relaunched with a helper utility or in
> a completely separate process directly as described in some of the
> further down stackoverflow answers.
>
> Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Sun, 25 Dec 2022 19:31:02 GMT) Full text and rfc822 format available.Message #80 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Sun, 25 Dec 2022 14:30:14 -0500
Unfortunately, I just got a crash:
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Process: Emacs [642]
Path: /opt/homebrew/*/Emacs.app/Contents/MacOS/Emacs
Identifier: org.gnu.Emacs
Version: Version 29.0.60 (9.0)
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
User ID: 501
Date/Time: 2022-12-25 14:28:45.8693 -0500
OS Version: macOS 13.1 (22C65)
Report Version: 12
Anonymous UUID: CD1F31D7-5E61-2935-643D-55F58CD29C12
Sleep/Wake UUID: 2679CDEF-2FD4-4A89-92F7-619CD5C1E50A
Time Awake Since Boot: 60000 seconds
Time Since Wake: 2033 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 0x00000000000000f9
Exception Codes: 0x0000000000000001, 0x00000000000000f9
VM Region Info: 0xf9 is not in any region. Bytes before following
region: 105553518919431
REGION TYPE START - END [ VSIZE]
PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
MALLOC_NANO (reserved) 600018000000-600020000000 [128.0M]
rw-/rwx SM=NUL ...(unallocated)
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x1a6d621b0 __pthread_kill + 8
1 libsystem_pthread.dylib 0x1a6d98cec pthread_kill + 288
2 libsystem_c.dylib 0x1a6c9aa50 raise + 32
3 Emacs 0x10431daec
terminate_due_to_signal + 204
4 Emacs 0x10431e2f0 emacs_abort + 20
5 Emacs 0x1042ecdb0 ns_term_shutdown + 132
6 Emacs 0x1041d8b94 shut_down_emacs + 332
7 Emacs 0x10431dab4
terminate_due_to_signal + 148
8 Emacs 0x1041fb084 handle_fatal_signal + 16
9 Emacs 0x1041fb100
deliver_thread_signal + 124
10 Emacs 0x1041f9700
deliver_fatal_thread_signal + 12
11 Emacs 0x1041fb160 handle_sigsegv + 96
12 libsystem_platform.dylib 0x1a6dc72a4 _sigtramp + 56
13 ??? 0xffff8001a6a99380 ???
14 dyld 0x1a6a99d54
lsl::BTree<lsl::Allocator::Buffer,
std::__1::less<lsl::Allocator::Buffer>,
false>::erase(lsl::BTree<lsl::Allocator::Buffer,
std::__1::less<lsl::Allocator::Buffer>, false>::const_iterator) + 76
15 dyld 0x1a6a999fc
lsl::PersistentAllocator::reserveRange(lsl::BTree<lsl::Allocator::Buffer,
lsl::PersistentAllocator::RegionSizeCompare, false>::const_iterator&,
lsl::Allocator::Buffer) + 264
16 dyld 0x1a6a9a0b0
lsl::PersistentAllocator::allocate_buffer(unsigned long, unsigned
long, unsigned long, lsl::Allocator**) + 624
17 dyld 0x1a6a991e0
lsl::Allocator::aligned_alloc(unsigned long, unsigned long) + 180
18 dyld 0x1a6a99230
lsl::Allocator::strdup(char const*) + 48
19 dyld 0x1a6a968b8
dyld4::FileManager::fileRecordForPath(char const*) + 40
20 dyld 0x1a6ab4624
dyld4::Atlas::ProcessSnapshot::Serializer::readMappedFileInfo(std::__1::span<std::byte,
18446744073709551615ul>&, unsigned long long&, lsl::UUID&,
dyld4::FileRecord&) + 132
21 dyld 0x1a6ab3170
dyld4::Atlas::ProcessSnapshot::Serializer::deserialize(std::__1::span<std::byte,
18446744073709551615ul>) + 928
22 dyld 0x1a6ab2cec
dyld4::Atlas::ProcessSnapshot::ProcessSnapshot(lsl::Allocator&,
dyld4::FileManager&, bool, std::__1::span<std::byte,
18446744073709551615ul>) + 304
23 dyld 0x1a6a7ef64
lsl::UniquePtr<dyld4::Atlas::ProcessSnapshot>
lsl::Allocator::makeUnique<dyld4::Atlas::ProcessSnapshot,
lsl::EphemeralAllocator&, dyld4::FileManager&, bool,
std::__1::span<std::byte, 18446744073709551615ul>
const&>(lsl::EphemeralAllocator&, dyld4::FileManager&, bool&&,
std::__1::span<std::byte, 18446744073709551615ul> const&) + 80
24 dyld 0x1a6a7bafc
dyld4::RuntimeState::getCurrentProcessSnapshot() + 96
25 dyld 0x1a6a7b8cc
dyld4::RuntimeState::notifyDebuggerLoad(std::__1::span<dyld4::Loader
const*, 18446744073709551615ul> const&) + 72
26 dyld 0x1a6aaaf3c
dyld4::APIs::dlopen_from(char const*, int, void*)::$_0::operator()()
const + 748
27 dyld 0x1a6aa4968
dyld4::APIs::dlopen_from(char const*, int, void*) + 892
28 Emacs 0x1042a0db0 Fnative_elisp_load + 356
29 Emacs 0x10427c88c Fload + 2104
30 Emacs 0x10427e5f0 save_match_data_load + 92
31 Emacs 0x104258928
load_with_autoload_queue + 120
32 Emacs 0x104264d84 Frequire + 560
33 Emacs 0x104254a30 eval_sub + 2236
34 Emacs 0x104257158
internal_lisp_condition_case + 884
35 Emacs 0x10425489c eval_sub + 1832
36 Emacs 0x104254bac Fprogn + 48
37 Emacs 0x1042563a8 Fwhile + 80
38 Emacs 0x10425489c eval_sub + 1832
39 Emacs 0x104254bac Fprogn + 48
40 Emacs 0x10425a10c funcall_lambda + 1316
41 Emacs 0x104256724 Ffuncall + 316
42 Emacs 0x104256724 Ffuncall + 316
43 timer-3ee7cfd9-d55357b5.eln 0x10b104e44
F74696d65722d6576656e742d68616e646c6572_timer_event_handler_0 + 832
44 Emacs 0x104256724 Ffuncall + 316
45 Emacs 0x1041e5288 timer_check + 892
46 Emacs 0x1041e3634 readable_events + 36
47 Emacs 0x1041e4eb4 get_input_pending + 56
48 Emacs 0x1041e3364
detect_input_pending_run_timers + 48
49 Emacs 0x1042ab064
wait_reading_process_output + 3824
50 Emacs 0x1041e11e0 read_char + 8656
51 Emacs 0x1041dd548 read_key_sequence + 1056
52 Emacs 0x1041dbdb8 command_loop_1 + 700
53 Emacs 0x10425732c
internal_condition_case + 96
54 Emacs 0x1041dbae8 command_loop_2 + 52
55 Emacs 0x104256d50 internal_catch + 88
56 Emacs 0x10431df18 command_loop.cold.1 + 80
57 Emacs 0x1041db488 command_loop + 152
58 Emacs 0x1041db344 recursive_edit_1 + 148
59 Emacs 0x1041db5a8 Frecursive_edit + 264
60 Emacs 0x1041da924 main + 7484
61 dyld 0x1a6a6fe50 start + 2544
Thread 1:
0 libsystem_pthread.dylib 0x1a6d93e18 start_wqthread + 0
Thread 2:
0 libsystem_pthread.dylib 0x1a6d93e18 start_wqthread + 0
Thread 3:: gmain
0 libsystem_kernel.dylib 0x1a6d64a00 __select + 8
1 libglib-2.0.0.dylib 0x10517fb20 g_poll + 424
2 libglib-2.0.0.dylib 0x105172cc4
g_main_context_iterate + 340
3 libglib-2.0.0.dylib 0x105172d8c
g_main_context_iteration + 60
4 libglib-2.0.0.dylib 0x105174124 glib_worker_main + 48
5 libglib-2.0.0.dylib 0x1051973a8 g_thread_proxy + 68
6 libsystem_pthread.dylib 0x1a6d9906c _pthread_start + 148
7 libsystem_pthread.dylib 0x1a6d93e2c thread_start + 8
Thread 4:
0 libsystem_pthread.dylib 0x1a6d93e18 start_wqthread + 0
Thread 5:
0 libsystem_pthread.dylib 0x1a6d93e18 start_wqthread + 0
Thread 6:
0 libsystem_pthread.dylib 0x1a6d93e18 start_wqthread + 0
Thread 7:
0 libsystem_kernel.dylib 0x1a6d5ffa4 __pselect + 8
1 libsystem_kernel.dylib 0x1a6d5fe7c pselect$DARWIN_EXTSN + 64
2 Emacs 0x1042ede90 -[EmacsApp
fd_handler:] + 184
3 Foundation 0x1a7d79470 __NSThread__start__ + 716
4 libsystem_pthread.dylib 0x1a6d9906c _pthread_start + 148
5 libsystem_pthread.dylib 0x1a6d93e2c thread_start + 8
Thread 8:: com.apple.NSEventThread
0 libsystem_kernel.dylib 0x1a6d59d70 mach_msg2_trap + 8
1 libsystem_kernel.dylib 0x1a6d6b8a4 mach_msg2_internal + 80
2 libsystem_kernel.dylib 0x1a6d625c4 mach_msg_overwrite + 540
3 libsystem_kernel.dylib 0x1a6d5a0ec mach_msg + 24
4 CoreFoundation 0x1a6e78bc0
__CFRunLoopServiceMachPort + 160
5 CoreFoundation 0x1a6e774ac __CFRunLoopRun + 1232
6 CoreFoundation 0x1a6e76888 CFRunLoopRunSpecific + 612
7 AppKit 0x1aa222410 _NSEventThread + 172
8 libsystem_pthread.dylib 0x1a6d9906c _pthread_start + 148
9 libsystem_pthread.dylib 0x1a6d93e2c thread_start + 8
Thread 0 crashed with ARM Thread State (64-bit):
x0: 0x0000000000000000 x1: 0x0000000000000000 x2:
0x0000000000000000 x3: 0x0000600003839480
x4: 0x0000600003839460 x5: 0x0000000000000000 x6:
0x0000000000000067 x7: 0x000000000000001c
x8: 0xf7585af72d0ca2d0 x9: 0xf7585af52f035850 x10:
0x0000000000000001 x11: 0x0000000000000003
x12: 0x0000000000000001 x13: 0x0000600002c7cc00 x14:
0x010000020211fee9 x15: 0x000000020211fee8
x16: 0x0000000000000148 x17: 0x0000000206f407f0 x18:
0x0000000000000000 x19: 0x0000000000000006
x20: 0x00000002020ffa80 x21: 0x0000000000000103 x22:
0x00000002020ffb60 x23: 0x000002094c88f008
x24: 0x000000016bce9e01 x25: 0x0000000000000008 x26:
0x00000000000002c0 x27: 0x0000000163bfb7d0
x28: 0x0000000163bfb840 fp: 0x00000001048d9910 lr: 0x00000001a6d98cec
sp: 0x00000001048d98f0 pc: 0x00000001a6d621b0 cpsr: 0x40001000
far: 0x000001374cb34000 esr: 0x56000080 Address size fault
Binary Images:
0x1a6d59000 - 0x1a6d91ff3 libsystem_kernel.dylib (*)
<aebf397e-e2ef-3a49-be58-23d4558511f6>
/usr/lib/system/libsystem_kernel.dylib
0x1a6d92000 - 0x1a6d9effb libsystem_pthread.dylib (*)
<132084c6-c347-3489-9ac2-fcaad21cdb73>
/usr/lib/system/libsystem_pthread.dylib
0x1a6c59000 - 0x1a6cd9ff3 libsystem_c.dylib (*)
<756cd0d2-3241-3a74-8c59-02632dcee221>
/usr/lib/system/libsystem_c.dylib
0x104110000 - 0x104367fff org.gnu.Emacs (Version
29.0.60) <05fbbbfb-3405-3d9f-a7a0-4fd6430863ba>
/opt/homebrew/*/Emacs.app/Contents/MacOS/Emacs
0x1a6dc3000 - 0x1a6dcaffb libsystem_platform.dylib (*)
<b215ae90-4ed2-3fcd-8ccc-6c0d93cc4f41>
/usr/lib/system/libsystem_platform.dylib
0x0 - 0xffffffffffffffff ??? (*)
<00000000-0000-0000-0000-000000000000> ???
0x1a6a6a000 - 0x1a6af4b63 dyld (*)
<487cfdeb-9b07-39bf-bfb9-970b61aea2d1> /usr/lib/dyld
0x10b100000 - 0x10b107fff timer-3ee7cfd9-d55357b5.eln
(*) <0f550bba-4a80-3546-98fe-a92aa0d14158>
/opt/homebrew/*/Emacs.app/Contents/native-lisp/29.0.60-c7b10636/preloaded/timer-3ee7cfd9-d55357b5.eln
0x10513c000 - 0x105223fff libglib-2.0.0.dylib (*)
<f593e720-37ac-3b64-8d96-f9c330062fec>
/opt/homebrew/*/libglib-2.0.0.dylib
0x1a7d23000 - 0x1a875bfff com.apple.Foundation (6.9)
<f1f5f857-8c3c-36d5-bc27-7702d6795468>
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x1a6df7000 - 0x1a72cefff com.apple.CoreFoundation (6.9)
<fd16d6d9-10c0-323b-b43b-9781c4a4d268>
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x1aa0bf000 - 0x1aafc9fff com.apple.AppKit (6.9)
<dbbd4dea-6c68-3200-a81b-79b6a62f4669>
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 9464
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: 532120
thread_create: 0
thread_set_state: 48
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Sun, 25 Dec 2022 20:00:02 GMT) Full text and rfc822 format available.Message #83 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Aaron Jensen <aaronjensen <at> gmail.com> Cc: gerd.moellmann <at> gmail.com, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Sun, 25 Dec 2022 21:59:35 +0200
> From: Aaron Jensen <aaronjensen <at> gmail.com> > Date: Sun, 25 Dec 2022 14:30:14 -0500 > Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org > > Unfortunately, I just got a crash: It's again inside dlopen. We need a macOS expert to tell us what we are doing wrong that causes crashes there.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Tue, 27 Dec 2022 11:13:01 GMT) Full text and rfc822 format available.Message #86 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: gerd.moellmann <at> gmail.com, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Tue, 27 Dec 2022 06:12:35 -0500
On Sun, Dec 25, 2022 at 2:59 PM Eli Zaretskii <eliz <at> gnu.org> wrote: > > > From: Aaron Jensen <aaronjensen <at> gmail.com> > > Date: Sun, 25 Dec 2022 14:30:14 -0500 > > Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org > > > > Unfortunately, I just got a crash: > > It's again inside dlopen. We need a macOS expert to tell us what we > are doing wrong that causes crashes there. I found a similar issue in another program: https://forum.xojo.com/t/xojo-2022r3-1-crashes-galore/72887/142 They seem to have concluded that it is a macOS bug introduced in Ventura (13.0) that causes dlopen to crash maybe 1% of the time while loading libraries. They have reported it to Apple. It is not yet fixed (even in the latest beta) so I may need to live with this for a while. I will send crash reports to apple every chance I get. Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Tue, 27 Dec 2022 13:12:02 GMT) Full text and rfc822 format available.Message #89 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Aaron Jensen <aaronjensen <at> gmail.com> Cc: gerd.moellmann <at> gmail.com, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Tue, 27 Dec 2022 15:11:03 +0200
> From: Aaron Jensen <aaronjensen <at> gmail.com> > Date: Tue, 27 Dec 2022 06:12:35 -0500 > Cc: gerd.moellmann <at> gmail.com, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org > > I found a similar issue in another program: > https://forum.xojo.com/t/xojo-2022r3-1-crashes-galore/72887/142 Maybe, maybe not. Your crashes always happen after restarting, right? You don't see crashes inside dlopen if you never restart, correct? But yes, it could be something related. My production session has 260 *.eln files loaded, for example. So if macOS 13 has problems with loading many shared libraries, maybe this is one of the symptoms.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Thu, 29 Dec 2022 22:49:01 GMT) Full text and rfc822 format available.Message #92 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: gerd.moellmann <at> gmail.com, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 29 Dec 2022 17:47:51 -0500
On Tue, Dec 27, 2022 at 8:11 AM Eli Zaretskii <eliz <at> gnu.org> wrote: > > > From: Aaron Jensen <aaronjensen <at> gmail.com> > > Date: Tue, 27 Dec 2022 06:12:35 -0500 > > Cc: gerd.moellmann <at> gmail.com, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org > > > > I found a similar issue in another program: > > https://forum.xojo.com/t/xojo-2022r3-1-crashes-galore/72887/142 > > Maybe, maybe not. Your crashes always happen after restarting, right? > You don't see crashes inside dlopen if you never restart, correct? > > But yes, it could be something related. My production session has 260 > *.eln files loaded, for example. So if macOS 13 has problems with > loading many shared libraries, maybe this is one of the symptoms. I can't say that with 100% certainty. Sometimes the crashes are hours after I started Emacs and I don't know if I had ever restarted that session. I do seem to be crashing a lot less frequently after the signal patch, which is probably just a coincidence, but who knows. Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Thu, 29 Dec 2022 23:48:02 GMT) Full text and rfc822 format available.Message #95 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: gerd.moellmann <at> gmail.com, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 29 Dec 2022 18:46:54 -0500
On Thu, Dec 29, 2022 at 5:47 PM Aaron Jensen <aaronjensen <at> gmail.com> wrote:
>
> On Tue, Dec 27, 2022 at 8:11 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > From: Aaron Jensen <aaronjensen <at> gmail.com>
> > > Date: Tue, 27 Dec 2022 06:12:35 -0500
> > > Cc: gerd.moellmann <at> gmail.com, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org
> > >
> > > I found a similar issue in another program:
> > > https://forum.xojo.com/t/xojo-2022r3-1-crashes-galore/72887/142
> >
> > Maybe, maybe not. Your crashes always happen after restarting, right?
> > You don't see crashes inside dlopen if you never restart, correct?
> >
> > But yes, it could be something related. My production session has 260
> > *.eln files loaded, for example. So if macOS 13 has problems with
> > loading many shared libraries, maybe this is one of the symptoms.
>
> I can't say that with 100% certainty. Sometimes the crashes are hours
> after I started Emacs and I don't know if I had ever restarted that
> session. I do seem to be crashing a lot less frequently after the
> signal patch, which is probably just a coincidence, but who knows.
>
> Aaron
I just got a crash on a fresh start, so I now know it is not related
to restarts. Interestingly enough, this crash and the one just before
show the eln that is being loaded. The first time it was:
vc-hg-69e20438-d4ba19ca.eln
and the second time it was:
magit-status-6f9334e6-b672845f.eln
It seems to happen more often when I immediately start doing something
in Emacs. One thing of note is that I have something that eagerly
loads packages on an idle timer (it caches what was loaded when Emacs
is quit). That's possibly why there is usually a timer_event_handler
in the trace. I don't know if that gives us any clues as to what may
be happening here.
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Process: Emacs [19874]
Path: /opt/homebrew/*/Emacs.app/Contents/MacOS/Emacs
Identifier: org.gnu.Emacs
Version: Version 29.0.60 (9.0)
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
User ID: 501
Date/Time: 2022-12-29 18:41:27.1385 -0500
OS Version: macOS 13.1 (22C65)
Report Version: 12
Anonymous UUID: CD1F31D7-5E61-2935-643D-55F58CD29C12
Sleep/Wake UUID: FC867C11-7B4D-45DA-A2FF-FE03A9A69EF4
Time Awake Since Boot: 210000 seconds
Time Since Wake: 5671 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_PROTECTION_FAILURE at 0x000000013b1940f8
Exception Codes: 0x0000000000000002, 0x000000013b1940f8
VM Region Info: 0x13b1940f8 is in 0x13b194000-0x13b1ac000; bytes
after start: 248 bytes before end: 98055
REGION TYPE START - END [ VSIZE]
PRT/MAX SHRMOD REGION DETAIL
dyld private memory 13b154000-13b194000 [ 256K]
rw-/rwx SM=PRV
---> __TEXT 13b194000-13b1ac000 [ 96K]
r-x/rwx SM=COW ...-b672845f.eln
__DATA_CONST 13b1ac000-13b1b0000 [ 16K]
r--/rwx SM=COW ...-b672845f.eln
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x1a6d621b0 __pthread_kill + 8
1 libsystem_pthread.dylib 0x1a6d98cec pthread_kill + 288
2 libsystem_c.dylib 0x1a6c9aa50 raise + 32
3 Emacs 0x100d69aec
terminate_due_to_signal + 204
4 Emacs 0x100d6a2f0 emacs_abort + 20
5 Emacs 0x100d38db0 ns_term_shutdown + 132
6 Emacs 0x100c24b94 shut_down_emacs + 332
7 Emacs 0x100d69ab4
terminate_due_to_signal + 148
8 Emacs 0x100c47084 handle_fatal_signal + 16
9 Emacs 0x100c47100
deliver_thread_signal + 124
10 Emacs 0x100c45700
deliver_fatal_thread_signal + 12
11 libsystem_platform.dylib 0x1a6dc72a4 _sigtramp + 56
12 dyld 0x1a6a9c1b4
lsl::BTree<lsl::Allocator::Buffer,
lsl::PersistentAllocator::RegionSizeCompare, false>::NodeCore<15u,
10u>::splitChild(unsigned char, lsl::Allocator&) + 172
13 dyld 0x1a6a9c1b4
lsl::BTree<lsl::Allocator::Buffer,
lsl::PersistentAllocator::RegionSizeCompare, false>::NodeCore<15u,
10u>::splitChild(unsigned char, lsl::Allocator&) + 172
14 dyld 0x1a6a9bf78
lsl::BTree<lsl::Allocator::Buffer,
lsl::PersistentAllocator::RegionSizeCompare,
false>::const_iterator::prepareForInsertion(lsl::Allocator&) + 532
15 dyld 0x1a6a9bbb0
lsl::BTree<lsl::Allocator::Buffer,
lsl::PersistentAllocator::RegionSizeCompare,
false>::insert_internal(lsl::BTree<lsl::Allocator::Buffer,
lsl::PersistentAllocator::RegionSizeCompare, false>::const_iterator&&,
lsl::Allocator::Buffer&&) + 452
16 dyld 0x1a6a99a90
lsl::PersistentAllocator::reserveRange(lsl::BTree<lsl::Allocator::Buffer,
lsl::PersistentAllocator::RegionSizeCompare, false>::const_iterator&,
lsl::Allocator::Buffer) + 412
17 dyld 0x1a6a9a0b0
lsl::PersistentAllocator::allocate_buffer(unsigned long, unsigned
long, unsigned long, lsl::Allocator**) + 624
18 dyld 0x1a6a991e0
lsl::Allocator::aligned_alloc(unsigned long, unsigned long) + 180
19 dyld 0x1a6a99230
lsl::Allocator::strdup(char const*) + 48
20 dyld 0x1a6a968b8
dyld4::FileManager::fileRecordForPath(char const*) + 40
21 dyld 0x1a6ab4624
dyld4::Atlas::ProcessSnapshot::Serializer::readMappedFileInfo(std::__1::span<std::byte,
18446744073709551615ul>&, unsigned long long&, lsl::UUID&,
dyld4::FileRecord&) + 132
22 dyld 0x1a6ab3170
dyld4::Atlas::ProcessSnapshot::Serializer::deserialize(std::__1::span<std::byte,
18446744073709551615ul>) + 928
23 dyld 0x1a6ab2cec
dyld4::Atlas::ProcessSnapshot::ProcessSnapshot(lsl::Allocator&,
dyld4::FileManager&, bool, std::__1::span<std::byte,
18446744073709551615ul>) + 304
24 dyld 0x1a6a7ef64
lsl::UniquePtr<dyld4::Atlas::ProcessSnapshot>
lsl::Allocator::makeUnique<dyld4::Atlas::ProcessSnapshot,
lsl::EphemeralAllocator&, dyld4::FileManager&, bool,
std::__1::span<std::byte, 18446744073709551615ul>
const&>(lsl::EphemeralAllocator&, dyld4::FileManager&, bool&&,
std::__1::span<std::byte, 18446744073709551615ul> const&) + 80
25 dyld 0x1a6a7bafc
dyld4::RuntimeState::getCurrentProcessSnapshot() + 96
26 dyld 0x1a6a7b8cc
dyld4::RuntimeState::notifyDebuggerLoad(std::__1::span<dyld4::Loader
const*, 18446744073709551615ul> const&) + 72
27 dyld 0x1a6aaaf3c
dyld4::APIs::dlopen_from(char const*, int, void*)::$_0::operator()()
const + 748
28 dyld 0x1a6aa4968
dyld4::APIs::dlopen_from(char const*, int, void*) + 892
29 Emacs 0x100cecdb0 Fnative_elisp_load + 356
30 Emacs 0x100cc888c Fload + 2104
31 Emacs 0x100cca5f0 save_match_data_load + 92
32 Emacs 0x100ca4928
load_with_autoload_queue + 120
33 Emacs 0x100cb0d84 Frequire + 560
34 Emacs 0x100ca0a30 eval_sub + 2236
35 Emacs 0x100ca3158
internal_lisp_condition_case + 884
36 Emacs 0x100ca089c eval_sub + 1832
37 Emacs 0x100ca0bac Fprogn + 48
38 Emacs 0x100ca23a8 Fwhile + 80
39 Emacs 0x100ca089c eval_sub + 1832
40 Emacs 0x100ca0bac Fprogn + 48
41 Emacs 0x100ca610c funcall_lambda + 1316
42 Emacs 0x100ca2724 Ffuncall + 316
43 Emacs 0x100ca2724 Ffuncall + 316
44 timer-3ee7cfd9-d55357b5.eln 0x107b40e44
F74696d65722d6576656e742d68616e646c6572_timer_event_handler_0 + 832
45 Emacs 0x100ca2724 Ffuncall + 316
46 Emacs 0x100c31288 timer_check + 892
47 Emacs 0x100c2f634 readable_events + 36
48 Emacs 0x100c30eb4 get_input_pending + 56
49 Emacs 0x100c2f364
detect_input_pending_run_timers + 48
50 Emacs 0x100cf7064
wait_reading_process_output + 3824
51 Emacs 0x100b6d4d8 sit_for + 376
52 Emacs 0x100c2ca74 read_char + 6756
53 Emacs 0x100c29548 read_key_sequence + 1056
54 Emacs 0x100c27db8 command_loop_1 + 700
55 Emacs 0x100ca332c
internal_condition_case + 96
56 Emacs 0x100c27ae8 command_loop_2 + 52
57 Emacs 0x100ca2d50 internal_catch + 88
58 Emacs 0x100d69f18 command_loop.cold.1 + 80
59 Emacs 0x100c27488 command_loop + 152
60 Emacs 0x100c27344 recursive_edit_1 + 148
61 Emacs 0x100c275a8 Frecursive_edit + 264
62 Emacs 0x100c26924 main + 7484
63 dyld 0x1a6a6fe50 start + 2544
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Thu, 29 Dec 2022 23:51:02 GMT) Full text and rfc822 format available.Message #98 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Aaron Jensen <aaronjensen <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org> Cc: gerd.moellmann <at> gmail.com, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 29 Dec 2022 15:49:55 -0800
On 12/29/22 15:46, Aaron Jensen wrote: > have something that eagerly > loads packages on an idle timer (it caches what was loaded when Emacs > is quit). Could it by that the dynamic linker is being invoked recursively? That is, while something is being dynamically linked, a SIGALRM or equivalent arrives, some idle timer code is run, and the dynamic linker is invoked before the outer linker finishes? I imagine that might put some dynamic linkers into a tizzy.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 00:00:02 GMT) Full text and rfc822 format available.Message #101 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 29 Dec 2022 18:59:41 -0500
On Thu, Dec 29, 2022 at 6:49 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote: > > On 12/29/22 15:46, Aaron Jensen wrote: > > have something that eagerly > > loads packages on an idle timer (it caches what was loaded when Emacs > > is quit). > > Could it by that the dynamic linker is being invoked recursively? That > is, while something is being dynamically linked, a SIGALRM or equivalent > arrives, some idle timer code is run, and the dynamic linker is invoked > before the outer linker finishes? I imagine that might put some dynamic > linkers into a tizzy. I have no idea, would we see that in the trace at all? Here are two more crashes: https://gist.github.com/aaronjensen/f7c46857ea93c858f46a639d8880f290 I have been able to reproduce it just now pretty easily, but I still can't reproduce it with the debugger attached.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 00:05:01 GMT) Full text and rfc822 format available.Message #104 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 29 Dec 2022 19:03:47 -0500
On Thu, Dec 29, 2022 at 6:59 PM Aaron Jensen <aaronjensen <at> gmail.com> wrote: > > On Thu, Dec 29, 2022 at 6:49 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote: > > > > On 12/29/22 15:46, Aaron Jensen wrote: > > > have something that eagerly > > > loads packages on an idle timer (it caches what was loaded when Emacs > > > is quit). > > > > Could it by that the dynamic linker is being invoked recursively? That > > is, while something is being dynamically linked, a SIGALRM or equivalent > > arrives, some idle timer code is run, and the dynamic linker is invoked > > before the outer linker finishes? I imagine that might put some dynamic > > linkers into a tizzy. > > > I have no idea, would we see that in the trace at all? Here are two > more crashes: https://gist.github.com/aaronjensen/f7c46857ea93c858f46a639d8880f290 > > I have been able to reproduce it just now pretty easily, but I still > can't reproduce it with the debugger attached. Would it make sense to use block_atimers while loading native lisp? If that's a workable thing and you can send me a patch I can try it out. Thanks, Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 00:09:01 GMT) Full text and rfc822 format available.Message #107 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Aaron Jensen <aaronjensen <at> gmail.com> Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 29 Dec 2022 16:08:37 -0800
On 12/29/22 15:59, Aaron Jensen wrote: > On Thu, Dec 29, 2022 at 6:49 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote: >> >> Could it by that the dynamic linker is being invoked recursively? That >> is, while something is being dynamically linked, a SIGALRM or equivalent >> arrives, some idle timer code is run, and the dynamic linker is invoked >> before the outer linker finishes? I imagine that might put some dynamic >> linkers into a tizzy. > > I have no idea, would we see that in the trace at all? Not necessarily from the traces you sent. For example, if the inner dynamic linker function corrupts data but returns, the crash will occur when there's only one dynamic linker activation record on the stack, even though that call wasn't the problem. It may require some macOS expertise and access to a dynamic debugger to diagnose this further. (I have neither.) Possibly you could deduce it by running Emacs under dtrace or equivalent (sorry, can't help you with that either).
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 01:17:02 GMT) Full text and rfc822 format available.Message #110 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Aaron Jensen <aaronjensen <at> gmail.com> Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 29 Dec 2022 17:16:18 -0800
On 12/29/22 16:03, Aaron Jensen wrote: > Would it make sense to use block_atimers while loading native lisp? If Might, but it might make more sense not to be dynamically loading code during an idle timer. Surely this could cause problems even in non-native lisp. Anyway, I suggest consulting a macOS expert before doing much experimenting; there's not enough evidence now for me to give advice.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 01:21:01 GMT) Full text and rfc822 format available.Message #113 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 29 Dec 2022 17:20:14 -0800
[Message part 1 (text/plain, inline)]
Hm, I don’t see how that could be generally avoided. All it would take is any idle timer that evals auto loaded code that was yet to be loaded. If this is in fact the problem it does seem unlikely anyone would hit it unless they were doing what I am doing, but that would only be a coincidence. I wonder if there are any macOS experts here. I can try asking on stack overflow or maybe opening a support case. I’ve never been able to get to a developer though. Aaron On Thu, Dec 29 2022 at 8:16 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote: > On 12/29/22 16:03, Aaron Jensen wrote: > > Would it make sense to use block_atimers while loading native lisp? If > > Might, but it might make more sense not to be dynamically loading code > during an idle timer. Surely this could cause problems even in non-native > lisp. Anyway, I suggest consulting a macOS expert before doing much > experimenting; there's not enough evidence now for me to give advice. >
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 02:12:02 GMT) Full text and rfc822 format available.Message #116 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 29 Dec 2022 21:11:28 -0500
On Thu, Dec 29, 2022 at 8:16 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote: > > On 12/29/22 16:03, Aaron Jensen wrote: > > Would it make sense to use block_atimers while loading native lisp? If > > Might, but it might make more sense not to be dynamically loading code > during an idle timer. Surely this could cause problems even in > non-native lisp. Anyway, I suggest consulting a macOS expert before > doing much experimenting; there's not enough evidence now for me to give > advice. I reported a bug and opened a discussion on the developer forum. We will see where that goes. I also added printfs on either side of native-elisp-load. When I got a crash, it was in a magit eln again and from what I can tell, every "start loading" had a matching "loaded" logged. I don't know that that definitely rules out the load interrupted theory or not. Furthermore, I've been able to crash it in a debugger. I don't know what to do there though, so I'm not sure how useful that is at this point. Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 03:56:02 GMT) Full text and rfc822 format available.Message #119 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 29 Dec 2022 22:54:50 -0500
On Thu, Dec 29, 2022 at 9:11 PM Aaron Jensen <aaronjensen <at> gmail.com> wrote:
>
> On Thu, Dec 29, 2022 at 8:16 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> >
> > On 12/29/22 16:03, Aaron Jensen wrote:
> > > Would it make sense to use block_atimers while loading native lisp? If
> >
> > Might, but it might make more sense not to be dynamically loading code
> > during an idle timer. Surely this could cause problems even in
> > non-native lisp. Anyway, I suggest consulting a macOS expert before
> > doing much experimenting; there's not enough evidence now for me to give
> > advice.
>
>
> I reported a bug and opened a discussion on the developer forum. We
> will see where that goes.
>
> I also added printfs on either side of native-elisp-load. When I got a
> crash, it was in a magit eln again and from what I can tell, every
> "start loading" had a matching "loaded" logged. I don't know that that
> definitely rules out the load interrupted theory or not.
>
> Furthermore, I've been able to crash it in a debugger. I don't know
> what to do there though, so I'm not sure how useful that is at this
> point.
>
> Aaron
I was able to reproduce it in an after-init hook (so no timers involved)
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Process: Emacs [33253]
Path: /opt/homebrew/*/Emacs.app/Contents/MacOS/Emacs
Identifier: org.gnu.Emacs
Version: Version 29.0.60 (9.0)
Code Type: ARM-64 (Native)
Parent Process: zsh [69115]
Responsible: iTerm2 [64164]
User ID: 501
Date/Time: 2022-12-29 22:51:06.9736 -0500
OS Version: macOS 13.1 (22C65)
Report Version: 12
Anonymous UUID: CD1F31D7-5E61-2935-643D-55F58CD29C12
Sleep/Wake UUID: F85FABBE-D01F-449A-BF1E-0176C31B6028
Time Awake Since Boot: 210000 seconds
Time Since Wake: 128 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 0x00000000000000f9
Exception Codes: 0x0000000000000001, 0x00000000000000f9
VM Region Info: 0xf9 is not in any region. Bytes before following
region: 105553518919431
REGION TYPE START - END [ VSIZE]
PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
MALLOC_NANO (reserved) 600018000000-600020000000 [128.0M]
rw-/rwx SM=NUL ...(unallocated)
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x1a6d621b0 __pthread_kill + 8
1 libsystem_pthread.dylib 0x1a6d98cec pthread_kill + 288
2 libsystem_c.dylib 0x1a6c9aa50 raise + 32
3 Emacs 0x100a31aec
terminate_due_to_signal + 204
4 Emacs 0x100a322f0 emacs_abort + 20
5 Emacs 0x100a00db0 ns_term_shutdown + 132
6 Emacs 0x1008ecb94 shut_down_emacs + 332
7 Emacs 0x100a31ab4
terminate_due_to_signal + 148
8 Emacs 0x10090f084 handle_fatal_signal + 16
9 Emacs 0x10090f100
deliver_thread_signal + 124
10 Emacs 0x10090d700
deliver_fatal_thread_signal + 12
11 Emacs 0x10090f160 handle_sigsegv + 96
12 libsystem_platform.dylib 0x1a6dc72a4 _sigtramp + 56
13 dyld 0x1a6a99380
lsl::BTree<lsl::Allocator::Buffer,
std::__1::less<lsl::Allocator::Buffer>,
false>::const_iterator::operator++() + 60
14 dyld 0x1a6a99d54
lsl::BTree<lsl::Allocator::Buffer,
std::__1::less<lsl::Allocator::Buffer>,
false>::erase(lsl::BTree<lsl::Allocator::Buffer,
std::__1::less<lsl::Allocator::Buffer>, false>::const_iterator) + 76
15 dyld 0x1a6a999fc
lsl::PersistentAllocator::reserveRange(lsl::BTree<lsl::Allocator::Buffer,
lsl::PersistentAllocator::RegionSizeCompare, false>::const_iterator&,
lsl::Allocator::Buffer) + 264
16 dyld 0x1a6a9a0b0
lsl::PersistentAllocator::allocate_buffer(unsigned long, unsigned
long, unsigned long, lsl::Allocator**) + 624
17 dyld 0x1a6a991e0
lsl::Allocator::aligned_alloc(unsigned long, unsigned long) + 180
18 dyld 0x1a6a99230
lsl::Allocator::strdup(char const*) + 48
19 dyld 0x1a6a968b8
dyld4::FileManager::fileRecordForPath(char const*) + 40
20 dyld 0x1a6ab4624
dyld4::Atlas::ProcessSnapshot::Serializer::readMappedFileInfo(std::__1::span<std::byte,
18446744073709551615ul>&, unsigned long long&, lsl::UUID&,
dyld4::FileRecord&) + 132
21 dyld 0x1a6ab3170
dyld4::Atlas::ProcessSnapshot::Serializer::deserialize(std::__1::span<std::byte,
18446744073709551615ul>) + 928
22 dyld 0x1a6ab2cec
dyld4::Atlas::ProcessSnapshot::ProcessSnapshot(lsl::Allocator&,
dyld4::FileManager&, bool, std::__1::span<std::byte,
18446744073709551615ul>) + 304
23 dyld 0x1a6a7ef64
lsl::UniquePtr<dyld4::Atlas::ProcessSnapshot>
lsl::Allocator::makeUnique<dyld4::Atlas::ProcessSnapshot,
lsl::EphemeralAllocator&, dyld4::FileManager&, bool,
std::__1::span<std::byte, 18446744073709551615ul>
const&>(lsl::EphemeralAllocator&, dyld4::FileManager&, bool&&,
std::__1::span<std::byte, 18446744073709551615ul> const&) + 80
24 dyld 0x1a6a7bafc
dyld4::RuntimeState::getCurrentProcessSnapshot() + 96
25 dyld 0x1a6a7b8cc
dyld4::RuntimeState::notifyDebuggerLoad(std::__1::span<dyld4::Loader
const*, 18446744073709551615ul> const&) + 72
26 dyld 0x1a6aaaf3c
dyld4::APIs::dlopen_from(char const*, int, void*)::$_0::operator()()
const + 748
27 dyld 0x1a6aa4968
dyld4::APIs::dlopen_from(char const*, int, void*) + 892
28 Emacs 0x1009b4db0 Fnative_elisp_load + 356
29 Emacs 0x10099088c Fload + 2104
30 Emacs 0x1009925f0 save_match_data_load + 92
31 Emacs 0x10096c928
load_with_autoload_queue + 120
32 Emacs 0x100978d84 Frequire + 560
33 Emacs 0x100968a30 eval_sub + 2236
34 Emacs 0x10096b158
internal_lisp_condition_case + 884
35 Emacs 0x10096889c eval_sub + 1832
36 Emacs 0x100968bac Fprogn + 48
37 Emacs 0x10096a3a8 Fwhile + 80
38 Emacs 0x10096889c eval_sub + 1832
39 Emacs 0x100968bac Fprogn + 48
40 Emacs 0x10096889c eval_sub + 1832
41 Emacs 0x10096889c eval_sub + 1832
42 Emacs 0x100968bac Fprogn + 48
43 Emacs 0x10096e10c funcall_lambda + 1316
44 Emacs 0x10096a724 Ffuncall + 316
45 Emacs 0x100968998 eval_sub + 2084
46 Emacs 0x100968bac Fprogn + 48
47 Emacs 0x10096a2b4 Flet + 840
48 Emacs 0x10096889c eval_sub + 1832
49 Emacs 0x100968bac Fprogn + 48
50 Emacs 0x10096e10c funcall_lambda + 1316
51 Emacs 0x10096a724 Ffuncall + 316
52 Emacs 0x100968998 eval_sub + 2084
53 Emacs 0x100968bac Fprogn + 48
54 Emacs 0x10096889c eval_sub + 1832
55 Emacs 0x10096b158
internal_lisp_condition_case + 884
56 Emacs 0x10096889c eval_sub + 1832
57 Emacs 0x100968bac Fprogn + 48
58 Emacs 0x10096e10c funcall_lambda + 1316
59 Emacs 0x10096a724 Ffuncall + 316
60 Emacs 0x10096d35c
run_hook_wrapped_funcall + 28
61 Emacs 0x10096d1f0 run_hook_with_args + 320
62 Emacs 0x100968998 eval_sub + 2084
63 Emacs 0x10096b158
internal_lisp_condition_case + 884
64 Emacs 0x10096889c eval_sub + 1832
65 Emacs 0x100968bac Fprogn + 48
66 Emacs 0x10096a2b4 Flet + 840
67 Emacs 0x10096889c eval_sub + 1832
68 Emacs 0x100968bac Fprogn + 48
69 Emacs 0x10096a3a8 Fwhile + 80
70 Emacs 0x10096889c eval_sub + 1832
71 Emacs 0x100968bac Fprogn + 48
72 Emacs 0x10096a2b4 Flet + 840
73 Emacs 0x10096889c eval_sub + 1832
74 Emacs 0x100968bac Fprogn + 48
75 Emacs 0x10096e10c funcall_lambda + 1316
76 Emacs 0x10096a724 Ffuncall + 316
77 Emacs 0x10096cf28 Fapply + 612
78 Emacs 0x1009ab940 exec_byte_code + 2988
79 Emacs 0x10096a724 Ffuncall + 316
80 startup-bbc6ea72-452f9f58.eln 0x104f8431c
F636f6d6d616e642d6c696e65_command_line_0 + 5452
81 Emacs 0x10096a724 Ffuncall + 316
82 startup-bbc6ea72-452f9f58.eln 0x104f80bb8
F6e6f726d616c2d746f702d6c6576656c_normal_top_level_0 + 3156
83 Emacs 0x100968918 eval_sub + 1956
84 Emacs 0x10096ca4c Feval + 88
85 Emacs 0x10096b32c
internal_condition_case + 96
86 Emacs 0x1009011c8 top_level_1 + 48
87 Emacs 0x10096ad50 internal_catch + 88
88 Emacs 0x100a31f08 command_loop.cold.1 + 64
89 Emacs 0x1008ef488 command_loop + 152
90 Emacs 0x1008ef344 recursive_edit_1 + 148
91 Emacs 0x1008ef5a8 Frecursive_edit + 264
92 Emacs 0x1008ee924 main + 7484
93 dyld 0x1a6a6fe50 start + 2544
Thread 1:
0 libsystem_pthread.dylib 0x1a6d93e18 start_wqthread + 0
Thread 2:
0 libsystem_pthread.dylib 0x1a6d93e18 start_wqthread + 0
Thread 3:: gmain
0 libsystem_kernel.dylib 0x1a6d64a00 __select + 8
1 libglib-2.0.0.dylib 0x10189b090 g_poll + 424
2 libglib-2.0.0.dylib 0x10188e234
g_main_context_iterate + 340
3 libglib-2.0.0.dylib 0x10188e2fc
g_main_context_iteration + 60
4 libglib-2.0.0.dylib 0x10188f694 glib_worker_main + 48
5 libglib-2.0.0.dylib 0x1018b2918 g_thread_proxy + 68
6 libsystem_pthread.dylib 0x1a6d9906c _pthread_start + 148
7 libsystem_pthread.dylib 0x1a6d93e2c thread_start + 8
Thread 4:
0 libsystem_pthread.dylib 0x1a6d93e18 start_wqthread + 0
Thread 5:
0 libsystem_pthread.dylib 0x1a6d93e18 start_wqthread + 0
Thread 6:
0 libsystem_kernel.dylib 0x1a6d5ffa4 __pselect + 8
1 libsystem_kernel.dylib 0x1a6d5fe7c pselect$DARWIN_EXTSN + 64
2 Emacs 0x100a01e90 -[EmacsApp
fd_handler:] + 184
3 Foundation 0x1a7d79470 __NSThread__start__ + 716
4 libsystem_pthread.dylib 0x1a6d9906c _pthread_start + 148
5 libsystem_pthread.dylib 0x1a6d93e2c thread_start + 8
Thread 7:: com.apple.NSEventThread
0 libsystem_kernel.dylib 0x1a6d59d70 mach_msg2_trap + 8
1 libsystem_kernel.dylib 0x1a6d6b8a4 mach_msg2_internal + 80
2 libsystem_kernel.dylib 0x1a6d625c4 mach_msg_overwrite + 540
3 libsystem_kernel.dylib 0x1a6d5a0ec mach_msg + 24
4 CoreFoundation 0x1a6e78bc0
__CFRunLoopServiceMachPort + 160
5 CoreFoundation 0x1a6e774ac __CFRunLoopRun + 1232
6 CoreFoundation 0x1a6e76888 CFRunLoopRunSpecific + 612
7 AppKit 0x1aa222410 _NSEventThread + 172
8 libsystem_pthread.dylib 0x1a6d9906c _pthread_start + 148
9 libsystem_pthread.dylib 0x1a6d93e2c thread_start + 8
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 04:25:02 GMT) Full text and rfc822 format available.Message #122 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 29 Dec 2022 23:24:37 -0500
And here is an init.el that reproduces it. It may take several
restarts, but it reproduces it for me:
(defun load-all ()
(mapc
(lambda (package)
(condition-case nil
(require package nil t)
(error nil)))
'(
electric
w32-fns
locate
shell
autoinsert
novice
dnd
mouse-drag
find-file
registry
skeleton
epg
plstore
mouse-copy
ecomplete
xt-mouse
tmm
abbrev
term
cus-edit
dired-x
man
kmacro
sort
subr
tabify
lpr
descr-text
tool-bar
epa-mail
nnspool
nnbabyl
mml2015
gnus-draft
nndiary
gnus-score
gnus-int
nndir
nngateway
gnus-registry
mml1991
nnweb
gssapi
gnus-msg
gnus-icalendar
mail-source
mm-decode
nnrss
mm-extern
gnus-async
nntp
nnmbox
nnvirtual
gnus-gravatar
gnus-sum
nnfolder
mml
nnregistry
mml-sec
mm-partial
nnoo
message
gnus-delay
gnus-kill
mm-archive
canlock
gnus-art
nnheader
gnus-agent
gnus
nnmairix
gnus-topic
gnus-rfc1843
gnus-group
spam
gnus-cus
gnus-bcklg
mm-util
gnus-uu
mm-url
gnus-search
gnus-notifications
spam-wash
nnmail
gnus-undo
score-mode
spam-stat
gnus-vm
nnmaildir
gnus-cache
gnus-html
gnus-salt
legacy-gnus-agent
gnus-win
nneething
nnimap
gnus-dbus
gnus-start
nnnil
spam-report
gnus-util
gnus-logic
nndoc
mm-bodies
gnus-mh
nndraft
mml-smime
gnus-diary
mm-view
nnselect
gnus-spec
gnus-ml
gnus-sieve
gnus-range
mm-uu
smiley
nnml
gnus-cite
gmm-utils
gnus-picon
mm-encode
nnmh
deuglify
gnus-eform
gnus-dup
gnus-fun
gnus-bookmark
smime
gnus-dired
gnus-cloud
gnus-rmail
gnus-srvr
nnagent
gnus-mlspl
gnus-demon
battery
foldout
echistory
pcmpl-rpm
font-core
sasl-scram-sha256
sieve
tramp-loaddefs
tramp-adb
tramp-container
eudc-capf
tramp-ftp
browse-url
eudcb-mab
tramp
ntlm
dbus
sieve-manage
tramp-integration
tramp-rclone
snmp-mode
eudc
nsm
sasl-cram
tramp-sh
sasl-ntlm
tramp-uu
eudc-vars
tramp-fuse
tramp-cmds
telnet
tramp-archive
newst-backend
dns
sasl-digest
eudcb-bbdb
webjump
hmac-md5
ldap
newst-treeview
eudc-export
eudcb-mailabbrev
mairix
newst-plainview
tramp-cache
dictionary
newsticker
ange-ftp
trampver
network-stream
mailcap
eudcb-ldap
tramp-smb
eww
sieve-mode
rcirc
tramp-compat
tramp-gvfs
imap
newst-reader
shr
soap-inspect
tramp-sshfs
dig
sasl
zeroconf
secrets
hmac-def
shr-color
puny
soap-client
tramp-sudoedit
pop3
goto-addr
rfc2104
tramp-crypt
newst-ticker
gnutls
eudc-bob
dictionary-connection
eudcb-macos-contacts
socks
net-utils
eudcb-ecomplete
eudc-hotlist
sasl-scram-rfc
keymap
info-look
strokes
cal-china
cal-french
diary-loaddefs
cal-julian
cal-hebrew
parse-time
diary-lib
time-date
holiday-loaddefs
cal-html
cal-bahai
cal-loaddefs
timeclock
cal-iso
cal-mayan
holidays
cal-tex
icalendar
cal-islam
cal-menu
iso8601
cal-move
lunar
cal-dst
cal-coptic
cal-x
appt
calendar
cal-persia
todo-mode
solar
tooltip
em-glob
em-script
esh-cmd
esh-module
em-prompt
eshell
em-alias
em-xtra
em-banner
esh-mode
esh-opt
em-tramp
em-smart
esh-proc
em-basic
em-dirs
em-hist
em-cmpl
em-pred
em-unix
esh-io
esh-groups
em-rebind
esh-var
em-extpipe
esh-ext
em-term
em-elecslash
esh-arg
em-ls
esh-util
htmlfontify
cdl
x-dnd
bind-key
use-package-bind-key
use-package-ensure
use-package-core
use-package-jump
use-package-delight
use-package-lint
use-package
use-package-diminish
use-package-ensure-system-package
ehelp
autorevert
sqlite
sqlite-mode
delsel
;; sup-mouse
iswitchb
vi
vc-mtn
pgg-gpg
eieio-compat
info-edit
pgg
vc-arch
tpu-extras
rcompile
nnir
linum
mh-compat
quickurl
cl
ws-mode
bruce
tpu-edt
otodo-mode
uce
landmark
starttls
vt-control
inversion
pgg-parse
html2text
netrc
cl-compat
terminal
tpu-mapper
mantemp
longlines
rfc2368
metamail
gulp
makesum
meese
pgg-pgp
url-dired
messcompat
eudcb-ph
vt100-led
autoload
url-ns
vip
ps-def
autoarg
tls
rlogin
pgg-def
pgg-pgp5
sb-image
thumbs
cc-compat
url-about
yow
gs
crisp
rect
ebuff-menu
subdirs
rot13
ibuf-ext
files-x
xml
help-mode
format
nxml-mode
rng-loc
nxml-rap
rng-xsd
xmltok
nxml-parse
rng-util
rng-pttrn
nxml-enc
rng-nxml
nxml-maint
rng-valid
rng-uri
rng-dt
nxml-ns
rng-parse
nxml-outln
rng-match
nxml-util
rng-maint
xsd-regexp
rng-cmpct
loaddefs
loadhist
reftex-dcr
reftex-auc
reftex-loaddefs
reftex-cite
paragraphs
flyspell
reftex-vars
underline
tildify
reftex-sel
two-column
page
reftex
texinfmt
yaml-ts-mode
texinfo-loaddefs
reftex-ref
texinfo
emacs-authors-mode
picture
fill
conf-mode
reftex-parse
less-css-mode
string-edit
dns-mode
bibtex
ispell
nroff-mode
refill
refbib
table
text-mode
sgml-mode
texnfo-upd
reftex-index
css-mode
enriched
emacs-news-mode
word-wrap-mode
glyphless-mode
makeinfo
remember
bibtex-style
toml-ts-mode
rst
refer
pixel-fill
artist
reftex-global
po
mhtml-mode
page-ext
tex-mode
reftex-toc
bib-mode
ansi-osc
files
misc
case-table
dynamic-setting
thingatpt
ox-publish
org-indent
ox-org
org-src
org-feed
org-crypt
ob-maxima
ob-emacs-lisp
org-attach-git
ob-lisp
org-keys
ox-ascii
org-cycle
ox-md
ob-lua
ob-java
ol-bibtex
oc-basic
org-footnote
ob-screen
ob-js
ox-koma-letter
org-habit
org-faces
ob-gnuplot
ob-lob
oc-biblatex
ob-forth
ob-org
org-timer
ob-makefile
ob-core
oc-natbib
ox
ob-matlab
ob-sass
ob-ruby
ob-R
org-goto
org-colview
org-capture
org
ol-irc
org-loaddefs
ol-bbdb
ox-man
org-macs
ob-sqlite
org-list
ob-awk
org-clock
org-plot
ol-man
ob-eshell
ob-perl
ob-sed
ol-w3m
org-archive
ob-julia
ob-latex
org-protocol
ox-odt
ol-rmail
ob-table
ol-info
ox-beamer
org-duration
org-pcomplete
ox-latex
ol-eshell
org-lint
ob-clojure
ob-lilypond
org-fold
ob-tangle
ob-ref
org-tempo
ob-ocaml
org-persist
org-agenda
ob-python
ob-calc
ob
org-element
org-compat
ob-css
oc
org-id
ob-haskell
ob-fortran
org-inlinetask
org-mouse
ol-gnus
oc-bibtex
ob-scheme
ob-ditaa
ob-exp
org-fold-core
ol-docview
ob-plantuml
ol
ox-html
org-table
ob-octave
oc-csl
ob-processing
org-mobile
ox-icalendar
ob-groovy
ob-eval
org-macro
org-datetree
ol-eww
ob-sql
ob-dot
org-entities
ob-C
org-attach
ob-shell
ol-mhe
org-num
org-version
org-refile
ol-doi
ox-texinfo
org-ctags
ob-comint
rtree
rfc2047
reporter
rmail-spam-filter
qp
mail-extr
rfc2231
yenc
mail-prsvr
mailalias
rfc6068
rmailmm
ietf-drums
rmail
ietf-drums-date
footnote
rfc822
rmailout
;; rmailkwd
;; supercite
;; blessmail
;; feedmail
;; mail-parse
;; mailheader
;; uudecode
;; undigest
;; unrmail
;; binhex
mail-utils
rfc2045
hashcash
rmailsort
emacsbug
flow-fill
smtpmail
mspools
rmailsum
rmailmsc
mailabbrev
mail-hist
sendmail
mailclient
rmailedit
startup
ansi-color
image-file
dabbrev
cua-base
viper-ex
viper-macs
edt-pc
cua-gmrk
keypad
viper-util
edt
edt-vt100
viper-keym
cua-rect
edt-mapper
edt-lk201
viper-mous
viper-init
tab-line
server
speedbar
find-dired
cus-dep
jka-cmpr-hook
format-spec
scroll-all
lk201
tmux
fbterm
common-win
haiku-win
st
tty-colors
x-win
vt200
internal
xterm
screen
sun
wyse50
ns-win
linux
pgtk-win
pc-win
bobcat
AT386
tvi970
rxvt
news
vt100
iris-ansi
cygwin
konsole
saveplace
image-mode
uniquify
face-remap
hilit-chg
finder
ibuf-macs))
(restart-emacs))
(add-hook 'after-init-hook #'load-all)
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 04:26:01 GMT) Full text and rfc822 format available.Message #125 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 29 Dec 2022 23:25:37 -0500
On Thu, Dec 29, 2022 at 11:24 PM Aaron Jensen <aaronjensen <at> gmail.com> wrote: > > And here is an init.el that reproduces it. It may take several > restarts, but it reproduces it for me: I should note that you'll need to comment out the restart-Emacs in order to let everything native compile if it hasn't already. Then you can add the restart back in. Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 07:42:02 GMT) Full text and rfc822 format available.Message #128 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Aaron Jensen <aaronjensen <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu> Cc: Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Fri, 30 Dec 2022 08:41:15 +0100
On 30.12.22 05:25, Aaron Jensen wrote: > On Thu, Dec 29, 2022 at 11:24 PM Aaron Jensen <aaronjensen <at> gmail.com> wrote: >> >> And here is an init.el that reproduces it. It may take several >> restarts, but it reproduces it for me: > > I should note that you'll need to comment out the restart-Emacs in > order to let everything native compile if it hasn't already. Then you > can add the restart back in. > > Aaron FWIW, I can't yet reproduce this. Tried ca. 10 times in a row, under LLDB.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 08:04:01 GMT) Full text and rfc822 format available.Message #131 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Fri, 30 Dec 2022 03:03:39 -0500
On Fri, Dec 30, 2022 at 2:41 AM Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote: > > On 30.12.22 05:25, Aaron Jensen wrote: > > On Thu, Dec 29, 2022 at 11:24 PM Aaron Jensen <aaronjensen <at> gmail.com> wrote: > >> > >> And here is an init.el that reproduces it. It may take several > >> restarts, but it reproduces it for me: > > > > I should note that you'll need to comment out the restart-Emacs in > > order to let everything native compile if it hasn't already. Then you > > can add the restart back in. > > > > Aaron > > FWIW, I can't yet reproduce this. Tried ca. 10 times in a row, under LLDB. What version of macOS are you using?
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 08:30:02 GMT) Full text and rfc822 format available.Message #134 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: gerd.moellmann <at> gmail.com, 60220 <at> debbugs.gnu.org, aaronjensen <at> gmail.com Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Fri, 30 Dec 2022 10:29:25 +0200
> Date: Thu, 29 Dec 2022 15:49:55 -0800 > Cc: gerd.moellmann <at> gmail.com, 60220 <at> debbugs.gnu.org > From: Paul Eggert <eggert <at> cs.ucla.edu> > > On 12/29/22 15:46, Aaron Jensen wrote: > > have something that eagerly > > loads packages on an idle timer (it caches what was loaded when Emacs > > is quit). > > Could it by that the dynamic linker is being invoked recursively? That > is, while something is being dynamically linked, a SIGALRM or equivalent > arrives, some idle timer code is run, and the dynamic linker is invoked > before the outer linker finishes? I imagine that might put some dynamic > linkers into a tizzy. The timers of the kind that we see in the crash backtraces don't run off SIGALRM, they run as part of the main loop.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 08:33:01 GMT) Full text and rfc822 format available.Message #137 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Aaron Jensen <aaronjensen <at> gmail.com>, Andrea Corallo <akrl <at> sdf.org> Cc: gerd.moellmann <at> gmail.com, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Fri, 30 Dec 2022 10:32:22 +0200
> From: Aaron Jensen <aaronjensen <at> gmail.com> > Date: Thu, 29 Dec 2022 19:03:47 -0500 > Cc: Eli Zaretskii <eliz <at> gnu.org>, gerd.moellmann <at> gmail.com, 60220 <at> debbugs.gnu.org > > > > Could it by that the dynamic linker is being invoked recursively? That > > > is, while something is being dynamically linked, a SIGALRM or equivalent > > > arrives, some idle timer code is run, and the dynamic linker is invoked > > > before the outer linker finishes? I imagine that might put some dynamic > > > linkers into a tizzy. > > > > > > I have no idea, would we see that in the trace at all? Here are two > > more crashes: https://gist.github.com/aaronjensen/f7c46857ea93c858f46a639d8880f290 > > > > I have been able to reproduce it just now pretty easily, but I still > > can't reproduce it with the debugger attached. > > Would it make sense to use block_atimers while loading native lisp? If > that's a workable thing and you can send me a patch I can try it out. Andrea, can you suggest a patch along these lines for Aaron to try? Thanks.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 08:38:01 GMT) Full text and rfc822 format available.Message #140 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: gerd.moellmann <at> gmail.com, 60220 <at> debbugs.gnu.org, aaronjensen <at> gmail.com Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Fri, 30 Dec 2022 10:37:05 +0200
> Date: Thu, 29 Dec 2022 17:16:18 -0800 > Cc: Eli Zaretskii <eliz <at> gnu.org>, gerd.moellmann <at> gmail.com, > 60220 <at> debbugs.gnu.org > From: Paul Eggert <eggert <at> cs.ucla.edu> > > On 12/29/22 16:03, Aaron Jensen wrote: > > Would it make sense to use block_atimers while loading native lisp? If > > Might, but it might make more sense not to be dynamically loading code > during an idle timer. This is a limitation we don't want, as it is too severe. How can we prevent loading when idle timers can run any Lisp, and an arbitrary Lisp program can always call some autoloaded function? And I don't understand why we'd want to have such a restriction, since idle timers run from the main loop, thus in safe context. It would be a gratuitous restriction that will only draw (justified) complaints. Can you explain why you think loading shared libraries from an Emacs idle timer could be dangerous? I don't think I understand that.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 08:43:02 GMT) Full text and rfc822 format available.Message #143 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Aaron Jensen <aaronjensen <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Fri, 30 Dec 2022 09:42:09 +0100
13.1 on an M1. Sent from my iPhone > On 30. Dec 2022, at 09:03, Aaron Jensen <aaronjensen <at> gmail.com> wrote: > > On Fri, Dec 30, 2022 at 2:41 AM Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote: >> >>> On 30.12.22 05:25, Aaron Jensen wrote: >>> On Thu, Dec 29, 2022 at 11:24 PM Aaron Jensen <aaronjensen <at> gmail.com> wrote: >>>> >>>> And here is an init.el that reproduces it. It may take several >>>> restarts, but it reproduces it for me: >>> >>> I should note that you'll need to comment out the restart-Emacs in >>> order to let everything native compile if it hasn't already. Then you >>> can add the restart back in. >>> >>> Aaron >> >> FWIW, I can't yet reproduce this. Tried ca. 10 times in a row, under LLDB. > > What version of macOS are you using?
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 13:37:02 GMT) Full text and rfc822 format available.Message #146 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: gerd.moellmann <at> gmail.com, Paul Eggert <eggert <at> cs.ucla.edu>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Fri, 30 Dec 2022 08:36:25 -0500
On Fri, Dec 30, 2022 at 3:37 AM Eli Zaretskii <eliz <at> gnu.org> wrote: > > > Date: Thu, 29 Dec 2022 17:16:18 -0800 > > Cc: Eli Zaretskii <eliz <at> gnu.org>, gerd.moellmann <at> gmail.com, > > 60220 <at> debbugs.gnu.org > > From: Paul Eggert <eggert <at> cs.ucla.edu> > > > > On 12/29/22 16:03, Aaron Jensen wrote: > > > Would it make sense to use block_atimers while loading native lisp? If > > > > Might, but it might make more sense not to be dynamically loading code > > during an idle timer. > > This is a limitation we don't want, as it is too severe. How can we > prevent loading when idle timers can run any Lisp, and an arbitrary > Lisp program can always call some autoloaded function? > > And I don't understand why we'd want to have such a restriction, since > idle timers run from the main loop, thus in safe context. It would be > a gratuitous restriction that will only draw (justified) complaints. > > Can you explain why you think loading shared libraries from an Emacs > idle timer could be dangerous? I don't think I understand that. I've already disproven this. I can reproduce a crash with just an after-init hook loading several features. Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 13:38:01 GMT) Full text and rfc822 format available.Message #149 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Fri, 30 Dec 2022 08:37:18 -0500
On Fri, Dec 30, 2022 at 3:42 AM Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote: > > 13.1 on an M1. Ok, same. Did you allow everything to native compile before starting the restart loop?
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 13:53:02 GMT) Full text and rfc822 format available.Message #152 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Fri, 30 Dec 2022 08:52:33 -0500
On Fri, Dec 30, 2022 at 8:37 AM Aaron Jensen <aaronjensen <at> gmail.com> wrote: > > On Fri, Dec 30, 2022 at 3:42 AM Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote: > > > > 13.1 on an M1. > > Ok, same. Did you allow everything to native compile before starting > the restart loop? Also, please try to run it outside of LLDB and see if it crashes there.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 14:19:01 GMT) Full text and rfc822 format available.Message #155 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Aaron Jensen <aaronjensen <at> gmail.com> Cc: gerd.moellmann <at> gmail.com, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Fri, 30 Dec 2022 16:18:51 +0200
> From: Aaron Jensen <aaronjensen <at> gmail.com> > Date: Fri, 30 Dec 2022 08:36:25 -0500 > Cc: Paul Eggert <eggert <at> cs.ucla.edu>, gerd.moellmann <at> gmail.com, 60220 <at> debbugs.gnu.org > > > Can you explain why you think loading shared libraries from an Emacs > > idle timer could be dangerous? I don't think I understand that. > > I've already disproven this. I can reproduce a crash with just an > after-init hook loading several features. I've seen that, but since we don't have a reasonable explanation for the crashes, I don't think your reproduction is evidence that Paul's fears, whatever they are, are necessarily incorrect. The mere fact that you can trigger the crash in a different scenario doesn't yet mean the original scenario has nothing to do with the problem. This kind of conclusions can only be drawn once the reason is fully understood, and we are not there yet.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 14:25:02 GMT) Full text and rfc822 format available.Message #158 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Fri, 30 Dec 2022 09:24:00 -0500
On Fri, Dec 30, 2022 at 8:52 AM Aaron Jensen <aaronjensen <at> gmail.com> wrote: > > On Fri, Dec 30, 2022 at 8:37 AM Aaron Jensen <aaronjensen <at> gmail.com> wrote: > > > > On Fri, Dec 30, 2022 at 3:42 AM Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote: > > > > > > 13.1 on an M1. > > > > Ok, same. Did you allow everything to native compile before starting > > the restart loop? > > Also, please try to run it outside of LLDB and see if it crashes there. FWIW, with CFLAGS="-g -O0" CXXFLAGS="-g -O0" and running in XCode it seems to reproduce pretty easily for me. Only took a couple restarts. https://share.cleanshot.com/PK2djHVv On Fri, Dec 30, 2022 at 9:18 AM Eli Zaretskii <eliz <at> gnu.org> wrote: > > I've seen that, but since we don't have a reasonable explanation for > the crashes, I don't think your reproduction is evidence that Paul's > fears, whatever they are, are necessarily incorrect. The mere fact > that you can trigger the crash in a different scenario doesn't yet > mean the original scenario has nothing to do with the problem. This > kind of conclusions can only be drawn once the reason is fully > understood, and we are not there yet. Understood, thank you. I should not jump so quickly to conclusions.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 15:28:01 GMT) Full text and rfc822 format available.Message #161 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Aaron Jensen <aaronjensen <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Fri, 30 Dec 2022 16:27:00 +0100
On 30.12.22 14:52, Aaron Jensen wrote:
> On Fri, Dec 30, 2022 at 8:37 AM Aaron Jensen <aaronjensen <at> gmail.com> wrote:
>>
>> On Fri, Dec 30, 2022 at 3:42 AM Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>>>
>>> 13.1 on an M1.
>>
>> Ok, same. Did you allow everything to native compile before starting
>> the restart loop?
>
> Also, please try to run it outside of LLDB and see if it crashes there.
It seem to depend on "-g -O0" plus running in LLDB.
With "-g -O0" and without LLDB, the first restart terminates with
~/tmp/ > HOME=. ~/emacs/master/src/emacs
dyld[4467]: Assertion failed: (this->magic == kMagic), function
contains, file Loader.cpp, line 144.
With LLDB, it stops like this between restarts
* thread #21, stop reason = exec
frame #0: 0x0000000100b50950 dyld`_dyld_start
but happily chips on after each "continue" in LLDB.
I don't see at the moment how to proceed with this. Maybe it's worth
trying to use a helper process for restarting Emacs, as you described
elsewhere if I remember that right.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 15:52:01 GMT) Full text and rfc822 format available.Message #164 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Fri, 30 Dec 2022 10:50:42 -0500
On Fri, Dec 30, 2022 at 10:27 AM Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote: > > On 30.12.22 14:52, Aaron Jensen wrote: > > On Fri, Dec 30, 2022 at 8:37 AM Aaron Jensen <aaronjensen <at> gmail.com> wrote: > >> > >> On Fri, Dec 30, 2022 at 3:42 AM Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote: > >>> > >>> 13.1 on an M1. > >> > >> Ok, same. Did you allow everything to native compile before starting > >> the restart loop? > > > > Also, please try to run it outside of LLDB and see if it crashes there. > > It seem to depend on "-g -O0" plus running in LLDB. > > With "-g -O0" and without LLDB, the first restart terminates with > > ~/tmp/ > HOME=. ~/emacs/master/src/emacs > dyld[4467]: Assertion failed: (this->magic == kMagic), function > contains, file Loader.cpp, line 144. Yes, this is what I see. The Apple error reporter shows me the full stack trace I've submitted. I'm glad I'm not the only one. For me, it does not depend on "-g -O0", but that does appear to make it more likely. > With LLDB, it stops like this between restarts > > * thread #21, stop reason = exec > frame #0: 0x0000000100b50950 dyld`_dyld_start > > but happily chips on after each "continue" in LLDB. I'm guessing the exec breakpoint is expected and not problematic. Xcode doesn't do this, and I can make LLDB crash, it just takes a few times for me. > I don't see at the moment how to proceed with this. Maybe it's worth > trying to use a helper process for restarting Emacs, as you described > elsewhere if I remember that right. I don't think this is necessary since I've seen what appears to be the same crash on a fresh start (without restarting). I don't know how to proceed either. Without any additional evidence, the only thing I can guess is that we are hitting the same thing that Xojo is: https://www.mbs-plugins.de/archive/2022-12-28/Avoiding_macOS_Ventura_crashes/monkeybreadsoftware_blog_xojo Their current plan is to wait and see if Apple fixes it, but 13.2 beta doesn't appear to have fixed it yet, so it may be a while. In the interim, I'm just sending every crash report to Apple and starting Emacs anew whenever it crashes (which thankfully under normal use isn't all that often). Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Fri, 30 Dec 2022 22:43:01 GMT) Full text and rfc822 format available.Message #167 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: gerd.moellmann <at> gmail.com, 60220 <at> debbugs.gnu.org, aaronjensen <at> gmail.com Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Fri, 30 Dec 2022 14:42:50 -0800
On 12/30/22 00:37, Eli Zaretskii wrote: > Can you explain why you think loading shared libraries from an Emacs > idle timer could be dangerous? No, sorry, I was mistaken in my analysis.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Sat, 31 Dec 2022 06:34:02 GMT) Full text and rfc822 format available.Message #170 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: gerd.moellmann <at> gmail.com, 60220 <at> debbugs.gnu.org, aaronjensen <at> gmail.com Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Sat, 31 Dec 2022 08:33:28 +0200
> Date: Fri, 30 Dec 2022 14:42:50 -0800 > Cc: aaronjensen <at> gmail.com, gerd.moellmann <at> gmail.com, 60220 <at> debbugs.gnu.org > From: Paul Eggert <eggert <at> cs.ucla.edu> > > On 12/30/22 00:37, Eli Zaretskii wrote: > > Can you explain why you think loading shared libraries from an Emacs > > idle timer could be dangerous? > > No, sorry, I was mistaken in my analysis. OK, thanks. It's good to know we have one problem less to investigate and solve.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Wed, 04 Jan 2023 15:52:01 GMT) Full text and rfc822 format available.Message #173 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Andrea Corallo <akrl <at> sdf.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: gerd.moellmann <at> gmail.com, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org, Aaron Jensen <aaronjensen <at> gmail.com> Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Wed, 04 Jan 2023 15:51:17 +0000
Eli Zaretskii <eliz <at> gnu.org> writes: >> From: Aaron Jensen <aaronjensen <at> gmail.com> >> Date: Thu, 29 Dec 2022 19:03:47 -0500 >> Cc: Eli Zaretskii <eliz <at> gnu.org>, gerd.moellmann <at> gmail.com, 60220 <at> debbugs.gnu.org >> >> > > Could it by that the dynamic linker is being invoked recursively? That >> > > is, while something is being dynamically linked, a SIGALRM or equivalent >> > > arrives, some idle timer code is run, and the dynamic linker is invoked >> > > before the outer linker finishes? I imagine that might put some dynamic >> > > linkers into a tizzy. >> > >> > >> > I have no idea, would we see that in the trace at all? Here are two >> > more crashes: https://gist.github.com/aaronjensen/f7c46857ea93c858f46a639d8880f290 >> > >> > I have been able to reproduce it just now pretty easily, but I still >> > can't reproduce it with the debugger attached. >> >> Would it make sense to use block_atimers while loading native lisp? If >> that's a workable thing and you can send me a patch I can try it out. > > Andrea, can you suggest a patch along these lines for Aaron to try? > > Thanks. Hi Eli, sorry I'm traveling with sporadic access to the PC till next week. If the issue is still present I'll work on it next week. Best Regards Andrea
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Wed, 04 Jan 2023 16:59:02 GMT) Full text and rfc822 format available.Message #176 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Andrea Corallo <akrl <at> sdf.org> Cc: gerd.moellmann <at> gmail.com, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org, aaronjensen <at> gmail.com Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Wed, 04 Jan 2023 18:58:50 +0200
> From: Andrea Corallo <akrl <at> sdf.org> > Cc: Aaron Jensen <aaronjensen <at> gmail.com>, gerd.moellmann <at> gmail.com, > eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org > Date: Wed, 04 Jan 2023 15:51:17 +0000 > > Eli Zaretskii <eliz <at> gnu.org> writes: > > >> Would it make sense to use block_atimers while loading native lisp? If > >> that's a workable thing and you can send me a patch I can try it out. > > > > Andrea, can you suggest a patch along these lines for Aaron to try? > > > > Thanks. > > Hi Eli, > > sorry I'm traveling with sporadic access to the PC till next week. If > the issue is still present I'll work on it next week. Thanks in advance.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Tue, 10 Jan 2023 15:29:02 GMT) Full text and rfc822 format available.Message #179 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Andrea Corallo <akrl <at> sdf.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: gerd.moellmann <at> gmail.com, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org, aaronjensen <at> gmail.com Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Tue, 10 Jan 2023 15:28:48 +0000
Eli Zaretskii <eliz <at> gnu.org> writes: >> From: Andrea Corallo <akrl <at> sdf.org> >> Cc: Aaron Jensen <aaronjensen <at> gmail.com>, gerd.moellmann <at> gmail.com, >> eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org >> Date: Wed, 04 Jan 2023 15:51:17 +0000 >> >> Eli Zaretskii <eliz <at> gnu.org> writes: >> >> >> Would it make sense to use block_atimers while loading native lisp? If >> >> that's a workable thing and you can send me a patch I can try it out. >> > >> > Andrea, can you suggest a patch along these lines for Aaron to try? >> > >> > Thanks. >> >> Hi Eli, >> >> sorry I'm traveling with sporadic access to the PC till next week. If >> the issue is still present I'll work on it next week. > > Thanks in advance. Hi all, I pushed a change that should block atimers during native code loads, it's in 'scratch/native-timers-blocked'. I haven't tested it deeply but seems to work for me. If anyone likes to test it or play with it is there. BR Andrea
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Tue, 10 Jan 2023 16:57:02 GMT) Full text and rfc822 format available.Message #182 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Andrea Corallo <akrl <at> sdf.org> Cc: gerd.moellmann <at> gmail.com, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org, aaronjensen <at> gmail.com Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Tue, 10 Jan 2023 18:57:10 +0200
> From: Andrea Corallo <akrl <at> sdf.org> > Cc: aaronjensen <at> gmail.com, gerd.moellmann <at> gmail.com, eggert <at> cs.ucla.edu, > 60220 <at> debbugs.gnu.org > Date: Tue, 10 Jan 2023 15:28:48 +0000 > > Eli Zaretskii <eliz <at> gnu.org> writes: > > >> From: Andrea Corallo <akrl <at> sdf.org> > >> Cc: Aaron Jensen <aaronjensen <at> gmail.com>, gerd.moellmann <at> gmail.com, > >> eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org > >> Date: Wed, 04 Jan 2023 15:51:17 +0000 > >> > >> Eli Zaretskii <eliz <at> gnu.org> writes: > >> > >> >> Would it make sense to use block_atimers while loading native lisp? If > >> >> that's a workable thing and you can send me a patch I can try it out. > >> > > >> > Andrea, can you suggest a patch along these lines for Aaron to try? > >> > > >> > Thanks. > >> > >> Hi Eli, > >> > >> sorry I'm traveling with sporadic access to the PC till next week. If > >> the issue is still present I'll work on it next week. > > > > Thanks in advance. > > Hi all, > > I pushed a change that should block atimers during native code loads, > it's in 'scratch/native-timers-blocked'. > > I haven't tested it deeply but seems to work for me. If anyone likes to > test it or play with it is there. Thanks.
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Tue, 10 Jan 2023 23:01:02 GMT) Full text and rfc822 format available.Message #185 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Andrea Corallo <akrl <at> sdf.org> Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Tue, 10 Jan 2023 17:59:59 -0500
On Tue, Jan 10, 2023 at 10:28 AM Andrea Corallo <akrl <at> sdf.org> wrote: > > Eli Zaretskii <eliz <at> gnu.org> writes: > > >> From: Andrea Corallo <akrl <at> sdf.org> > >> Cc: Aaron Jensen <aaronjensen <at> gmail.com>, gerd.moellmann <at> gmail.com, > >> eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org > >> Date: Wed, 04 Jan 2023 15:51:17 +0000 > >> > >> Eli Zaretskii <eliz <at> gnu.org> writes: > >> > >> >> Would it make sense to use block_atimers while loading native lisp? If > >> >> that's a workable thing and you can send me a patch I can try it out. > >> > > >> > Andrea, can you suggest a patch along these lines for Aaron to try? > >> > > >> > Thanks. > >> > >> Hi Eli, > >> > >> sorry I'm traveling with sporadic access to the PC till next week. If > >> the issue is still present I'll work on it next week. > > > > Thanks in advance. > > Hi all, > > I pushed a change that should block atimers during native code loads, > it's in 'scratch/native-timers-blocked'. > > I haven't tested it deeply but seems to work for me. If anyone likes to > test it or play with it is there. > > BR > > Andrea Unfortunately, it still crashes for me with my repro (without restarting, I just opened Emacs and it crashed). Thanks, Aaron
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Thu, 12 Jan 2023 11:02:01 GMT) Full text and rfc822 format available.Message #188 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Andrea Corallo <akrl <at> sdf.org> To: Aaron Jensen <aaronjensen <at> gmail.com> Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Thu, 12 Jan 2023 11:01:43 +0000
Aaron Jensen <aaronjensen <at> gmail.com> writes: > On Tue, Jan 10, 2023 at 10:28 AM Andrea Corallo <akrl <at> sdf.org> wrote: >> >> Eli Zaretskii <eliz <at> gnu.org> writes: >> >> >> From: Andrea Corallo <akrl <at> sdf.org> >> >> Cc: Aaron Jensen <aaronjensen <at> gmail.com>, gerd.moellmann <at> gmail.com, >> >> eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org >> >> Date: Wed, 04 Jan 2023 15:51:17 +0000 >> >> >> >> Eli Zaretskii <eliz <at> gnu.org> writes: >> >> >> >> >> Would it make sense to use block_atimers while loading native lisp? If >> >> >> that's a workable thing and you can send me a patch I can try it out. >> >> > >> >> > Andrea, can you suggest a patch along these lines for Aaron to try? >> >> > >> >> > Thanks. >> >> >> >> Hi Eli, >> >> >> >> sorry I'm traveling with sporadic access to the PC till next week. If >> >> the issue is still present I'll work on it next week. >> > >> > Thanks in advance. >> >> Hi all, >> >> I pushed a change that should block atimers during native code loads, >> it's in 'scratch/native-timers-blocked'. >> >> I haven't tested it deeply but seems to work for me. If anyone likes to >> test it or play with it is there. >> >> BR >> >> Andrea > > Unfortunately, it still crashes for me with my repro (without > restarting, I just opened Emacs and it crashed). Mhhh :/ , the only advice I have would be to two a printf in 'block_atimers' and 'unblock_atimers', just to be 100% that when when we crash we did our job of blocking the timers. Andrea
bug-gnu-emacs <at> gnu.org:bug#60220; Package emacs.
(Sat, 14 Jan 2023 16:24:01 GMT) Full text and rfc822 format available.Message #191 received at 60220 <at> debbugs.gnu.org (full text, mbox):
From: Aaron Jensen <aaronjensen <at> gmail.com> To: Andrea Corallo <akrl <at> sdf.org> Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org Subject: Re: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Sat, 14 Jan 2023 11:23:14 -0500
On Thu, Jan 12, 2023 at 6:01 AM Andrea Corallo <akrl <at> sdf.org> wrote: > > Aaron Jensen <aaronjensen <at> gmail.com> writes: > > > On Tue, Jan 10, 2023 at 10:28 AM Andrea Corallo <akrl <at> sdf.org> wrote: > >> > >> Eli Zaretskii <eliz <at> gnu.org> writes: > >> > >> >> From: Andrea Corallo <akrl <at> sdf.org> > >> >> Cc: Aaron Jensen <aaronjensen <at> gmail.com>, gerd.moellmann <at> gmail.com, > >> >> eggert <at> cs.ucla.edu, 60220 <at> debbugs.gnu.org > >> >> Date: Wed, 04 Jan 2023 15:51:17 +0000 > >> >> > >> >> Eli Zaretskii <eliz <at> gnu.org> writes: > >> >> > >> >> >> Would it make sense to use block_atimers while loading native lisp? If > >> >> >> that's a workable thing and you can send me a patch I can try it out. > >> >> > > >> >> > Andrea, can you suggest a patch along these lines for Aaron to try? > >> >> > > >> >> > Thanks. > >> >> > >> >> Hi Eli, > >> >> > >> >> sorry I'm traveling with sporadic access to the PC till next week. If > >> >> the issue is still present I'll work on it next week. > >> > > >> > Thanks in advance. > >> > >> Hi all, > >> > >> I pushed a change that should block atimers during native code loads, > >> it's in 'scratch/native-timers-blocked'. > >> > >> I haven't tested it deeply but seems to work for me. If anyone likes to > >> test it or play with it is there. > >> > >> BR > >> > >> Andrea > > > > Unfortunately, it still crashes for me with my repro (without > > restarting, I just opened Emacs and it crashed). > > Mhhh :/ , the only advice I have would be to two a printf in > 'block_atimers' and 'unblock_atimers', just to be 100% that when when we > crash we did our job of blocking the timers. Looks like it was blocked at the time of the crash: ... UNBLOCK BLOCK dyld[33354]: Assertion failed: (this->magic == kMagic), function contains, file Loader.cpp, line 144. Thanks, Aaron
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.