all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
@ 2022-12-20 15:11 Aaron Jensen
  2022-12-20 15:25 ` Aaron Jensen
  2022-12-20 15:32 ` Eli Zaretskii
  0 siblings, 2 replies; 63+ messages in thread
From: Aaron Jensen @ 2022-12-20 15:11 UTC (permalink / raw)
  To: 60220


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@29/29.0.60/share/info/emacs
 --prefix=/opt/homebrew/Cellar/emacs-plus@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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))





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-20 15:11 bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Aaron Jensen
@ 2022-12-20 15:25 ` Aaron Jensen
  2022-12-20 15:41   ` Eli Zaretskii
  2022-12-20 15:32 ` Eli Zaretskii
  1 sibling, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2022-12-20 15:25 UTC (permalink / raw)
  To: 60220

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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-20 15:11 bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Aaron Jensen
  2022-12-20 15:25 ` Aaron Jensen
@ 2022-12-20 15:32 ` Eli Zaretskii
  2022-12-20 15:36   ` Aaron Jensen
  1 sibling, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2022-12-20 15:32 UTC (permalink / raw)
  To: Aaron Jensen; +Cc: 60220

> From: Aaron Jensen <aaronjensen@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-20 15:32 ` Eli Zaretskii
@ 2022-12-20 15:36   ` Aaron Jensen
  0 siblings, 0 replies; 63+ messages in thread
From: Aaron Jensen @ 2022-12-20 15:36 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 60220

On Tue, Dec 20, 2022 at 10:31 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-20 15:25 ` Aaron Jensen
@ 2022-12-20 15:41   ` Eli Zaretskii
  2022-12-20 15:59     ` Aaron Jensen
  0 siblings, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2022-12-20 15:41 UTC (permalink / raw)
  To: Aaron Jensen; +Cc: 60220

> From: Aaron Jensen <aaronjensen@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?





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-20 15:41   ` Eli Zaretskii
@ 2022-12-20 15:59     ` Aaron Jensen
  2022-12-20 17:23       ` Eli Zaretskii
  0 siblings, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2022-12-20 15:59 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 60220

On Tue, Dec 20, 2022 at 10:40 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-20 15:59     ` Aaron Jensen
@ 2022-12-20 17:23       ` Eli Zaretskii
  2022-12-21  3:47         ` Aaron Jensen
  0 siblings, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2022-12-20 17:23 UTC (permalink / raw)
  To: Aaron Jensen; +Cc: 60220

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Tue, 20 Dec 2022 10:59:20 -0500
> Cc: 60220@debbugs.gnu.org
> 
> On Tue, Dec 20, 2022 at 10:40 AM Eli Zaretskii <eliz@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-20 17:23       ` Eli Zaretskii
@ 2022-12-21  3:47         ` Aaron Jensen
  2022-12-21 12:22           ` Eli Zaretskii
  0 siblings, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2022-12-21  3:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 60220

On Tue, Dec 20, 2022 at 12:22 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Tue, 20 Dec 2022 10:59:20 -0500
> > Cc: 60220@debbugs.gnu.org
> >
> > On Tue, Dec 20, 2022 at 10:40 AM Eli Zaretskii <eliz@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-21  3:47         ` Aaron Jensen
@ 2022-12-21 12:22           ` Eli Zaretskii
  2022-12-21 13:29             ` Gerd Möllmann
  0 siblings, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2022-12-21 12:22 UTC (permalink / raw)
  To: Aaron Jensen, Gerd Möllmann; +Cc: 60220

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Tue, 20 Dec 2022 22:47:46 -0500
> Cc: 60220@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-21 12:22           ` Eli Zaretskii
@ 2022-12-21 13:29             ` Gerd Möllmann
  2022-12-22  5:09               ` Aaron Jensen
  0 siblings, 1 reply; 63+ messages in thread
From: Gerd Möllmann @ 2022-12-21 13:29 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 60220, Aaron Jensen

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@gnu.org> wrote:
> 
> 
>> 
>> From: Aaron Jensen <aaronjensen@gmail.com>
>> Date: Tue, 20 Dec 2022 22:47:46 -0500
>> Cc: 60220@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-21 13:29             ` Gerd Möllmann
@ 2022-12-22  5:09               ` Aaron Jensen
  2022-12-22  5:12                 ` Aaron Jensen
  0 siblings, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2022-12-22  5:09 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: Eli Zaretskii, 60220

On Wed, Dec 21, 2022 at 8:29 AM Gerd Möllmann <gerd.moellmann@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-22  5:09               ` Aaron Jensen
@ 2022-12-22  5:12                 ` Aaron Jensen
  2022-12-22  5:36                   ` Gerd Möllmann
  2022-12-22  8:05                   ` Eli Zaretskii
  0 siblings, 2 replies; 63+ messages in thread
From: Aaron Jensen @ 2022-12-22  5:12 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: Eli Zaretskii, 60220

On Thu, Dec 22, 2022 at 12:09 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Wed, Dec 21, 2022 at 8:29 AM Gerd Möllmann <gerd.moellmann@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-22  5:12                 ` Aaron Jensen
@ 2022-12-22  5:36                   ` Gerd Möllmann
  2022-12-22  8:18                     ` Eli Zaretskii
  2022-12-22  8:05                   ` Eli Zaretskii
  1 sibling, 1 reply; 63+ messages in thread
From: Gerd Möllmann @ 2022-12-22  5:36 UTC (permalink / raw)
  To: Aaron Jensen; +Cc: Eli Zaretskii, 60220

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@gmail.com> wrote:
> 
> On Thu, Dec 22, 2022 at 12:09 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
>> 
>>> On Wed, Dec 21, 2022 at 8:29 AM Gerd Möllmann <gerd.moellmann@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-22  5:12                 ` Aaron Jensen
  2022-12-22  5:36                   ` Gerd Möllmann
@ 2022-12-22  8:05                   ` Eli Zaretskii
  1 sibling, 0 replies; 63+ messages in thread
From: Eli Zaretskii @ 2022-12-22  8:05 UTC (permalink / raw)
  To: Aaron Jensen; +Cc: gerd.moellmann, 60220

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Thu, 22 Dec 2022 00:12:35 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, 60220@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-22  5:36                   ` Gerd Möllmann
@ 2022-12-22  8:18                     ` Eli Zaretskii
  2022-12-23  2:05                       ` Paul Eggert
  0 siblings, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2022-12-22  8:18 UTC (permalink / raw)
  To: Gerd Möllmann, Paul Eggert; +Cc: 60220, aaronjensen

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Thu, 22 Dec 2022 06:36:43 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, 60220@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-22  8:18                     ` Eli Zaretskii
@ 2022-12-23  2:05                       ` Paul Eggert
  2022-12-23  2:22                         ` Aaron Jensen
  0 siblings, 1 reply; 63+ messages in thread
From: Paul Eggert @ 2022-12-23  2:05 UTC (permalink / raw)
  To: Eli Zaretskii, Gerd Möllmann; +Cc: 60220, aaronjensen

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

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?

[-- Attachment #2: 0001-Fix-restart-emacs-alarms-Bug-60220.patch --]
[-- Type: text/x-patch, Size: 824 bytes --]

From 175a4a27dcb17a80d9e8e82344ad3bef47822350 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 22 Dec 2022 18:01:08 -0800
Subject: [PATCH] Fix restart-emacs alarms (Bug#60220).
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/emacs.c (Fkill_emacs): Turn timers off before execing,
so that the re-execed Emacs doesn’t get a timer alarm.
---
 src/emacs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/emacs.c b/src/emacs.c
index d8a2863fd9..a2ba4b50f0 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -2910,6 +2910,7 @@ DEFUN ("kill-emacs", Fkill_emacs, Skill_emacs, 0, 2, "P",
 
   if (!NILP (restart))
     {
+      turn_on_atimers (false);
 #ifdef WINDOWSNT
       if (w32_reexec_emacs (initial_cmdline, initial_wd) < 0)
 #else
-- 
2.38.1


^ permalink raw reply related	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-23  2:05                       ` Paul Eggert
@ 2022-12-23  2:22                         ` Aaron Jensen
  2022-12-23  5:33                           ` Gerd Möllmann
  2022-12-23  5:56                           ` Paul Eggert
  0 siblings, 2 replies; 63+ messages in thread
From: Aaron Jensen @ 2022-12-23  2:22 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Gerd Möllmann, Eli Zaretskii, 60220

On Thu, Dec 22, 2022 at 9:06 PM Paul Eggert <eggert@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)





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-23  2:22                         ` Aaron Jensen
@ 2022-12-23  5:33                           ` Gerd Möllmann
  2022-12-23  5:56                           ` Paul Eggert
  1 sibling, 0 replies; 63+ messages in thread
From: Gerd Möllmann @ 2022-12-23  5:33 UTC (permalink / raw)
  To: Aaron Jensen; +Cc: Eli Zaretskii, Paul Eggert, 60220

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@gmail.com> wrote:
> 
> On Thu, Dec 22, 2022 at 9:06 PM Paul Eggert <eggert@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)





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-23  2:22                         ` Aaron Jensen
  2022-12-23  5:33                           ` Gerd Möllmann
@ 2022-12-23  5:56                           ` Paul Eggert
  2022-12-24  6:45                             ` Aaron Jensen
  2022-12-24 15:11                             ` Aaron Jensen
  1 sibling, 2 replies; 63+ messages in thread
From: Paul Eggert @ 2022-12-23  5:56 UTC (permalink / raw)
  To: Aaron Jensen; +Cc: Gerd Möllmann, Eli Zaretskii, 60220

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?






^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-23  5:56                           ` Paul Eggert
@ 2022-12-24  6:45                             ` Aaron Jensen
  2022-12-24  6:57                               ` Eli Zaretskii
  2022-12-24 15:11                             ` Aaron Jensen
  1 sibling, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2022-12-24  6:45 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Gerd Möllmann, Eli Zaretskii, 60220

On Fri, Dec 23, 2022 at 12:56 AM Paul Eggert <eggert@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-24  6:45                             ` Aaron Jensen
@ 2022-12-24  6:57                               ` Eli Zaretskii
  2022-12-24  7:03                                 ` Aaron Jensen
  2022-12-24  8:25                                 ` Paul Eggert
  0 siblings, 2 replies; 63+ messages in thread
From: Eli Zaretskii @ 2022-12-24  6:57 UTC (permalink / raw)
  To: Aaron Jensen; +Cc: gerd.moellmann, eggert, 60220

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 24 Dec 2022 01:45:51 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, Gerd Möllmann <gerd.moellmann@gmail.com>, 
> 	60220@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-24  6:57                               ` Eli Zaretskii
@ 2022-12-24  7:03                                 ` Aaron Jensen
  2022-12-24  8:25                                 ` Paul Eggert
  1 sibling, 0 replies; 63+ messages in thread
From: Aaron Jensen @ 2022-12-24  7:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gerd.moellmann, eggert, 60220

On Sat, Dec 24, 2022 at 1:57 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Sat, 24 Dec 2022 01:45:51 -0500
> > Cc: Eli Zaretskii <eliz@gnu.org>, Gerd Möllmann <gerd.moellmann@gmail.com>,
> >       60220@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-24  6:57                               ` Eli Zaretskii
  2022-12-24  7:03                                 ` Aaron Jensen
@ 2022-12-24  8:25                                 ` Paul Eggert
  1 sibling, 0 replies; 63+ messages in thread
From: Paul Eggert @ 2022-12-24  8:25 UTC (permalink / raw)
  To: Eli Zaretskii, Aaron Jensen; +Cc: gerd.moellmann, 60220

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.






^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-23  5:56                           ` Paul Eggert
  2022-12-24  6:45                             ` Aaron Jensen
@ 2022-12-24 15:11                             ` Aaron Jensen
  2022-12-25  5:30                               ` Gerd Möllmann
  1 sibling, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2022-12-24 15:11 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Gerd Möllmann, Eli Zaretskii, 60220

On Fri, Dec 23, 2022 at 12:56 AM Paul Eggert <eggert@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-24 15:11                             ` Aaron Jensen
@ 2022-12-25  5:30                               ` Gerd Möllmann
  2022-12-25 19:30                                 ` Aaron Jensen
  0 siblings, 1 reply; 63+ messages in thread
From: Gerd Möllmann @ 2022-12-25  5:30 UTC (permalink / raw)
  To: Aaron Jensen; +Cc: Eli Zaretskii, Paul Eggert, 60220

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@gmail.com> wrote:
> 
> On Fri, Dec 23, 2022 at 12:56 AM Paul Eggert <eggert@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-25  5:30                               ` Gerd Möllmann
@ 2022-12-25 19:30                                 ` Aaron Jensen
  2022-12-25 19:59                                   ` Eli Zaretskii
  0 siblings, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2022-12-25 19:30 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: Eli Zaretskii, Paul Eggert, 60220

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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-25 19:30                                 ` Aaron Jensen
@ 2022-12-25 19:59                                   ` Eli Zaretskii
  2022-12-27 11:12                                     ` Aaron Jensen
  0 siblings, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2022-12-25 19:59 UTC (permalink / raw)
  To: Aaron Jensen; +Cc: gerd.moellmann, eggert, 60220

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sun, 25 Dec 2022 14:30:14 -0500
> Cc: Paul Eggert <eggert@cs.ucla.edu>, Eli Zaretskii <eliz@gnu.org>, 60220@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-25 19:59                                   ` Eli Zaretskii
@ 2022-12-27 11:12                                     ` Aaron Jensen
  2022-12-27 13:11                                       ` Eli Zaretskii
  0 siblings, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2022-12-27 11:12 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gerd.moellmann, eggert, 60220

On Sun, Dec 25, 2022 at 2:59 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Sun, 25 Dec 2022 14:30:14 -0500
> > Cc: Paul Eggert <eggert@cs.ucla.edu>, Eli Zaretskii <eliz@gnu.org>, 60220@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-27 11:12                                     ` Aaron Jensen
@ 2022-12-27 13:11                                       ` Eli Zaretskii
  2022-12-29 22:47                                         ` Aaron Jensen
  0 siblings, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2022-12-27 13:11 UTC (permalink / raw)
  To: Aaron Jensen; +Cc: gerd.moellmann, eggert, 60220

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Tue, 27 Dec 2022 06:12:35 -0500
> Cc: gerd.moellmann@gmail.com, eggert@cs.ucla.edu, 60220@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-27 13:11                                       ` Eli Zaretskii
@ 2022-12-29 22:47                                         ` Aaron Jensen
  2022-12-29 23:46                                           ` Aaron Jensen
  0 siblings, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2022-12-29 22:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gerd.moellmann, eggert, 60220

On Tue, Dec 27, 2022 at 8:11 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Tue, 27 Dec 2022 06:12:35 -0500
> > Cc: gerd.moellmann@gmail.com, eggert@cs.ucla.edu, 60220@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-29 22:47                                         ` Aaron Jensen
@ 2022-12-29 23:46                                           ` Aaron Jensen
  2022-12-29 23:49                                             ` Paul Eggert
  0 siblings, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2022-12-29 23:46 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gerd.moellmann, eggert, 60220

On Thu, Dec 29, 2022 at 5:47 PM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Tue, Dec 27, 2022 at 8:11 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Aaron Jensen <aaronjensen@gmail.com>
> > > Date: Tue, 27 Dec 2022 06:12:35 -0500
> > > Cc: gerd.moellmann@gmail.com, eggert@cs.ucla.edu, 60220@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-29 23:46                                           ` Aaron Jensen
@ 2022-12-29 23:49                                             ` Paul Eggert
  2022-12-29 23:59                                               ` Aaron Jensen
  2022-12-30  8:29                                               ` Eli Zaretskii
  0 siblings, 2 replies; 63+ messages in thread
From: Paul Eggert @ 2022-12-29 23:49 UTC (permalink / raw)
  To: Aaron Jensen, Eli Zaretskii; +Cc: gerd.moellmann, 60220

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.






^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-29 23:49                                             ` Paul Eggert
@ 2022-12-29 23:59                                               ` Aaron Jensen
  2022-12-30  0:03                                                 ` Aaron Jensen
  2022-12-30  0:08                                                 ` Paul Eggert
  2022-12-30  8:29                                               ` Eli Zaretskii
  1 sibling, 2 replies; 63+ messages in thread
From: Aaron Jensen @ 2022-12-29 23:59 UTC (permalink / raw)
  To: Paul Eggert; +Cc: gerd.moellmann, Eli Zaretskii, 60220

On Thu, Dec 29, 2022 at 6:49 PM Paul Eggert <eggert@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-29 23:59                                               ` Aaron Jensen
@ 2022-12-30  0:03                                                 ` Aaron Jensen
  2022-12-30  1:16                                                   ` Paul Eggert
  2022-12-30  8:32                                                   ` Eli Zaretskii
  2022-12-30  0:08                                                 ` Paul Eggert
  1 sibling, 2 replies; 63+ messages in thread
From: Aaron Jensen @ 2022-12-30  0:03 UTC (permalink / raw)
  To: Paul Eggert; +Cc: gerd.moellmann, Eli Zaretskii, 60220

On Thu, Dec 29, 2022 at 6:59 PM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Thu, Dec 29, 2022 at 6:49 PM Paul Eggert <eggert@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-29 23:59                                               ` Aaron Jensen
  2022-12-30  0:03                                                 ` Aaron Jensen
@ 2022-12-30  0:08                                                 ` Paul Eggert
  1 sibling, 0 replies; 63+ messages in thread
From: Paul Eggert @ 2022-12-30  0:08 UTC (permalink / raw)
  To: Aaron Jensen; +Cc: gerd.moellmann, Eli Zaretskii, 60220

On 12/29/22 15:59, Aaron Jensen wrote:
> On Thu, Dec 29, 2022 at 6:49 PM Paul Eggert <eggert@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).






^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30  0:03                                                 ` Aaron Jensen
@ 2022-12-30  1:16                                                   ` Paul Eggert
  2022-12-30  1:20                                                     ` Aaron Jensen
                                                                       ` (2 more replies)
  2022-12-30  8:32                                                   ` Eli Zaretskii
  1 sibling, 3 replies; 63+ messages in thread
From: Paul Eggert @ 2022-12-30  1:16 UTC (permalink / raw)
  To: Aaron Jensen; +Cc: gerd.moellmann, Eli Zaretskii, 60220

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.






^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30  1:16                                                   ` Paul Eggert
@ 2022-12-30  1:20                                                     ` Aaron Jensen
  2022-12-30  2:11                                                     ` Aaron Jensen
  2022-12-30  8:37                                                     ` Eli Zaretskii
  2 siblings, 0 replies; 63+ messages in thread
From: Aaron Jensen @ 2022-12-30  1:20 UTC (permalink / raw)
  To: Paul Eggert; +Cc: gerd.moellmann, Eli Zaretskii, 60220

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

 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@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.
>

[-- Attachment #2: Type: text/html, Size: 1593 bytes --]

^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30  1:16                                                   ` Paul Eggert
  2022-12-30  1:20                                                     ` Aaron Jensen
@ 2022-12-30  2:11                                                     ` Aaron Jensen
  2022-12-30  3:54                                                       ` Aaron Jensen
  2022-12-30  8:37                                                     ` Eli Zaretskii
  2 siblings, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2022-12-30  2:11 UTC (permalink / raw)
  To: Paul Eggert; +Cc: gerd.moellmann, Eli Zaretskii, 60220

On Thu, Dec 29, 2022 at 8:16 PM Paul Eggert <eggert@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30  2:11                                                     ` Aaron Jensen
@ 2022-12-30  3:54                                                       ` Aaron Jensen
  2022-12-30  4:24                                                         ` Aaron Jensen
  0 siblings, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2022-12-30  3:54 UTC (permalink / raw)
  To: Paul Eggert; +Cc: gerd.moellmann, Eli Zaretskii, 60220

On Thu, Dec 29, 2022 at 9:11 PM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Thu, Dec 29, 2022 at 8:16 PM Paul Eggert <eggert@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30  3:54                                                       ` Aaron Jensen
@ 2022-12-30  4:24                                                         ` Aaron Jensen
  2022-12-30  4:25                                                           ` Aaron Jensen
  0 siblings, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2022-12-30  4:24 UTC (permalink / raw)
  To: Paul Eggert; +Cc: gerd.moellmann, Eli Zaretskii, 60220

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)





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30  4:24                                                         ` Aaron Jensen
@ 2022-12-30  4:25                                                           ` Aaron Jensen
  2022-12-30  7:41                                                             ` Gerd Möllmann
  0 siblings, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2022-12-30  4:25 UTC (permalink / raw)
  To: Paul Eggert; +Cc: gerd.moellmann, Eli Zaretskii, 60220

On Thu, Dec 29, 2022 at 11:24 PM Aaron Jensen <aaronjensen@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30  4:25                                                           ` Aaron Jensen
@ 2022-12-30  7:41                                                             ` Gerd Möllmann
  2022-12-30  8:03                                                               ` Aaron Jensen
  0 siblings, 1 reply; 63+ messages in thread
From: Gerd Möllmann @ 2022-12-30  7:41 UTC (permalink / raw)
  To: Aaron Jensen, Paul Eggert; +Cc: Eli Zaretskii, 60220

On 30.12.22 05:25, Aaron Jensen wrote:
> On Thu, Dec 29, 2022 at 11:24 PM Aaron Jensen <aaronjensen@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30  7:41                                                             ` Gerd Möllmann
@ 2022-12-30  8:03                                                               ` Aaron Jensen
  2022-12-30  8:42                                                                 ` Gerd Möllmann
  0 siblings, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2022-12-30  8:03 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: Eli Zaretskii, Paul Eggert, 60220

On Fri, Dec 30, 2022 at 2:41 AM Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>
> On 30.12.22 05:25, Aaron Jensen wrote:
> > On Thu, Dec 29, 2022 at 11:24 PM Aaron Jensen <aaronjensen@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?





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-29 23:49                                             ` Paul Eggert
  2022-12-29 23:59                                               ` Aaron Jensen
@ 2022-12-30  8:29                                               ` Eli Zaretskii
  1 sibling, 0 replies; 63+ messages in thread
From: Eli Zaretskii @ 2022-12-30  8:29 UTC (permalink / raw)
  To: Paul Eggert; +Cc: gerd.moellmann, 60220, aaronjensen

> Date: Thu, 29 Dec 2022 15:49:55 -0800
> Cc: gerd.moellmann@gmail.com, 60220@debbugs.gnu.org
> From: Paul Eggert <eggert@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30  0:03                                                 ` Aaron Jensen
  2022-12-30  1:16                                                   ` Paul Eggert
@ 2022-12-30  8:32                                                   ` Eli Zaretskii
  2023-01-04 15:51                                                     ` Andrea Corallo
  1 sibling, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2022-12-30  8:32 UTC (permalink / raw)
  To: Aaron Jensen, Andrea Corallo; +Cc: gerd.moellmann, eggert, 60220

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Thu, 29 Dec 2022 19:03:47 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, gerd.moellmann@gmail.com, 60220@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30  1:16                                                   ` Paul Eggert
  2022-12-30  1:20                                                     ` Aaron Jensen
  2022-12-30  2:11                                                     ` Aaron Jensen
@ 2022-12-30  8:37                                                     ` Eli Zaretskii
  2022-12-30 13:36                                                       ` Aaron Jensen
  2022-12-30 22:42                                                       ` Paul Eggert
  2 siblings, 2 replies; 63+ messages in thread
From: Eli Zaretskii @ 2022-12-30  8:37 UTC (permalink / raw)
  To: Paul Eggert; +Cc: gerd.moellmann, 60220, aaronjensen

> Date: Thu, 29 Dec 2022 17:16:18 -0800
> Cc: Eli Zaretskii <eliz@gnu.org>, gerd.moellmann@gmail.com,
>  60220@debbugs.gnu.org
> From: Paul Eggert <eggert@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30  8:03                                                               ` Aaron Jensen
@ 2022-12-30  8:42                                                                 ` Gerd Möllmann
  2022-12-30 13:37                                                                   ` Aaron Jensen
  0 siblings, 1 reply; 63+ messages in thread
From: Gerd Möllmann @ 2022-12-30  8:42 UTC (permalink / raw)
  To: Aaron Jensen; +Cc: Eli Zaretskii, Paul Eggert, 60220

13.1 on an M1. 

Sent from my iPhone

> On 30. Dec 2022, at 09:03, Aaron Jensen <aaronjensen@gmail.com> wrote:
> 
> On Fri, Dec 30, 2022 at 2:41 AM Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>> 
>>> On 30.12.22 05:25, Aaron Jensen wrote:
>>> On Thu, Dec 29, 2022 at 11:24 PM Aaron Jensen <aaronjensen@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?





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30  8:37                                                     ` Eli Zaretskii
@ 2022-12-30 13:36                                                       ` Aaron Jensen
  2022-12-30 14:18                                                         ` Eli Zaretskii
  2022-12-30 22:42                                                       ` Paul Eggert
  1 sibling, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2022-12-30 13:36 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gerd.moellmann, Paul Eggert, 60220

On Fri, Dec 30, 2022 at 3:37 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Date: Thu, 29 Dec 2022 17:16:18 -0800
> > Cc: Eli Zaretskii <eliz@gnu.org>, gerd.moellmann@gmail.com,
> >  60220@debbugs.gnu.org
> > From: Paul Eggert <eggert@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30  8:42                                                                 ` Gerd Möllmann
@ 2022-12-30 13:37                                                                   ` Aaron Jensen
  2022-12-30 13:52                                                                     ` Aaron Jensen
  0 siblings, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2022-12-30 13:37 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: Eli Zaretskii, Paul Eggert, 60220

On Fri, Dec 30, 2022 at 3:42 AM Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>
> 13.1 on an M1.

Ok, same. Did you allow everything to native compile before starting
the restart loop?





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30 13:37                                                                   ` Aaron Jensen
@ 2022-12-30 13:52                                                                     ` Aaron Jensen
  2022-12-30 14:24                                                                       ` Aaron Jensen
  2022-12-30 15:27                                                                       ` Gerd Möllmann
  0 siblings, 2 replies; 63+ messages in thread
From: Aaron Jensen @ 2022-12-30 13:52 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: Eli Zaretskii, Paul Eggert, 60220

On Fri, Dec 30, 2022 at 8:37 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Fri, Dec 30, 2022 at 3:42 AM Gerd Möllmann <gerd.moellmann@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30 13:36                                                       ` Aaron Jensen
@ 2022-12-30 14:18                                                         ` Eli Zaretskii
  0 siblings, 0 replies; 63+ messages in thread
From: Eli Zaretskii @ 2022-12-30 14:18 UTC (permalink / raw)
  To: Aaron Jensen; +Cc: gerd.moellmann, eggert, 60220

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Fri, 30 Dec 2022 08:36:25 -0500
> Cc: Paul Eggert <eggert@cs.ucla.edu>, gerd.moellmann@gmail.com, 60220@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30 13:52                                                                     ` Aaron Jensen
@ 2022-12-30 14:24                                                                       ` Aaron Jensen
  2022-12-30 15:27                                                                       ` Gerd Möllmann
  1 sibling, 0 replies; 63+ messages in thread
From: Aaron Jensen @ 2022-12-30 14:24 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: Eli Zaretskii, Paul Eggert, 60220

On Fri, Dec 30, 2022 at 8:52 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Fri, Dec 30, 2022 at 8:37 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
> >
> > On Fri, Dec 30, 2022 at 3:42 AM Gerd Möllmann <gerd.moellmann@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@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30 13:52                                                                     ` Aaron Jensen
  2022-12-30 14:24                                                                       ` Aaron Jensen
@ 2022-12-30 15:27                                                                       ` Gerd Möllmann
  2022-12-30 15:50                                                                         ` Aaron Jensen
  1 sibling, 1 reply; 63+ messages in thread
From: Gerd Möllmann @ 2022-12-30 15:27 UTC (permalink / raw)
  To: Aaron Jensen; +Cc: Eli Zaretskii, Paul Eggert, 60220

On 30.12.22 14:52, Aaron Jensen wrote:
> On Fri, Dec 30, 2022 at 8:37 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
>>
>> On Fri, Dec 30, 2022 at 3:42 AM Gerd Möllmann <gerd.moellmann@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30 15:27                                                                       ` Gerd Möllmann
@ 2022-12-30 15:50                                                                         ` Aaron Jensen
  0 siblings, 0 replies; 63+ messages in thread
From: Aaron Jensen @ 2022-12-30 15:50 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: Eli Zaretskii, Paul Eggert, 60220

On Fri, Dec 30, 2022 at 10:27 AM Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>
> On 30.12.22 14:52, Aaron Jensen wrote:
> > On Fri, Dec 30, 2022 at 8:37 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
> >>
> >> On Fri, Dec 30, 2022 at 3:42 AM Gerd Möllmann <gerd.moellmann@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30  8:37                                                     ` Eli Zaretskii
  2022-12-30 13:36                                                       ` Aaron Jensen
@ 2022-12-30 22:42                                                       ` Paul Eggert
  2022-12-31  6:33                                                         ` Eli Zaretskii
  1 sibling, 1 reply; 63+ messages in thread
From: Paul Eggert @ 2022-12-30 22:42 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gerd.moellmann, 60220, aaronjensen

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.






^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30 22:42                                                       ` Paul Eggert
@ 2022-12-31  6:33                                                         ` Eli Zaretskii
  0 siblings, 0 replies; 63+ messages in thread
From: Eli Zaretskii @ 2022-12-31  6:33 UTC (permalink / raw)
  To: Paul Eggert; +Cc: gerd.moellmann, 60220, aaronjensen

> Date: Fri, 30 Dec 2022 14:42:50 -0800
> Cc: aaronjensen@gmail.com, gerd.moellmann@gmail.com, 60220@debbugs.gnu.org
> From: Paul Eggert <eggert@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2022-12-30  8:32                                                   ` Eli Zaretskii
@ 2023-01-04 15:51                                                     ` Andrea Corallo
  2023-01-04 16:58                                                       ` Eli Zaretskii
  0 siblings, 1 reply; 63+ messages in thread
From: Andrea Corallo @ 2023-01-04 15:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gerd.moellmann, eggert, 60220, Aaron Jensen

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Aaron Jensen <aaronjensen@gmail.com>
>> Date: Thu, 29 Dec 2022 19:03:47 -0500
>> Cc: Eli Zaretskii <eliz@gnu.org>, gerd.moellmann@gmail.com, 60220@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2023-01-04 15:51                                                     ` Andrea Corallo
@ 2023-01-04 16:58                                                       ` Eli Zaretskii
  2023-01-10 15:28                                                         ` Andrea Corallo
  0 siblings, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2023-01-04 16:58 UTC (permalink / raw)
  To: Andrea Corallo; +Cc: gerd.moellmann, eggert, 60220, aaronjensen

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Aaron Jensen <aaronjensen@gmail.com>, gerd.moellmann@gmail.com,
>         eggert@cs.ucla.edu, 60220@debbugs.gnu.org
> Date: Wed, 04 Jan 2023 15:51:17 +0000
> 
> Eli Zaretskii <eliz@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2023-01-04 16:58                                                       ` Eli Zaretskii
@ 2023-01-10 15:28                                                         ` Andrea Corallo
  2023-01-10 16:57                                                           ` Eli Zaretskii
  2023-01-10 22:59                                                           ` Aaron Jensen
  0 siblings, 2 replies; 63+ messages in thread
From: Andrea Corallo @ 2023-01-10 15:28 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gerd.moellmann, eggert, 60220, aaronjensen

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: Aaron Jensen <aaronjensen@gmail.com>, gerd.moellmann@gmail.com,
>>         eggert@cs.ucla.edu, 60220@debbugs.gnu.org
>> Date: Wed, 04 Jan 2023 15:51:17 +0000
>> 
>> Eli Zaretskii <eliz@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2023-01-10 15:28                                                         ` Andrea Corallo
@ 2023-01-10 16:57                                                           ` Eli Zaretskii
  2023-01-10 22:59                                                           ` Aaron Jensen
  1 sibling, 0 replies; 63+ messages in thread
From: Eli Zaretskii @ 2023-01-10 16:57 UTC (permalink / raw)
  To: Andrea Corallo; +Cc: gerd.moellmann, eggert, 60220, aaronjensen

> From: Andrea Corallo <akrl@sdf.org>
> Cc: aaronjensen@gmail.com, gerd.moellmann@gmail.com, eggert@cs.ucla.edu,
>         60220@debbugs.gnu.org
> Date: Tue, 10 Jan 2023 15:28:48 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andrea Corallo <akrl@sdf.org>
> >> Cc: Aaron Jensen <aaronjensen@gmail.com>, gerd.moellmann@gmail.com,
> >>         eggert@cs.ucla.edu, 60220@debbugs.gnu.org
> >> Date: Wed, 04 Jan 2023 15:51:17 +0000
> >> 
> >> Eli Zaretskii <eliz@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.





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2023-01-10 15:28                                                         ` Andrea Corallo
  2023-01-10 16:57                                                           ` Eli Zaretskii
@ 2023-01-10 22:59                                                           ` Aaron Jensen
  2023-01-12 11:01                                                             ` Andrea Corallo
  1 sibling, 1 reply; 63+ messages in thread
From: Aaron Jensen @ 2023-01-10 22:59 UTC (permalink / raw)
  To: Andrea Corallo; +Cc: gerd.moellmann, Eli Zaretskii, eggert, 60220

On Tue, Jan 10, 2023 at 10:28 AM Andrea Corallo <akrl@sdf.org> wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Andrea Corallo <akrl@sdf.org>
> >> Cc: Aaron Jensen <aaronjensen@gmail.com>, gerd.moellmann@gmail.com,
> >>         eggert@cs.ucla.edu, 60220@debbugs.gnu.org
> >> Date: Wed, 04 Jan 2023 15:51:17 +0000
> >>
> >> Eli Zaretskii <eliz@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2023-01-10 22:59                                                           ` Aaron Jensen
@ 2023-01-12 11:01                                                             ` Andrea Corallo
  2023-01-14 16:23                                                               ` Aaron Jensen
  0 siblings, 1 reply; 63+ messages in thread
From: Andrea Corallo @ 2023-01-12 11:01 UTC (permalink / raw)
  To: Aaron Jensen; +Cc: gerd.moellmann, Eli Zaretskii, eggert, 60220

Aaron Jensen <aaronjensen@gmail.com> writes:

> On Tue, Jan 10, 2023 at 10:28 AM Andrea Corallo <akrl@sdf.org> wrote:
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Andrea Corallo <akrl@sdf.org>
>> >> Cc: Aaron Jensen <aaronjensen@gmail.com>, gerd.moellmann@gmail.com,
>> >>         eggert@cs.ucla.edu, 60220@debbugs.gnu.org
>> >> Date: Wed, 04 Jan 2023 15:51:17 +0000
>> >>
>> >> Eli Zaretskii <eliz@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

* bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
  2023-01-12 11:01                                                             ` Andrea Corallo
@ 2023-01-14 16:23                                                               ` Aaron Jensen
  0 siblings, 0 replies; 63+ messages in thread
From: Aaron Jensen @ 2023-01-14 16:23 UTC (permalink / raw)
  To: Andrea Corallo; +Cc: gerd.moellmann, Eli Zaretskii, eggert, 60220

On Thu, Jan 12, 2023 at 6:01 AM Andrea Corallo <akrl@sdf.org> wrote:
>
> Aaron Jensen <aaronjensen@gmail.com> writes:
>
> > On Tue, Jan 10, 2023 at 10:28 AM Andrea Corallo <akrl@sdf.org> wrote:
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> >> From: Andrea Corallo <akrl@sdf.org>
> >> >> Cc: Aaron Jensen <aaronjensen@gmail.com>, gerd.moellmann@gmail.com,
> >> >>         eggert@cs.ucla.edu, 60220@debbugs.gnu.org
> >> >> Date: Wed, 04 Jan 2023 15:51:17 +0000
> >> >>
> >> >> Eli Zaretskii <eliz@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





^ permalink raw reply	[flat|nested] 63+ messages in thread

end of thread, other threads:[~2023-01-14 16:23 UTC | newest]

Thread overview: 63+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-12-20 15:11 bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Aaron Jensen
2022-12-20 15:25 ` Aaron Jensen
2022-12-20 15:41   ` Eli Zaretskii
2022-12-20 15:59     ` Aaron Jensen
2022-12-20 17:23       ` Eli Zaretskii
2022-12-21  3:47         ` Aaron Jensen
2022-12-21 12:22           ` Eli Zaretskii
2022-12-21 13:29             ` Gerd Möllmann
2022-12-22  5:09               ` Aaron Jensen
2022-12-22  5:12                 ` Aaron Jensen
2022-12-22  5:36                   ` Gerd Möllmann
2022-12-22  8:18                     ` Eli Zaretskii
2022-12-23  2:05                       ` Paul Eggert
2022-12-23  2:22                         ` Aaron Jensen
2022-12-23  5:33                           ` Gerd Möllmann
2022-12-23  5:56                           ` Paul Eggert
2022-12-24  6:45                             ` Aaron Jensen
2022-12-24  6:57                               ` Eli Zaretskii
2022-12-24  7:03                                 ` Aaron Jensen
2022-12-24  8:25                                 ` Paul Eggert
2022-12-24 15:11                             ` Aaron Jensen
2022-12-25  5:30                               ` Gerd Möllmann
2022-12-25 19:30                                 ` Aaron Jensen
2022-12-25 19:59                                   ` Eli Zaretskii
2022-12-27 11:12                                     ` Aaron Jensen
2022-12-27 13:11                                       ` Eli Zaretskii
2022-12-29 22:47                                         ` Aaron Jensen
2022-12-29 23:46                                           ` Aaron Jensen
2022-12-29 23:49                                             ` Paul Eggert
2022-12-29 23:59                                               ` Aaron Jensen
2022-12-30  0:03                                                 ` Aaron Jensen
2022-12-30  1:16                                                   ` Paul Eggert
2022-12-30  1:20                                                     ` Aaron Jensen
2022-12-30  2:11                                                     ` Aaron Jensen
2022-12-30  3:54                                                       ` Aaron Jensen
2022-12-30  4:24                                                         ` Aaron Jensen
2022-12-30  4:25                                                           ` Aaron Jensen
2022-12-30  7:41                                                             ` Gerd Möllmann
2022-12-30  8:03                                                               ` Aaron Jensen
2022-12-30  8:42                                                                 ` Gerd Möllmann
2022-12-30 13:37                                                                   ` Aaron Jensen
2022-12-30 13:52                                                                     ` Aaron Jensen
2022-12-30 14:24                                                                       ` Aaron Jensen
2022-12-30 15:27                                                                       ` Gerd Möllmann
2022-12-30 15:50                                                                         ` Aaron Jensen
2022-12-30  8:37                                                     ` Eli Zaretskii
2022-12-30 13:36                                                       ` Aaron Jensen
2022-12-30 14:18                                                         ` Eli Zaretskii
2022-12-30 22:42                                                       ` Paul Eggert
2022-12-31  6:33                                                         ` Eli Zaretskii
2022-12-30  8:32                                                   ` Eli Zaretskii
2023-01-04 15:51                                                     ` Andrea Corallo
2023-01-04 16:58                                                       ` Eli Zaretskii
2023-01-10 15:28                                                         ` Andrea Corallo
2023-01-10 16:57                                                           ` Eli Zaretskii
2023-01-10 22:59                                                           ` Aaron Jensen
2023-01-12 11:01                                                             ` Andrea Corallo
2023-01-14 16:23                                                               ` Aaron Jensen
2022-12-30  0:08                                                 ` Paul Eggert
2022-12-30  8:29                                               ` Eli Zaretskii
2022-12-22  8:05                   ` Eli Zaretskii
2022-12-20 15:32 ` Eli Zaretskii
2022-12-20 15:36   ` Aaron Jensen

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.