Re: Crash in terminate: on Mavericks [SOLVED]

I narrowed the problem down to a plug-in bundle being unloaded using CFBundleUnloadExecutable. (I know, that's not the recommended approach, but this is legacy code.) So I looked into the plug-in. It's mostly C++, but there was one Objective-C++ source file that wasn't being used and didn't

Re: Crash in terminate: on Mavericks

On 1/21/19 11:38 AM, Georg Seifert wrote: Your symbol settings are wrong. Make sure you use a target that has any. DEBUG_INFORMATION_FORMAT = dwarf COPY_PHASE_STRIP = NO STRIP_INSTALLED_PRODUCT = NO > > Then you should at least see where it happens. > I have: DEBUG_INFORMATION_FORMAT = dwarf-

Re: Crash in terminate: on Mavericks

Your symbol settings are wrong. Make sure you use a target that has any. DEBUG_INFORMATION_FORMAT = dwarf COPY_PHASE_STRIP = NO STRIP_INSTALLED_PRODUCT = NO Then you should at least see where it happens. Georg > Am 21.01.2019 um 18:39 schrieb James Walker : > > On 1/18/19 6:30 PM, Ken Thomas

Re: Crash in terminate: on Mavericks

common that the timing differs by macOS version, which means it might crash in some versions, not in others. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the

Re: Crash in terminate: on Mavericks

On 1/21/19 9:43 AM, Sean McBride wrote: On Fri, 18 Jan 2019 16:48:37 -0800, James Walker said: When my app runs in Mavericks (10.9.5), it crashes on quit, but in High Sierra it's fine. The backtrace doesn't show any of my code, so I'm not sure how to proceed. I don't suppose this means anythi

Re: Crash in terminate: on Mavericks

ss something seems to be happening with windows, likely closing of windows. It’s extremely easy to get into an order-of-deallocation problem with views, view controllers, delegates and other objects, leading to a dangling pointer to an unallocated object. It’s also extremely for common that the t

Re: Crash in terminate: on Mavericks

On Fri, 18 Jan 2019 16:48:37 -0800, James Walker said: >When my app runs in Mavericks (10.9.5), it crashes on quit, but in High >Sierra it's fine. The backtrace doesn't show any of my code, so I'm not >sure how to proceed. I don't suppose this means anything to anyone? Have you tried ASan and T

Re: Crash in terminate: on Mavericks

On 1/18/19 6:30 PM, Ken Thomases wrote: You haven't included the nature of the crash, like an access violation or uncaught exception. That would be in the lines just above the excerpt you sent. Also, if you're able to reproduce this yourself, try running your app under the Zombies instrument

Re: Crash in terminate: on Mavericks

You haven't included the nature of the crash, like an access violation or uncaught exception. That would be in the lines just above the excerpt you sent. Also, if you're able to reproduce this yourself, try running your app under the Zombies instrument template. Regards, Ken > On Jan 18, 201

Crash in terminate: on Mavericks

When my app runs in Mavericks (10.9.5), it crashes on quit, but in High Sierra it's fine. The backtrace doesn't show any of my code, so I'm not sure how to proceed. I don't suppose this means anything to anyone? Application Specific Information: Performing @selector(terminate:) from sender NS

Re: Need a direction. App crash in CoreData while loading a window's nib

Hi Dave and thanks for the reply. As you can see in the stack - there isn’t actually any “code” per-se that runs at that time. Here is the actual method that fails: // Show the measurement browser panel, in which user can review existing measurements for the selected sample. -(IBAction)showMeas

Re: Need a direction. App crash in CoreData while loading a window's nib

Well - 2AM and I finally resolved it. I also think I understand why the strange recursion occurs This double-layer binding of content-array of one NSArrayController to the arrangedObjects of another NSArrayController (who’s bound to an ordered relation of…. ) made loading to occur like this.

Re: Need a direction. App crash in CoreData while loading a window's nib

If you can, can you establish the binding programmatically after launch? If so, does the program crash once the bindings are re-established? … considering if it is a launch issue or more systematic? Sandor > On Nov 4, 2018, at 17:25, Motti Shneor wrote: > > Well, thanks Dave, Hunter, Richa

Re: Need a direction. App crash in CoreData while loading a window's nib

Well, thanks Dave, Hunter, Richard and the rest. I followed each of your suggestions, and I finally found the culprit. A single binding, rather a nifty one, which I don’t know how to do better — Maybe you can help. Removing this binding (alas losing functionality) window opens instantly, rega

Re: Need a direction. App crash in CoreData while loading a window's nib

> On Nov 4, 2018, at 2:24 PM, Motti Shneor wrote: > > Hi Dave and thanks for the reply. > > As you can see in the stack - there isn’t actually any “code” per-se that > runs at that time. Here is the actual method that fails: > > As for modifying the persistent store - I guess I don’t becaus

Re: Need a direction. App crash in CoreData while loading a window's nib

Does your code modify anything in the persistent store during loading (NSManagedObjectContextDidChangeNotification)? Maybe it is rounding some values for display? This might cause infinite recursion with bindings. > On Nov 4, 2018, at 2:42 AM, Motti Shneor wrote: > > Thanks Richard. > > The

Re: Need a direction. App crash in CoreData while loading a window's nib

> On Nov 4, 2018, at 12:42 AM, Motti Shneor wrote: > > 3. I tried to build with Xcode 9.4.1 (MacOS SDK 10.13) then with Xcode 10 > (MacOS SDK 10.14) - same thing. I only have my MacOS 10.13 to try running on. > I cannot run the original Xcode (8.x) with which the production version was > buil

Re: Need a direction. App crash in CoreData while loading a window's nib

___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.c

Re: Need a direction. App crash in CoreData while loading a window's nib

> On Nov 4, 2018, at 1:42 AM, Motti Shneor wrote: > > I just do not know how to go about resolving this. Here is another idea. Remove your bindings one at a time. Perhaps it is just one binding that is causing the problem and then you can perhaps track it from there. It looks like this may b

Re: Need a direction. App crash in CoreData while loading a window's nib

Thanks Richard. The data is OK. Not corrupt. I can import and export it to .csv, and I do run several sanity test (heavy calculations based on that data pass OK and provide expected results). Most important - the production build of the software (built half year ago), opens the same database a

Re: Need a direction. App crash in CoreData while loading a window's nib

> On Nov 3, 2018, at 2:47 PM, Motti Shneor wrote: > > Can anyone suggest a way to start bisecting the issue or an idea where to > look for? You may have bad or corrupted data in your core data persistent store. Save the file out as an xml and see if you find anything suspicious. You could

Need a direction. App crash in CoreData while loading a window's nib

Hi. This is Objective-C, NSDocument based (CoreData document) based application, running long time in production, that suddenly started crashing for me. I have a main window (naster/detail) presents a relatively large database. Each line when double-clicked, opens a secondary window to show ano

Re: Crash in Touchbar

Saagar Jha > On Jan 29, 2018, at 06:06, sumit bansal wrote: > > Hi All, > > I am getting 2 non-reproducible crashes in my application related to Touch > Bar. It may be the bug in Appkit code. Does anyone has any idea about it? > > > ===

Crash in Touchbar

Hi All, I am getting 2 non-reproducible crashes in my application related to Touch Bar. It may be the bug in Appkit code. Does anyone has any idea about it? == Stack#1 Application Specific Information: objc_msgSend() selector n

Re: How to debug crash in NSOperation?

Sent from my iPhone > On 28 Mar 2017, at 11:41, Quincey Morris > wrote: > >> On Mar 26, 2017, at 22:04 , Gerriet M. Denkmann wrote: >> >> [ arrayOfStrings writeToFile: “directoryPath/SortedKeys.plist” atomically: >> YES ]; ← pseudo code > > A couple of points about this line of code, assu

Re: How to debug crash in NSOperation?

On Mar 26, 2017, at 22:04 , Gerriet M. Denkmann wrote: > > [ arrayOfStrings writeToFile: “directoryPath/SortedKeys.plist” atomically: > YES ]; ← pseudo code A couple of points about this line of code, assuming that the method -[NSArray writeToFile:atomically:] is actually being used: 1. This

Re: How to debug crash in NSOperation?

Sent from my iPhone > On 28 Mar 2017, at 10:32, Jens Alfke wrote: > > >> On Mar 27, 2017, at 8:25 PM, Gerriet M. Denkmann wrote: >> >> >> >> Sent from my iPhone >> >>> On 27 Mar 2017, at 23:37, Jens Alfke wrote: >>> >>> On Mar 26, 2017, at 10:04 PM, Gerriet M. Denkmann wro

Re: How to debug crash in NSOperation?

> On Mar 27, 2017, at 8:25 PM, Gerriet M. Denkmann wrote: > > > > Sent from my iPhone > > On 27 Mar 2017, at 23:37, Jens Alfke > wrote: > >> >>> On Mar 26, 2017, at 10:04 PM, Gerriet M. Denkmann >> > wrote: >>> >>> Yes, you are right.

Re: How to debug crash in NSOperation?

Sent from my iPhone > On 27 Mar 2017, at 23:37, Jens Alfke wrote: > > >> On Mar 26, 2017, at 10:04 PM, Gerriet M. Denkmann >> wrote: >> >> Yes, you are right. And I have to apologise for not spotting this: >> >> *** Terminating app due to uncaught exception 'NSInvalidArgumentException',

Re: How to debug crash in NSOperation?

> On Mar 26, 2017, at 10:04 PM, Gerriet M. Denkmann wrote: > > Yes, you are right. And I have to apologise for not spotting this: > > *** Terminating app due to uncaught exception 'NSInvalidArgumentException', > reason: '*** setObjectForKey: object cannot be nil (key: SortedKeys.plist)' I rec

Re: How to debug crash in NSOperation?

> On 27 Mar 2017, at 10:39, Ken Thomases wrote: > > On Mar 26, 2017, at 10:06 PM, Gerriet M. Denkmann wrote: >> >> macOS 12.3 >> >> This is a rather rare bug (never seen before): >> >> Thread 12 Crashed:: Dispatch queue: เสือ :: NSOperation 0x61800184fbd0 (QOS: >> UTILITY) >> 0 libsystem_

Re: How to debug crash in NSOperation?

On Mar 26, 2017, at 10:06 PM, Gerriet M. Denkmann wrote: > > macOS 12.3 > > This is a rather rare bug (never seen before): > > Thread 12 Crashed:: Dispatch queue: เสือ :: NSOperation 0x61800184fbd0 (QOS: > UTILITY) > 0 libsystem_kernel.dylib0x7fffb3d65dd6 __pthread_kill + 10

How to debug crash in NSOperation?

macOS 12.3 This is a rather rare bug (never seen before): Thread 12 Crashed:: Dispatch queue: เสือ :: NSOperation 0x61800184fbd0 (QOS: UTILITY) 0 libsystem_kernel.dylib 0x7fffb3d65dd6 __pthread_kill + 10 1 libsystem_pthread.dylib 0x7fffb3e51787 pthread_kill +

Re: Gestures cause crash in Sierra

ITOT any gesture which could be interpreted as the start of a scroll generated an immediate constrainBoundsRect call with +inf,+inf as the origin (apparently a bug/feature in Sierra). My custom NSClipView wasn't set up to handle the invalid coordinates (it generally passes back whatever is sent

Gestures cause crash in Sierra

I'm having a problem with my applications that has come up just with Sierra. Any "swiping" gesture with two or three fingers on the trackpad causes an immediate crash. (Log below). A four finger swipe (if the four fingers are put down very deliberately) behaves properly. The fatal thread doesn'

Re: [Solved] Crash in addSubview: when compiled with SDK > 10.9

> On 4 Nov 2016, at 2:00 AM, Konidaris Christos wrote: > > The problem was that my NIBs also contained NSViewController objects for some > of their subviews. Changing these controllers to plain NSObjects eliminated > the crashes. > > Thank you for pointing me to the correct direction. > Tha

Re: [Solved] Crash in addSubview: when compiled with SDK > 10.9

> On 2 Nov 2016, at 19:24, Quincey Morris > wrote: > > On Nov 2, 2016, at 10:00 , Konidaris Christos wrote: >> >> Our application crashes inside AppKit when compiled with any SDK > 10.9. The >> crash happens at the following point in the program: >> >> activityPaneController = [[ESC_Activit

Re: Crash in addSubview: when compiled with SDK > 10.9

> On 2 Nov 2016, at 19:30, Quincey Morris > wrote: > > On Nov 2, 2016, at 10:00 , Konidaris Christos wrote: > >> Our application crashes inside AppKit when compiled with any SDK > 10.9. The >> crash happens at the following point in the program: >> >> activityPaneController = [[ESC_Activity

Re: Crash in addSubview: when compiled with SDK > 10.9

On Nov 2, 2016, at 10:00 , Konidaris Christos wrote: > Our application crashes inside AppKit when compiled with any SDK > 10.9. The > crash happens at the following point in the program: > > activityPaneController = [[ESC_ActivityPaneController alloc] initWithNibName: > @“ESC_ActivitySideBox"

Re: Crash in addSubview: when compiled with SDK > 10.9

Zombie objects and Malloc Scribble are checked in Diagnostics. – Chris > On 2 Nov 2016, at 19:05, Jens Alfke wrote: > > Have you run with Zombies enabled? Or with the address sanitizer? > > —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.

Re: Crash in addSubview: when compiled with SDK > 10.9

Have you run with Zombies enabled? Or with the address sanitizer? —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.appl

Crash in addSubview: when compiled with SDK > 10.9

Hi All, Our application crashes inside AppKit when compiled with any SDK > 10.9. The crash happens at the following point in the program: activityPaneController = [[ESC_ActivityPaneController alloc] initWithNibName: @“ESC_ActivitySideBox" bundle: nil]; [superV addSubview: activityPaneController

Crash in printing

One of my users has reported a crash in printing, and I don't really know what could be triggering it. This is the error: Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00f8 VM Regions Near 0xf8: -->

Crash in _NSVisualizedConstraintsView viewWillDraw

On occasion I see the following crash: The Error-Responder chain is showing an NSDocumentController triggered alert. My take on this would be that is a retain issue somewhere in the framework constraint visualisation code. I cannot reproduce the issue though. Thanks Jonathan OS Version: M

Re: NSOpenPanel() crash in Swift 1.1 -- SOLVED?

On Mon, Feb 23, 2015, at 04:08 PM, Bill Cheeseman wrote: > > > On Feb 23, 2015, at 5:02 PM, Charles Srstka > > wrote: > > > > That’s not a crash. That’s just some C++ code deep down in the system > > somewhere using exceptions as flow control. > > > It sure wasted a lot of my time, whatever

Re: NSOpenPanel() crash in Swift 1.1 -- SOLVED?

> On Feb 23, 2015, at 5:02 PM, Charles Srstka wrote: > > That’s not a crash. That’s just some C++ code deep down in the system > somewhere using exceptions as flow control. It sure wasted a lot of my time, whatever you want to call it. Extremely annoying. It's been so long since I used C++

Re: NSOpenPanel() crash in Swift 1.1 -- SOLVED?

On Feb 23, 2015, at 3:51 PM, Bill Cheeseman wrote: > > The explanation I found via Google search was in a short article from Touch > Code Magazine, here: > http://www.touch-code-magazine.com/how-to-show-an-open-file-dialogue-in-cocoa/ > >

Re: NSOpenPanel() crash in Swift 1.1 -- SOLVED?

> On Feb 23, 2015, at 3:43 PM, Kyle Sluder wrote: > > On Mon, Feb 23, 2015, at 02:00 PM, Bill Cheeseman wrote: >> >> But I appear to have solved the problem, based on something I found by >> doing a broader Google search. At some point I had added a breakpoint for >> "All Exceptions." My latest

Re: NSOpenPanel() crash in Swift 1.1 -- SOLVED?

On Mon, Feb 23, 2015, at 02:00 PM, Bill Cheeseman wrote: > > But I appear to have solved the problem, based on something I found by > doing a broader Google search. At some point I had added a breakpoint for > "All Exceptions." My latest Google search turned up a suggestion to limit > this to "Obj

Re: NSOpenPanel() crash in Swift 1.1 -- SOLVED?

> On Feb 20, 2015, at 7:45 AM, Bill Cheeseman wrote: > > I'm writing a single-window utility application in Xcode 6.1.1 on OS X > 10.10.2 using Swift 1.1. This code statement crashes: > > let panel = NSOpenPanel() > > For the first several days after I added this statement, it worked cor

NSOpenPanel() crash in Swift 1.1

I'm writing a single-window utility application in Xcode 6.1.1 on OS X 10.10.2 using Swift 1.1. This code statement crashes: let panel = NSOpenPanel() For the first several days after I added this statement, it worked correctly -- the panel opened and I was able to select a file in the pan

Re: Crash in libsystem_kernel.dylib`__workq_kernreturn:

I agree that it sounds like a memory management bug. Especially since you aren't using ARC. Try turning on NSZombies and see if it crashes at a more helpful point. http://michalstawarz.pl/2014/02/22/debug-exc_bad_access-nszombie-xcode-5/ On Sun, Jan 25, 2015 at 4:57 PM, Trygve Inda wrote: >> On

Re: Crash in libsystem_kernel.dylib`__workq_kernreturn:

> What are you using for memory management then? Manual, GC? > > Sent from my iPad > > On 25 Jan 2015, at 22:57, Trygve Inda wrote: > On Jan 25, 2015, at 12:33 , Trygve Inda wrote: It does seem like if I remove a call to NSData* imageData = [[self myImageRep] re

Re: Crash in libsystem_kernel.dylib`__workq_kernreturn:

What are you using for memory management then? Manual, GC? Sent from my iPad On 25 Jan 2015, at 22:57, Trygve Inda wrote: >>> On Jan 25, 2015, at 12:33 , Trygve Inda wrote: >>> >>> It does seem like if I remove a call to >>> >>> NSData* imageData = [[self myImageRep] >>> representationUsingT

Re: Crash in libsystem_kernel.dylib`__workq_kernreturn:

> On Jan 25, 2015, at 12:33 , Trygve Inda wrote: >> >> It does seem like if I remove a call to >> >> NSData* imageData = [[self myImageRep] >> representationUsingType:NSJPEGFileType properties:imageProperties]; >> >> It no longer crashes, but the crash happens 3-5 seconds after this call when >

Re: Crash in libsystem_kernel.dylib`__workq_kernreturn:

On Jan 25, 2015, at 12:33 , Trygve Inda wrote: > > It does seem like if I remove a call to > > NSData* imageData = [[self myImageRep] > representationUsingType:NSJPEGFileType properties:imageProperties]; > > It no longer crashes, but the crash happens 3-5 seconds after this call when > my progr

Crash in libsystem_kernel.dylib`__workq_kernreturn:

I am getting a very weird, random crash in: libsystem_kernel.dylib`__workq_kernreturn: 0x7fff8381de60: movl $0x2000170, %eax 0x7fff8381de65: movq %rcx, %r10 0x7fff8381de68: syscall 0x7fff8381de6a: jae0x7fff8381de74; __workq_kernreturn + 20 0x7fff8381de6c: movq %rax

Re: Inexplicable Crash in -[NSAppleScript executeAndReturnError:]

On Jan 23, 2015, at 1:25 PM, Jerry Krinock wrote: > Can anyone explain this weird crash report I got from a user and symbolized? > The last thing my code does (frame 24 in the call stack below), is to send > -[NSAppleScript executeAndReturnError:]. The crash says someone tried to set > a *di

Re: Inexplicable Crash in -[NSAppleScript executeAndReturnError:]

> On 2015 Jan 23, at 17:17, Steve Mills wrote: > > Oh, that reminds me. I had to change it to mainBundle instead of > mainAppBundle. The method is -mainAppBundle, but indeed you don’t have it. I wrote it. It returns the bundle of the enclosing “main” app when run from a helper tool, so tha

Re: Inexplicable Crash in -[NSAppleScript executeAndReturnError:]

On Jan 23, 2015, at 18:40, Shane Stanley wrote: >> On 24 Jan 2015, at 6:25 am, Jerry Krinock wrote: >> >> NSString* source ; >> source = [NSString stringWithFormat: >> @"tell application \"%@\"\n" >> @"activate\n" >> @"present last logged error\n" >> @"end te

Re: Inexplicable Crash in -[NSAppleScript executeAndReturnError:]

On 24 Jan 2015, at 11:40 am, Shane Stanley wrote: > >> where [[NSBundle mainAppBundle] bundlePath] returns “com.mycompany.MyApp”. > > In that case, you should be using @"tell application id \"%@\"\n". Ignore that. Your code says bundlePath, but I focused on your description, which looks more

Re: Inexplicable Crash in -[NSAppleScript executeAndReturnError:]

On 24 Jan 2015, at 6:25 am, Jerry Krinock wrote: > > NSString* source ; > source = [NSString stringWithFormat: > @"tell application \"%@\"\n" > @"activate\n" > @"present last logged error\n" > @"end tell", > [[NSBundl

Re: Inexplicable Crash in -[NSAppleScript executeAndReturnError:]

> On 2015 Jan 23, at 12:36, Michael Crawford wrote: > > perhaps the bug occurred somewhere else and either corrupted the heap or… Yes, that is a good point. > If you haven't already tried it, enable Guard Malloc and friends in > your build. Ah, I forgot about that. Just tried it. Worked per

Re: Inexplicable Crash in -[NSAppleScript executeAndReturnError:]

perhaps the bug occurred somewhere else and either corrupted the heap or wrote an erroneous value into some data structure, with the eventual result that you jumped off into hyperspace, then ran along just fine until a method was called with parameters that were suitably invalid as to cause a crash

Re: Inexplicable Crash in -[NSAppleScript executeAndReturnError:]

On Jan 23, 2015, at 14:18:38, Jerry Krinock wrote: > > Thank you, Steve. Oh, there isn’t any. It is only my app, as in MyApp, > which implements that command. I made it up. :) Oh duh. That would explain why 1 of the 3 search results is at sheepsystems.com. :) > Indeed. The way I’m using

Re: Inexplicable Crash in -[NSAppleScript executeAndReturnError:]

> On 2015 Jan 23, at 11:40, Steve Mills wrote: > > I can't find any docs for "present last logged error”. Thank you, Steve. Oh, there isn’t any. It is only my app, as in MyApp, which implements that command. I made it up. :) > How do I set up a state so that it will do something? I'm tryi

Re: Inexplicable Crash in -[NSAppleScript executeAndReturnError:]

On Jan 23, 2015, at 13:25:58, Jerry Krinock wrote: > > Can anyone explain this weird crash report I got from a user and symbolized? > The last thing my code does (frame 24 in the call stack below), is to send > -[NSAppleScript executeAndReturnError:]. The crash says someone tried to set > a

Inexplicable Crash in -[NSAppleScript executeAndReturnError:]

Can anyone explain this weird crash report I got from a user and symbolized? The last thing my code does (frame 24 in the call stack below), is to send -[NSAppleScript executeAndReturnError:]. The crash says someone tried to set a *dictionary* object with a nil key. How could I have done that

Re: Weird crash in FSRefCreate while saving NSDocument

On Nov 25, 2014, at 9:27 AM, Markus Spoettl wrote: > > That hits only one user out of many? All the time, whenever he uses it, and > no one else. Caused by other apps or ours? All good points. I'd certainly want a system profile, to examine both it and the crash report for any 3rd-party kexts

Re: Weird crash in FSRefCreate while saving NSDocument

On 25/11/14 15:28, Scott Ribe wrote: On Nov 25, 2014, at 1:26 AM, Markus Spoettl wrote: My user says he doesn't experience sluggishness, he also tried rebooting the machine and repair the disk permissions. Still crashes reliably every time. In that case, I'd personally suspect heap corrupti

Re: Weird crash in FSRefCreate while saving NSDocument

On Nov 25, 2014, at 1:26 AM, Markus Spoettl wrote: > > My user says he doesn't experience sluggishness, he also tried rebooting the > machine and repair the disk permissions. Still crashes reliably every time. In that case, I'd personally suspect heap corruption. -- Scott Ribe scott_r...@elev

Re: Weird crash in FSRefCreate while saving NSDocument

On 24/11/14 14:54, Scott Ribe wrote: So I have no idea if this is related or not. But a few things for you to possibly find out: is there a lot of file manipulation being done on that Mac, is performance of everything sluggish before this happens, and will it work after a reboot. My user says h

Re: Weird crash in FSRefCreate while saving NSDocument

On 24/11/14 14:54, Scott Ribe wrote: On Nov 24, 2014, at 3:03 AM, Markus Spoettl wrote: I'm attaching the call stack of the crash in the hope that someone on the list recognizes it. Any ideas what might be going on? Is this 10.10? And the libs are still using FSRef underneath

Re: Weird crash in FSRefCreate while saving NSDocument

On Nov 24, 2014, at 3:03 AM, Markus Spoettl wrote: > > I'm attaching the call stack of the crash in the hope that someone on the > list recognizes it. Any ideas what might be going on? Is this 10.10? And the libs are still using FSRef underneath their implementations??? Hoo

Weird crash in FSRefCreate while saving NSDocument

Hello, I have a user who keeps crashing our app by saving his NSDocument (file wrapper based). I can't make any sense of it and he's the only one who runs into this, apparently. I'm attaching the call stack of the crash in the hope that someone on the list recognizes it.

Re: Weird crash in -[NSSearchField setRecentSearches:]

> On 2014 Nov 10, at 15:37, Lee Ann Rucker wrote: > > Do you implement any of the delegate methods corresponding to the > notifications? Cocoa will add notifications for you instead of bothering with > "respondsToSelector:" all the time. Thank you, Lee Ann. No, I can’t find any corresponding

Re: Weird crash in -[NSSearchField setRecentSearches:]

Do you implement any of the delegate methods corresponding to the notifications? Cocoa will add notifications for you instead of bothering with "respondsToSelector:" all the time. On Nov 9, 2014, at 5:02 AM, Jerry Krinock wrote: > >> On 2014 Nov 07, at 16:02, Greg Parker wrote: >> >> You m

Re: Weird crash in -[NSSearchField setRecentSearches:]

> On 2014 Nov 07, at 16:02, Greg Parker wrote: > > You may have better luck tracing it from the other side. Run to that line in > appendToRecentSearches:, set a breakpoint on -[NSNotificationCenter > postNotificationName:object:userInfo:], and step over your line. At those > breakpoints you s

Re: Weird crash in -[NSSearchField setRecentSearches:]

> On Nov 7, 2014, at 12:35 PM, Jerry Krinock wrote: > >> On 2014 Nov 07, at 14:14, Greg Parker wrote: >> >> Which frame are you in when you try to read the register (the top frame, or >> some other frame)? > > Some other. #11 in this call stack: > > #0 in strlen () > #1 in strdup () >

Re: Weird crash in -[NSSearchField setRecentSearches:]

time this crash occurs, I’ll try it. Maybe I can accelerate the next crash by scripting a stress test. > objc_msgSend_corrupt_cache_error is trying to print some diagnostic info > before crashing. You should usually debug it as if it were a crash in > objc_msgSend itself: zombies, guard m

Re: Weird crash in -[NSSearchField setRecentSearches:]

esults. If I remove > the underscores, I get one result indicating that, yes, this could be due to > a deallocced observer. objc_msgSend_corrupt_cache_error is trying to print some diagnostic info before crashing. You should usually debug it as if it were a crash in objc_msgSend itself:

Re: Weird crash in -[NSSearchField setRecentSearches:]

> On 2014 Nov 04, at 01:33, Quincey Morris > wrote: > > The fact that NSNotificationCenter is involved tells you that this is *not* > KVO related. OK, then that makes me even more upset that all I can get from po $rdi, po $rdx, po $rcx, etc. when I need them nowadays is those damned “Couldn’

Re: Weird crash in -[NSSearchField setRecentSearches:]

On Nov 3, 2014, at 19:54 , Jerry Krinock wrote: > > The highest line in the stack in my code is #12. Line #11 indicates that the > crash occurs when AppKit attempts to post a notification, which I suspect is > a KVO notification. (But is NSNotificationCenter used in KVO?) No, it is not. The

Weird crash in -[NSSearchField setRecentSearches:]

I have subclassed NSSearchField, implementing a method which appends a new search to recent searches after the user has entered text into it. Three times during the last year, I’ve seen this method crash where it sets the new array of searches into super’s recentSearches, [self setRecentSearch

Re: No longer existing outlet causes crash in new version of app (iOS)

On Mar 7, 2014, at 3:22 AM, Koen van der Drift wrote: > > >> On Mar 6, 2014, at 10:02 PM, Kyle Sluder wrote: >> >>> On Thu, Mar 6, 2014, at 04:25 PM, Koen van der Drift wrote: >>> Just changing the name of the VC solved it. >> >> Well, the old build compiled nib is still sitting in your buil

Re: No longer existing outlet causes crash in new version of app (iOS)

On Mar 6, 2014, at 10:02 PM, Kyle Sluder wrote: > On Thu, Mar 6, 2014, at 04:25 PM, Koen van der Drift wrote: >> Just changing the name of the VC solved it. > > Well, the old build compiled nib is still sitting in your build > products, so it didn't really "solve" anything. I agree - so is the

Re: No longer existing outlet causes crash in new version of app (iOS)

On Thu, Mar 6, 2014, at 04:25 PM, Koen van der Drift wrote: > Just changing the name of the VC solved it. Well, the old build compiled nib is still sitting in your build products, so it didn't really "solve" anything. > Will this be an issue with users when they update to the new version? I don't

Re: No longer existing outlet causes crash in new version of app (iOS)

Just changing the name of the VC solved it. - Koen. On Mar 6, 2014, at 7:18 PM, Koen van der Drift wrote: > > On Mar 6, 2014, at 7:15 PM, Kyle Sluder wrote: > >> Delete the app from your device and rebuild. I'm guessing the XIB is >> left over and has the same name as a UIViewController, b

Re: No longer existing outlet causes crash in new version of app (iOS)

On Mar 6, 2014, at 7:15 PM, Kyle Sluder wrote: > Delete the app from your device and rebuild. I'm guessing the XIB is > left over and has the same name as a UIViewController, but that view > controller is now trying to set up its view in code. Since Xcode never > deletes files from the build pro

Re: No longer existing outlet causes crash in new version of app (iOS)

On Thu, Mar 6, 2014, at 04:01 PM, Koen van der Drift wrote: > I'm working on a new version of my app, and while testing it against the > one that is now in the store, I'm running into an "*** Terminating app > due to uncaught exception 'NSUnknownKeyException', reason: > '[ setValue:forUndefinedKey:

No longer existing outlet causes crash in new version of app (iOS)

I'm working on a new version of my app, and while testing it against the one that is now in the store, I'm running into an "*** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[ setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key graph

Re: Crash in -URLByResolvingBookmarkData::::: in sandboxed app

you’re intending to sell the app on the app store, the only true fix is probably to require 10.9. -Andrew Madsen On Feb 19, 2014, at 8:03 AM, Markus Spoettl wrote: > Hi, > > I keep getting a crash in my sandboxed app when it terminates. It is not > 100% reproducible, but it happens

Crash in -URLByResolvingBookmarkData::::: in sandboxed app

Hi, I keep getting a crash in my sandboxed app when it terminates. It is not 100% reproducible, but it happens a couple of times a day while working on the app, both when run from Xcode and started from Finder. Part of the termination cleanup requires me to decode a bookmark that was

Re: Crash in 10.9 decoding NSAttributedString

Sure, but I need a fix, even if temporary. I can probably simply not dearchive that object, but… I just call -[coder decodeObject:… forKey:…], but the actual object that could be returned is of almost any kind in this particular case. Without decoding it I can’t tell what class it’s going to be

Re: Crash in 10.9 decoding NSAttributedString

On Nov 1, 2013, at 3:04 PM, Graham Cox wrote: > In -initWithCoder for one of my objects, I attempt to decode an > NSAttributedString. It goes into an infinite recursion and crashes on 10.9. > This works fine on 10.7 and 10.8. Anyone any ideas what could be going on, A bug in CoreText, probab

Crash in 10.9 decoding NSAttributedString

In -initWithCoder for one of my objects, I attempt to decode an NSAttributedString. It goes into an infinite recursion and crashes on 10.9. This works fine on 10.7 and 10.8. Anyone any ideas what could be going on, or has seen this? Here’s the stack below the last place in my code: #0 0x0

Re: Crash in datasource method when closing document

On Oct 10, 2013, at 12:06 AM, Shane Stanley wrote: > The problem I'm having is that if I open a file, then add an item, say a > folder, then click the close button and choose Revert Changes, I (nearly > always) get an exception thrown on the outline view's datasource method > -outlineView:obje

Re: Crash in datasource method when closing document

On Wed, 9 Oct 2013 23:10:18 -0700, Jerry Krinock said: >> I'm using ARC. > >ARC doesn't help for KVO observers, notification observers, delegates, >manual bindings, or data sources. These must still be managed manually. > >* * * > >Here is some typical code "tear down" code. This is for a tabbed

Re: Crash in datasource method when closing document

On 10 Oct 2013, at 10:56 PM, Michael Babin wrote: > outlet connected? Problem solved... -- Shane Stanley 'AppleScriptObjC Explored' ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments t

Re: Crash in datasource method when closing document

On 10 Oct 2013, at 9:51 PM, Michael Babin wrote: > From your description, it appears that you're presenting a window/sheet when > the window is asked to close (Save/revert changes?). When the revert option > is selected, what changes occur to the underlying data supporting the outline > view?

  1   2   3   >