I tried doing the outlets for all the controls, then making a nsview in the method for a button that declares a view, then I set initwithframe to be sent to a variable typed 'id' and accessing that variable I was able to add nsbuttoncell to the variable, then I added the subview to the. main tableview here's the code I used: NSView *viewptr = [[NSView alloc]init]; NSButtonCell *bCell1 = [[NSButtonCell alloc]init]; NSRect rect; [bCell1 setTitle:@"click"]; rect.size.width = 2; rect.size.height = 1; id temp,x; temp = [viewptr initWithFrame:rect]; [temp addObject:bCell1]; [_cocoa_test_scrollview addSubview:temp]; is there anything im missing? the app keeps crashing and spiting out debug messages, like: -[NSView addObject:]: unrecognized selector sent to instance 0x12ee0ae60 ( 0 CoreFoundation 0x0000000186efaccc __exceptionPreprocess + 176 1 libobjc.A.dylib 0x00000001869e2788 objc_exception_throw + 60 2 CoreFoundation 0x0000000186fad02c -[NSObject(NSObject) __retain_OA] + 0 3 CoreFoundation 0x0000000186e64cdc forwarding + 1580 4 CoreFoundation 0x0000000186e645f0 _CF_forwarding_prep_0 + 96 5 objc_cocoa_test_image_3 0x0000000100608ca4 -[AppDelegate cocoa_test_button1_add:] + 264 6 AppKit 0x000000018a881c70 -[NSApplication(NSResponder) sendAction:to:from:] + 460 7 AppKit 0x000000018a881a74 -[NSControl sendAction:to:] + 72 8 AppKit 0x000000018a8819b8 __26-[NSCell _sendActionFrom:]_block_invoke + 100 9 AppKit 0x000000018a8818e0 -[NSCell _sendActionFrom:] + 204 10 AppKit 0x000000018a881804 -[NSButtonCell _sendActionFrom:] + 88 11 AppKit 0x000000018a87ee38 NSControlTrackMouse + 1480 12 AppKit 0x000000018a87e844 -[NSCell trackMouse:inRect:ofView:untilMouseUp:] + 144 13 AppKit 0x000000018a87e6fc -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] + 488 14 AppKit 0x000000018a87dbd0 -[NSControl mouseDown:] + 448 15 AppKit 0x000000018a87c99c -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 3472 16 AppKit 0x000000018a807f78 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 364 17 AppKit 0x000000018a807c38 -[NSWindow(NSEventRouting) sendEvent:] + 284 18 AppKit 0x000000018aecde70 -[NSApplication(NSEventRouting) sendEvent:] + 1604 19 AppKit 0x000000018ab1b8cc -[NSApplication _handleEvent:] + 60 20 AppKit 0x000000018a6cfcdc -[NSApplication run] + 512 21 AppKit 0x000000018a6a6f54 NSApplicationMain + 880 22 objc_cocoa_test_image_3 0x0000000100608a68 main + 60 23 dyld 0x0000000186a1e0e0 start + 2360 ) can anyone point me in the right direction?

Hi. We have weird trouble related to the multi-threading. Does anyone have ideas how to resolve or avoid? Sample Code // sample.hpp class Sample { public: Sample(); ~Sample(); void Init(); void Dealloc(); void OnEvent(); private: std::mutex sample_mutex_; int counter = 1; } // sample.cpp #include "sample.hpp" Sample::Sample() {} Sample::~Sample() {} void Sample::Init() { std::async([]() { std::this_thread::sleep_for(std::chrono::seconds(2)); this->OnEvent(); }); } void Sample::Dealloc() { std::lock_guard<std::mutex> lock(sample_mutex_); counter = 0; } void Sample::OnEvent { // called from another thread std::lock_guard<std::mutex> lock(sample_mutex_); counter += 1; } // obj_sample.h @interface ObjSample : NSObject - (id _Nonnull)init; @property(nonatomic, readonly) std::shared_ptr<Sample> sample; @end // obj_sample.mm @implementation ObjSample - (id _Nonnull)init{ if (self = [super init]) { _sample = std::make_shared<Sample>(); _sample->Init(); } return self; } - (void)dealloc { sample->Dealloc(); } @end What happens the deadlock happens. according to the debug navigator with the Xcode, we figured out 2 facts below. OnEvent does not end although it looks completed. void Sample::OnEvent { // called from another thread std::lock_guard<std::mutex> lock(sample_mutex_); counter += 1; } // <= Thread 35: stop here Sample::Dealloc is run on the same thread of OnEvent. // debug navigator Thread 35 2 Sample::Dealloc <- this is weird. 3 Sample::OnEvent We guess they causes the deadlock. probability less than 10% Environment MacOS: 14.3.1(Apple M1) Xcode: 15.3 iOS Simulator: 17.0.1

Intermittent Failures Occur During macOS Build Execution on Bamboo. Below is an Extract from the Failure Logs. Note: Please note that within our larger Bamboo build environment, several Xcode projects are constructed. Failures occur intermittently across various Xcode projects each time the Bamboo build is initiated. Therefore, these failures are not specific to any particular Xcode project. It's important to emphasize that the Xcode project mentioned, "myProject.xcodeproj," is used purely as a placeholder or example in this context. which 'xcodebuild' VALID_ARCHS="x86_64 arm64" ARCHS="x86_64" -project “”myProject.xcodeproj"" -alltargets -configuration "Release" -UseModernBuildSystem=NO build 08-Feb-2024 09:53:00 Command line invocation: build 08-Feb-2024 09:53:00 /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild "VALID_ARCHS=x86_64 arm64" ARCHS=x86_64 -project myProject.xcodeproj -alltargets -configuration Release -UseModernBuildSystem=NO build 08-Feb-2024 09:53:00 build 08-Feb-2024 09:53:00 User defaults from command line: build 08-Feb-2024 09:53:00 IDEPackageSupportUseBuiltinSCM = YES build 08-Feb-2024 09:53:00 UseModernBuildSystem = NO build 08-Feb-2024 09:53:00 build 08-Feb-2024 09:53:00 Build settings from command line: build 08-Feb-2024 09:53:00 ARCHS = x86_64 build 08-Feb-2024 09:53:00 VALID_ARCHS = x86_64 arm64 build 08-Feb-2024 09:53:00 error 08-Feb-2024 09:53:01 objc[39076]: thread is already initializing this class! error 08-Feb-2024 09:53:01 make[6]: *** [compile] Abort trap: 6

I'm working on an FFI for working with ObjectiveC/Foundation/Metal. AFAIU, as many APIs create and autorelease objects, I need to ensure that an NSAutoreleasePool is active when calling into these APIs. So I've created a wrapper that basically mimics @autoreleasepool by creating and initializing an NSAutoreleasePool, running some code, and then draining the pool. So far so good; I'm using this functionality around most of my entry points into the ObjectiveC world. There's two issues I don't understand though. The first is that NSAutoreleasePool initialization seems to require an active autorelease pool, which seems like a chicken-and-egg problem. Running with OBJC_DEBUG_MISSING_POOLS=YES and breaking on objc_autoreleaseNoPool, I see: objc[30336]: MISSING POOLS: (0x1e2e89c40) Object 0x6000007e0050 of class __NSCFString autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug (lldb) bt objc_autoreleaseNoPool at /usr/lib/libobjc.A.dylib (unknown line) _ZN19AutoreleasePoolPage17autoreleaseNoPageEP11objc_object at /usr/lib/libobjc.A.dylib (unknown line) _ZN19AutoreleasePoolPage4pushEv at /usr/lib/libobjc.A.dylib (unknown line) _CFAutoreleasePoolPush at /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (unknown line) -[NSAutoreleasePool init] at /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (unknown line) macro expansion at /Users/tim/Julia/pkg/ObjectiveC/src/syntax.jl:163 [inlined] NSAutoreleasePool at /Users/tim/Julia/pkg/ObjectiveC/src/foundation.jl:427 The second, related problem is that some APIs that are called by Metal from a background thread I don't control: (lldb) bt * thread #11, queue = 'com.Metal.CompletionQueueDispatch', stop reason = breakpoint 1.1 * frame #0: 0x000000018c21b9e8 libobjc.A.dylib`objc_autoreleaseNoPool frame #1: 0x000000018c1eb99c libobjc.A.dylib`AutoreleasePoolPage::autoreleaseNoPage(objc_object*) + 252 frame #2: 0x000000018c21c9ec libobjc.A.dylib`AutoreleasePoolPage::push() + 76 frame #3: 0x00000001aaef9694 IOGPU`-[IOGPUMetalBuffer dealloc] + 104 frame #4: 0x00000001f83554e4 AGXMetalG15X_B0`-[AGXBuffer dealloc] + 44 frame #5: 0x00000001f837eb98 AGXMetalG15X_B0`-[AGXG15XFamilyBuffer dealloc] + 76 frame #6: 0x000000019687c1c4 Metal`MTLResourceListChunkFreeEntries(MTLResourceListChunk*) + 64 frame #7: 0x000000019674e2b0 Metal`-[MTLResourceList releaseAllObjectsAndReset] + 72 frame #8: 0x00000001aaefbd10 IOGPU`IOGPUMetalCommandBufferStorageReset + 36 frame #9: 0x00000001aaefbcac IOGPU`IOGPUMetalCommandBufferStorageDealloc + 76 frame #10: 0x00000001aaefa130 IOGPU`-[IOGPUMetalCommandBuffer didCompleteWithStartTime:endTime:error:] + 240 frame #11: 0x000000019674dce4 Metal`-[_MTLCommandQueue commandBufferDidComplete:startTime:completionTime:error:] + 108 frame #12: 0x00000001aaf03b54 IOGPU`IOGPUNotificationQueueDispatchAvailableCompletionNotifications + 128 frame #13: 0x00000001aaf03c60 IOGPU`__IOGPUNotificationQueueSetDispatchQueue_block_invoke + 64 frame #14: 0x000000018c4049d0 libdispatch.dylib`_dispatch_client_callout4 + 20 frame #15: 0x000000018c420c5c libdispatch.dylib`_dispatch_mach_msg_invoke + 468 frame #16: 0x000000018c40bd28 libdispatch.dylib`_dispatch_lane_serial_drain + 368 frame #17: 0x000000018c421998 libdispatch.dylib`_dispatch_mach_invoke + 444 frame #18: 0x000000018c40bd28 libdispatch.dylib`_dispatch_lane_serial_drain + 368 frame #19: 0x000000018c40ca08 libdispatch.dylib`_dispatch_lane_invoke + 432 frame #20: 0x000000018c40bd28 libdispatch.dylib`_dispatch_lane_serial_drain + 368 frame #21: 0x000000018c40c9d4 libdispatch.dylib`_dispatch_lane_invoke + 380 frame #22: 0x000000018c41761c libdispatch.dylib`_dispatch_root_queue_drain_deferred_wlh + 288 frame #23: 0x000000018c416e90 libdispatch.dylib`_dispatch_workloop_worker_thread + 404 frame #24: 0x000000018c5b2114 libsystem_pthread.dylib`_pthread_wqthread + 288 (lldb) c Process 26902 resuming objc[26902]: MISSING POOLS: (0x1e2e89c40) Object 0x14c8a2400 of class AGXG15SDevice autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug Again, I'm not sure how I'm supposed to run this under an autorelease pool.

I have a class category declared and compiled in a mac os static lib: #import <Foundation/Foundation.h> @interface NSNumber(MyExtension) -(NSString *)CallMe; @end then this staticLib is added to a mac console app in XCode and used: #import <Foundation/Foundation.h> #import "MacStaticLib.h" int main(int argc, const char * argv[]) { @autoreleasepool { NSNumber *one = [NSNumber numberWithInt:12]; NSLog(@"%@",[one CallMe]); } return 0; } Compiles fine but fails in runtime, unrecognized selector 'CallMe' send to instance... what's wrong or what I missed? Thanks!!

Hello. iOS 15 and its version of Swift had an issue with applying class level annotations, such as @available to the members of its class. When we attempt to use our Objective-C library to get the class, if there are things inside the class not available on iOS 15, then the call to objc_getClass crashes with EXC_BAD_ACCESS. This appears to have been fixed on iOS 16 and newer, however, as we still support iOS 15, is there a better workaround than having to annotate every needed member of the class with @available, instead of being able to use the class level annotation?

I refer to Google's ESF project code to handle NOTIFY events, but after my notifyQueue is set to QOS_CLASS_BACKGROUND, the process memory gets larger when a lot of events occur. Is there any way to fix this without affecting performance The code is as follows： notifyQueue = dispatch_queue_create("notify",dispatch_queue_attr_make_with_qos_class(DISPATCH_QUEUE_CONCURRENT_WITH_AUTORELEASE_POOL,QOS_CLASS_BACKGROUND, 0)); if (msg->action_type == ES_ACTION_TYPE_NOTIFY) { es_message_t *copied_msg = [self copy_message:msg]; if (!copied_msg) { return; } dispatch_async(self->_notifyQueue, ^{ @autoreleasepool { [self handle:copied_msg]; [self free_message:copied_msg]; } }); }

i’ve seen evidence that UIViewController has logic to prevent its dealloc/deinit methods from running on a background thread. what seems to occur is that, if the last strong reference to a UIVC is zeroed off the main thread, then the VC is logically marked as ‘deallocating’, but actual invocation of dealloc/deinit is enqueued to the main queue. during the window of time between the beginning and end of this asynchronous deallocation, some strange issues can occur. in particular, if the deallocating VC is a parent view controller, then its children can still access it via their parent property. despite this property being marked as weak, a non-nil parent VC reference will be returned. if a weak reference is attempted to be stored to the parent, you get a runtime crash immediately to the effect of: Cannot form weak reference to instance (0x1234) of class <some-UIVC-sublass>... surprisingly, if you load the reference via the objc runtime's objc_loadWeak method, you'll get nil, but no crash. unsurprisingly, if a strong reference to the deallocating parent is stored and persists past its dealloc invocation, you’ll generally end up with a segmentation violation if the reference is accessed. i imagine the UIVC source is quite complex and there are probably good reasons to try and ensure deallocation only ever occurs on the main thread, but it seems surprising that simply passing view controller variables across threads could lead to exposing unsafe references like this. is this behavior expected? assuming not, i've preemptively filed feedback FB13478946 regarding this issue. attached is some sample code that can reliably reproduce the unexpected behavior. UIKitAsyncDeallocCrashTests.swift

xcode :Version 15.0.1 (15A507) MACOS：13.6.1 (22G313) thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x0000000000000000 frame #1: 0x000000010482ec60 FUSTAKitOUTLINED_FUNCTION_3 + 580 frame #2: 0x0000000104430810 dyldImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 424 frame #3: 0x0000000104430bd8 dyldImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 52 frame #4: 0x000000010442b600 dyldImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 536 frame #5: 0x000000010442b56c dyldImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 388 frame #6: 0x0000000104429878 dyldImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 184 frame #7: 0x0000000104429940 dyldImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 92 frame #8: 0x000000010441a6d8 dylddyld::initializeMainExecutable() + 216 frame #9: 0x000000010441f928 dylddyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 5216 frame #10: 0x0000000104419208 dylddyldbootstrap::start(dyld3::MachOLoaded const*, int, char const**, dyld3::MachOLoaded const*, unsigned long*) + 396 frame #11: 0x0000000104419038 dyld`_dyld_start + 56 when I run a Test app(Just create with xcode Version 15.0.1 (15A507)，without any extra code) depency FUSTAKit.framework packed by xcode Version 15.0.1 (15A507), i find this error。 but used xcode 14.2 pack FUSTA Kit.framework , everything is normal 。

Hello, I am attempting to track down a crash that isn't giving me a lot of information (crash log included below). Here is what I know so far: According to Apple documentation, a crash in objc_msgSend is due to a zombie object. So I have been trying to recreate the crash with zombies enabled, without success. The address of the object being messaged is 0x0000000000000010, a suspect value. It's always 0x10, across thousands of crash reports with slightly differing stack traces and circumstances. That makes me wonder if the runtime is trying to tell me something with that address, but I have been unable to find any documentation to that effect. We have internal analytics that suggest that the crash always happens after the user activates the system PIP video player, and usually also after backgrounding the app. It is also common (though not universal) that the crash occurs after the user has paused the video (and sometimes resumed it). This post is a bit of a Hail Mary; I'm hoping that maybe someone on here will see something I missed, because I have exhausted most of my own avenues of investigation. Many thanks for any help you can provide. 2023-11-30_07-16-00.4347_-0800-ffd5dc1a3d2ca628e1761ccfec5fe79f223d099e.crash

Is there any documentation about the Objective-C ABI changes that cause the above warning warning: mixed ObjC ABI, libSomeLib.a compiled without category class properties ? what are "category class properties"

Hello, We have a legacy project that has a NSData category. This category is used to add a new method called "base64EncodedString" that we use for a custom base 64 encoding. Up until iOS 17, everything worked and we had no issue with it. This how we use it: NSString* text = @"This is the string we want to encode"; NSString* strArrRequests64 = [[text dataUsingEncoding:NSUTF8StringEncoding] base64EncodedString]; We have a breakpoint in our implementation of base64EncodedString - (NSString *)base64EncodedString { size_t outputLength; char *outputBuffer = ....; NSString *result = [[[NSString alloc] initWithBytes:outputBuffer length:outputLength encoding:NSUTF8StringEncoding] autorelease]; free(outputBuffer); return result; } The strange thing is that we use this method for several calls in our app. In 80% of the cases it triggers the breakpoint and the encoding works as intended, but some calls do not and the encoding does not happen. We have checked the class of [text dataUsingEncoding:NSUTF8StringEncoding] and for all calls is "NSMutableConcreteData". This is a breaking change for iOS17 and it affects a lot of our clients. We have a solution for this particular case, but there are more categories inside our library which can be affected by this issue. Please advise.

Below is the implementation of the object_cxxDestructFromClass method. the line below the for loop if (!cls->hasCxxDtor()) return; Some questions: If a subclass inherits a parent class, and one of the middle classes does not have a CxxDtor, but the parent class does, will there be any problems with the release of the instance? static void object_cxxDestructFromClass(id obj, Class cls) { void (*dtor)(id); // Call cls's dtor first, then superclasses's dtors. for ( ; cls; cls = cls->getSuperclass()) { if (!cls->hasCxxDtor()) return; dtor = (void(*)(id)) lookupMethodInClassAndLoadCache(cls, SEL_cxx_destruct); if (dtor != (void(*)(id))_objc_msgForward_impcache) { if (PrintCxxCtors) { _objc_inform("CXX: calling C++ destructors for class %s", cls->nameForLogging()); } (*dtor)(obj); } } }

class Employee { func calculateSalary() { -> how can I print name of the variable call in this function? } } Example: let johnny = Employee() johnny.calculateSalary() -> It will print "johnny" in function calculateSalary()

I was migrating from Xcode 14 -> 15, and noticed that my code was failing with dyld[46534]: Symbol not found: _OBJC_CLASS_$_NSError I was able to debug the problem to some old objective c code, as documented in this thread: https://github.com/RonRadtke/react-native-blob-util/issues/273 The error seems to stem from this particular try catch block @try { // Some code } @catch(NSError *er) { // handle error } When I convert the code to catch an NSException instead, the runtime error goes away. Understandably, according to the apple docs, it should be throwing an NSException in the first place, but the documents do say Important: Although you can throw and catch objects other than NSException objects, the Cocoa frameworks themselves might only catch NSException objects for some conditions. So if you throw other types of objects, the Cocoa handlers for that exception might not run, with undefined results. (Conversely, non-NSException objects that you throw could be caught by some Cocoa handlers.) For these reasons, it is recommended that you throw NSException objects only, while being prepared to catch exception objects of all types. So it seems like this should not have produced a runtime error. I wanted to flag this in case the underlying code behind the @try @catch changed unintentionally.

Hi Experts, I am working on a application where I am calling Objective-C Core WLAN API from golang with below code, darwin_lib.m void ConnectWiFi(char * cInterfacename, char * cSSID, char * cSecurity, char *cSubsecurity, char * cPassphrase, char * cOnexuser, char * cOnexpass) { @autoreleasepool { NSString * interfacename = [[NSString alloc] initWithUTF8String:cInterfacename]; NSString * ssid = [[NSString alloc] initWithUTF8String:cSSID]; NSString * security = [[NSString alloc] initWithUTF8String:cSecurity]; NSString * subsecurity = [[NSString alloc] initWithUTF8String:cSubsecurity]; NSString * passphrase = [[NSString alloc] initWithUTF8String:cPassphrase]; NSString * onexuser = [[NSString alloc] initWithUTF8String:cOnexuser]; NSString * onexpass = [[NSString alloc] initWithUTF8String:cOnexpass]; NSError * connecterr = nil; CWWiFiClient * cwwificlient = [CWWiFiClient sharedWiFiClient]; CWInterface *a = [cwwificlient interfaceWithName:interfacename]; NSSet<CWNetwork *> * network = [a scanForNetworksWithName:ssid error:&connecterr]; **** some more code ***** BOOL result = [a associateToEnterpriseNetwork:network.anyObject identity:nil username:onexuser password:onexpass error:&connecterr]; main.go package main // #cgo CFLAGS: -x objective-c // #cgo LDFLAGS: -framework CoreWLAN // #cgo LDFLAGS: -framework Foundation // #include "clib.h" import "C" import "fmt" func main() { var status C.int = C.ConnectWiFi() time.Sleep(20) *** some more code and long running process *** } Now what I am trying to understand here from memory release point of view is, Is object created in C code will be freed once I reach time.Sleep(20) e.g cwwificlient a spcifically to Core WLAN side or do I have to call release specifically on object? I tried calling release on cwwificlient and program is crashing on second execution, not sure why it would crash on only second execution, why not first time itself? I tried calling release on a and program is not crashing. Do I have to free all the Core WLAN related object myself or autoreleasepool will take care of it? As whole code is inside autoreleasepool, will all the objects be released on it's own even though function is being called from go code? As go's garbage collector has no idea how many objects C code created so go's garbage collector won't be of any help here Is autoreleasepool, can also take care of releasing any alloc object e.g ssid created inside C code ?

I ran across the following crash while using one of our apps. The app crashes since the recent iOS 17 beta builds. The code crashes when using valueForKey on an NSArray with objects that implement NSCopying. like: [@[[Sample new]] valueForKey:@"copy"]; or: [[Sample new] valueForKey:@"copy"]; header: @interface Sample : NSObject<NSCopying> - (Sample *)copy; - (Sample *)copyWithZone:(nullable NSZone *)zone; @end implementation: @implementation Sample - (Sample *)copy { return [super copy]; } - (Sample *)copyWithZone:(nullable NSZone *)zone { return self; } @end Any idea why this might be happening? I have created a feedback too: FB12819891

Any ideas on how to root cause this? Started since iOS 15.x, affecting only small percentage of users. Apple crash report attached. Thanks! 2023-07-25_15-08-32.4590_-0400-444d5ea058bb103160c275742f01d7f130e02661.crash

My application is currently crashing in production in iPhone devices running iOS 15.x. The app will work as normal while running developer mode, enterprise builds and Test Flight builds. Unfortunately, I am unable to reproduce this issue even app is downloaded from the app store. I observed crash is happening at main.m. Can someone help me to reproduce this issue? How to read this crash log file? Please find the crash log details attached. 2022-03-04_14-15-23.6227_+0900-a1899fd803a4ed683466702be71b9d224b4cd5bc.crash