Re: Safe time to add accessory view to NSSavePanel in sandboxed app?

[Marek Hrušovský]

I just went through my crashes and this thread popped up in google.

I have additional information (one helpful method in the stack). Even if I
dig deep I still can't figure out what can cause the issue. Is anyone able
to get from "_hierarchyDidChangeInView" the line where it crashes?


Anyway I created rdar://23165196


Marek.


Date/Time:   2015-10-14T19:16:34Z

OS Version:  Mac OS X 10.11.0 (15A278b)

Report Version:  104


Exception Type:  SIGSEGV

Exception Codes: SEGV_MAPERR at 0x7fc7a764438

Crashed Thread:  0


Thread 0 Crashed:

0   libobjc.A.dylib  0x7fff84dcbe5d objc_msgSend +
29

1   ViewBridge   0x7fff9519ea42
-[NSVBAccessoryWindow _hierarchyDidChangeInView:] + 69

2   AppKit   0x7fff86593aea -[NSView
_setSuperview:] + 2602

3   AppKit   0x7fff86592c28 -[NSView
addSubview:] + 448

4   AppKit   0x7fff865fa754 -[NSWindow
setContentView:] + 638

5   ViewBridge   0x7fff951d1253
setWindowContentView + 75

6   ViewBridge   0x7fff951b5d8b
-[NSRemoteViewBase setAccessoryView:] + 208

7   AppKit   0x7fff86df9ed8
-[NSVBSavePanel(NSSavePanelSPI) _sendAccessoryView:] + 49

80x00010b56e3b0 0x10b4bf000 + 717744

On Sat, Jul 18, 2015 at 12:14 AM, Martin Wierschin  wrote:

> I just had a beta tester contact me about a very similar error/crash. It's
> slightly different than I've seen before, but it certainly seems related.
>
> The tester was closing a window backed by NSDocument. In response the
> AppKit document machinery was attempting to create an NSSavePanel, to allow
> the user to save or discard the file, but NSRemoteView threw an
> exception[1].
>
> As I mentioned earlier in this thread, I've come to anticipate this. I now
> wrap the relevant NSDocument method to catch any exceptions and display a
> warning alert that the system save panel is (apparently) temporarily
> unavailable. This time the app crashed while trying to generate that alert;
> -[NSAlert init] was loading some localized string and crashed[2].
>
> I doubt this is going to be reproducible, but it's reported as
> rdar://21881669.
>
> ~Martin Wierschin
>
>
> [1] INITIAL EXCEPTION:
>
> MyApp[807]: *** Assertion failure in -[NSRemoteView
> setServiceObject:forKey:],
> /SourceCache/ViewBridge/ViewBridge-105/NSRemoteView.m:3142
> failed:  invalid
> in: NSInternalInconsistencyException line 0
> STACK TRACE:
> ...
>  libobjc.A.dylib   objc_exception_throw
>  CoreFoundation+[NSException raise:format:arguments:]
>  Foundation-[NSAssertionHandler
> handleFailureInMethod:object:file:lineNumber:description:]
>  ViewBridge-[NSRemoteViewBase setServiceObject:forKey:]
>  FoundationNSKeyValueNotifyObserver
>  FoundationNSKeyValueDidChange
>  Foundation-[NSObject(NSKeyValueObserverNotification)
> didChangeValueForKey:]
>  AppKit-[NSDocument _preparedSavePanelForOperation:]
> ...
>  AppKit-[NSDocument
> canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:]
>  AppKit-[NSWindow __close]
>  AppKit-[NSControl sendAction:to:]
> ...
>  AppKitNSApplicationMain
>  MyApp MyAppMain
>  MyApp start
>
>
>
> [2] SUBSEQUENT CRASH:
>
> Exception Type:EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes:   KERN_INVALID_ADDRESS atVM Regions Near:
> ...
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   com.apple.CoreServices.CarbonCore _CSGetNamedData
> 1   com.apple.CoreFoundation  _CFPropertyListCopyShared
> 2   com.apple.CoreFoundation
> CFBundleCopyLocalizedStringForLocalization
> 3   com.apple.Foundation  -[NSBundle
> localizedStringForKey:value:table:]
> 4   com.apple.AppKit  -[NSAlert init]
> 5   com.apple.AppKit  +[NSAlert
> alertWithMessageText:defaultButton:alternateButton:otherButton:informativeTextWithFormat:]
> 6   com.company.myapp __84-[MyApp
> delayedWarnAboutUnavailableSavePanel:]_block_invoke
> 7   libdispatch.dylib _dispatch_call_block_and_release
> 8   libdispatch.dylib _dispatch_client_callout
> ...
> 17  com.apple.AppKit  -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:]
> 18  com.apple.AppKit  -[NSApplication run]
> 19  com.apple.AppKit  NSApplicationMain
> 20  com.company.myapp MyMain
> 21  com.company.myapp start
>
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the 

Re: Safe time to add accessory view to NSSavePanel in sandboxed app?

[Gary L. Wade]

That looks familiar back when I dealt with adding an accessory view under sand 
boxing. I don't have the code base available to me to know what I did 
differently or remind me further, but I know I did something different in the 
sandboxed version than the non-sandboxed. There's a number of web pages you 
should find related to the save panel UI hierarchy under sand boxing that 
should help, though. Search on things like NSSavePanel, sandbox, NSRemoteView, 
etc.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/

> On Oct 19, 2015, at 8:22 AM, Marek Hrušovský  wrote:
> 
> I just went through my crashes and this thread popped up in google.
> 
> I have additional information (one helpful method in the stack). Even if I
> dig deep I still can't figure out what can cause the issue. Is anyone able
> to get from "_hierarchyDidChangeInView" the line where it crashes?
> 
> 
> Anyway I created rdar://23165196
> 
> 
> Marek.
> 
> 
> Date/Time:   2015-10-14T19:16:34Z
> 
> OS Version:  Mac OS X 10.11.0 (15A278b)
> 
> Report Version:  104
> 
> 
> Exception Type:  SIGSEGV
> 
> Exception Codes: SEGV_MAPERR at 0x7fc7a764438
> 
> Crashed Thread:  0
> 
> 
> Thread 0 Crashed:
> 
> 0   libobjc.A.dylib  0x7fff84dcbe5d objc_msgSend +
> 29
> 
> 1   ViewBridge   0x7fff9519ea42
> -[NSVBAccessoryWindow _hierarchyDidChangeInView:] + 69
> 
> 2   AppKit   0x7fff86593aea -[NSView
> _setSuperview:] + 2602
> 
> 3   AppKit   0x7fff86592c28 -[NSView
> addSubview:] + 448
> 
> 4   AppKit   0x7fff865fa754 -[NSWindow
> setContentView:] + 638
> 
> 5   ViewBridge   0x7fff951d1253
> setWindowContentView + 75
> 
> 6   ViewBridge   0x7fff951b5d8b
> -[NSRemoteViewBase setAccessoryView:] + 208
> 
> 7   AppKit   0x7fff86df9ed8
> -[NSVBSavePanel(NSSavePanelSPI) _sendAccessoryView:] + 49
> 
> 80x00010b56e3b0 0x10b4bf000 + 717744
> 
>> On Sat, Jul 18, 2015 at 12:14 AM, Martin Wierschin  wrote:
>> 
>> I just had a beta tester contact me about a very similar error/crash. It's
>> slightly different than I've seen before, but it certainly seems related.
>> 
>> The tester was closing a window backed by NSDocument. In response the
>> AppKit document machinery was attempting to create an NSSavePanel, to allow
>> the user to save or discard the file, but NSRemoteView threw an
>> exception[1].
>> 
>> As I mentioned earlier in this thread, I've come to anticipate this. I now
>> wrap the relevant NSDocument method to catch any exceptions and display a
>> warning alert that the system save panel is (apparently) temporarily
>> unavailable. This time the app crashed while trying to generate that alert;
>> -[NSAlert init] was loading some localized string and crashed[2].
>> 
>> I doubt this is going to be reproducible, but it's reported as
>> rdar://21881669.
>> 
>> ~Martin Wierschin
>> 
>> 
>> [1] INITIAL EXCEPTION:
>> 
>> MyApp[807]: *** Assertion failure in -[NSRemoteView
>> setServiceObject:forKey:],
>> /SourceCache/ViewBridge/ViewBridge-105/NSRemoteView.m:3142
>>failed:  invalid
>>in: NSInternalInconsistencyException line 0
>>STACK TRACE:
>> ...
>> libobjc.A.dylib   objc_exception_throw
>> CoreFoundation+[NSException raise:format:arguments:]
>> Foundation-[NSAssertionHandler
>> handleFailureInMethod:object:file:lineNumber:description:]
>> ViewBridge-[NSRemoteViewBase setServiceObject:forKey:]
>> FoundationNSKeyValueNotifyObserver
>> FoundationNSKeyValueDidChange
>> Foundation-[NSObject(NSKeyValueObserverNotification)
>> didChangeValueForKey:]
>> AppKit-[NSDocument _preparedSavePanelForOperation:]
>> ...
>> AppKit-[NSDocument
>> canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:]
>> AppKit-[NSWindow __close]
>> AppKit-[NSControl sendAction:to:]
>> ...
>> AppKitNSApplicationMain
>> MyApp MyAppMain
>> MyApp start
>> 
>> 
>> 
>> [2] SUBSEQUENT CRASH:
>> 
>> Exception Type:EXC_BAD_ACCESS (SIGSEGV)
>> Exception Codes:   KERN_INVALID_ADDRESS atVM Regions Near:
>> ...
>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
>> 0   com.apple.CoreServices.CarbonCore _CSGetNamedData
>> 1   com.apple.CoreFoundation  _CFPropertyListCopyShared
>> 2   com.apple.CoreFoundation
>> CFBundleCopyLocalizedStringForLocalization
>> 3   com.apple.Foundation  -[NSBundle
>> localizedStringForKey:value:table:]
>> 4   com.apple.AppKit  -[NSAlert init]
>> 5   com.apple.AppKit  +[NSAlert
>> 

Re: Safe time to add accessory view to NSSavePanel in sandboxed app?

[Martin Wierschin]

I just had a beta tester contact me about a very similar error/crash. It's 
slightly different than I've seen before, but it certainly seems related.

The tester was closing a window backed by NSDocument. In response the AppKit 
document machinery was attempting to create an NSSavePanel, to allow the user 
to save or discard the file, but NSRemoteView threw an exception[1]. 

As I mentioned earlier in this thread, I've come to anticipate this. I now wrap 
the relevant NSDocument method to catch any exceptions and display a warning 
alert that the system save panel is (apparently) temporarily unavailable. This 
time the app crashed while trying to generate that alert; -[NSAlert init] was 
loading some localized string and crashed[2].

I doubt this is going to be reproducible, but it's reported as rdar://21881669.

~Martin Wierschin


[1] INITIAL EXCEPTION:

MyApp[807]: *** Assertion failure in -[NSRemoteView setServiceObject:forKey:], 
/SourceCache/ViewBridge/ViewBridge-105/NSRemoteView.m:3142
failed: NSRemoteView: invalid 
in: NSInternalInconsistencyException line 0 
STACK TRACE:
...
 libobjc.A.dylib   objc_exception_throw
 CoreFoundation+[NSException raise:format:arguments:]
 Foundation-[NSAssertionHandler 
handleFailureInMethod:object:file:lineNumber:description:]
 ViewBridge-[NSRemoteViewBase setServiceObject:forKey:]
 FoundationNSKeyValueNotifyObserver
 FoundationNSKeyValueDidChange
 Foundation-[NSObject(NSKeyValueObserverNotification) 
didChangeValueForKey:]
 AppKit-[NSDocument _preparedSavePanelForOperation:]
...
 AppKit-[NSDocument 
canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:]
 AppKit-[NSWindow __close]
 AppKit-[NSControl sendAction:to:]
...
 AppKitNSApplicationMain
 MyApp MyAppMain
 MyApp start



[2] SUBSEQUENT CRASH:

Exception Type:EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:   KERN_INVALID_ADDRESS atVM Regions Near:
...
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.CoreServices.CarbonCore _CSGetNamedData
1   com.apple.CoreFoundation  _CFPropertyListCopyShared
2   com.apple.CoreFoundation  CFBundleCopyLocalizedStringForLocalization
3   com.apple.Foundation  -[NSBundle localizedStringForKey:value:table:]
4   com.apple.AppKit  -[NSAlert init]
5   com.apple.AppKit  +[NSAlert 
alertWithMessageText:defaultButton:alternateButton:otherButton:informativeTextWithFormat:]
6   com.company.myapp __84-[MyApp 
delayedWarnAboutUnavailableSavePanel:]_block_invoke
7   libdispatch.dylib _dispatch_call_block_and_release
8   libdispatch.dylib _dispatch_client_callout
...
17  com.apple.AppKit  -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:]
18  com.apple.AppKit  -[NSApplication run]
19  com.apple.AppKit  NSApplicationMain
20  com.company.myapp MyMain
21  com.company.myapp start



___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Safe time to add accessory view to NSSavePanel in sandboxed app?

[Mike Abdullah]

 On 16 Jul 2015, at 02:33, Graham Cox graham@bigpond.com wrote:
 
 
 Pertinent details below - the line marked com.myapp contains the code 
 listed previously, which is an action method invoked by a menu command.
 
 
 Date/Time: 2015-07-15 10:32:36.027 -0400
 OS Version:Mac OS X 10.10.4 (14E46)
 Report Version:11
 Anonymous UUID:2614ADC0-4001-6CA3-540E-6108024E52C9
 
 Sleep/Wake UUID:   473E70D2-38EF-44CC-B867-61044E46EA90
 
 Time Awake Since Boot: 19 seconds
 Time Since Wake:   2600 seconds
 
 Crashed Thread:0  Dispatch queue: com.apple.main-thread
 
 Exception Type:EXC_BAD_ACCESS (SIGSEGV)
 Exception Codes:   KERN_INVALID_ADDRESS at 0x07f9a74a1988
 
 VM Regions Near 0x7f9a74a1988:
MALLOC_LARGE   00012db2b000-00012dd27000 [ 2032K] rw-/rwx 
 SM=PRV  
 -- 
__TEXT 1234-1234004a5000 [ 4756K] r-x/rwx 
 SM=COW  
 /System/Library/Extensions/AppleIntelHD4000GraphicsGLDriver.bundle/Contents/MacOS/AppleIntelHD4000GraphicsGLDriver
 
 Application Specific Information:
 objc_msgSend() selector name: invalid
 Performing @selector(exportAction:) from sender NSMenuItem 0x7f9a69c27d20
 
 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
 0   libobjc.A.dylib   0x7fff8b5b80dd objc_msgSend + 29
 1   com.apple.AppKit  0x7fff9231bb94 -[NSView 
 _setSuperview:] + 2591
 2   com.apple.AppKit  0x7fff9231ad78 -[NSView 
 addSubview:] + 436
 3   com.apple.AppKit  0x7fff92346432 -[NSWindow 
 setContentView:] + 640
 4   com.apple.ViewBridge  0x7fff93d460c1 setWindowContentView 
 + 75
 5   com.apple.ViewBridge  0x7fff93d34d42 -[NSRemoteViewBase 
 setAccessoryView:] + 208
 6   com.myapp   0x00010ba36a1d 0x10b9ab000 
 + 571933
 7   libsystem_trace.dylib 0x7fff8ba8acd7 
 _os_activity_initiate + 75
 8   com.apple.AppKit  0x7fff92530eb1 -[NSApplication 
 sendAction:to:from:] + 452
 9   com.apple.AppKit  0x7fff92530c4e -[NSMenuItem 
 _corePerformAction] + 382
 10  com.apple.AppKit  0x7fff9253097c -[NSCarbonMenuImpl 
 performActionWithHighlightingForItemAtIndex:] + 114
 11  libsystem_trace.dylib 0x7fff8ba8acd7 
 _os_activity_initiate + 75
 12  com.apple.AppKit  0x7fff925f7b00 -[NSMenu 
 performActionForItemAtIndex:] + 131
 13  com.apple.AppKit  0x7fff925f7a66 -[NSMenu 
 _internalPerformActionForItemAtIndex:] + 35
 14  com.apple.AppKit  0x7fff925f78b2 -[NSCarbonMenuImpl 
 _carbonCommandProcessEvent:handlerCallRef:] + 107
 15  com.apple.AppKit  0x7fff92518d6b 
 NSSLMMenuEventHandler + 724
 16  com.apple.HIToolbox   0x7fff8bc12b6c 
 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 
 1260
 17  com.apple.HIToolbox   0x7fff8bc11fae 
 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, 
 HandlerCallRec*) + 386
 18  com.apple.HIToolbox   0x7fff8bc27cb6 
 SendEventToEventTarget + 40
 19  com.apple.HIToolbox   0x7fff8bc61f45 
 SendHICommandEvent(unsigned int, HICommand const*, unsigned int, unsigned 
 int, unsigned char, void const*, OpaqueEventTargetRef*, 
 OpaqueEventTargetRef*, OpaqueEventRef**) + 428
 20  com.apple.HIToolbox   0x7fff8bc9fb8d 
 SendMenuCommandWithContextAndModifiers + 59
 21  com.apple.HIToolbox   0x7fff8bc9fb30 
 SendMenuItemSelectedEvent + 188
 22  com.apple.HIToolbox   0x7fff8bc9fa09 
 FinishMenuSelection(SelectionData*, MenuResult*, MenuResult*) + 96
 23  com.apple.HIToolbox   0x7fff8bca0481 
 MenuSelectCore(MenuData*, Point, double, unsigned int, OpaqueMenuRef**, 
 unsigned short*) + 702
 24  com.apple.HIToolbox   0x7fff8bca00fe 
 _HandleMenuSelection2 + 446
 25  com.apple.AppKit  0x7fff92436ce0 
 _NSHandleCarbonMenuEvent + 277
 26  com.apple.AppKit  0x7fff9236dbfd _DPSNextEvent + 1828
 27  com.apple.AppKit  0x7fff9236ce58 -[NSApplication 
 nextEventMatchingMask:untilDate:inMode:dequeue:] + 346
 28  com.apple.AppKit  0x7fff92362af3 -[NSApplication run] 
 + 594
 29  com.apple.AppKit  0x7fff922df244 NSApplicationMain + 
 1832

What does your code for setting the accessory view look like? Is it trying to 
be clever and re-use existing accessory views, or is a fresh one created each 
time?


___

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:

Re: Safe time to add accessory view to NSSavePanel in sandboxed app?

[Martin Wierschin]

That logic makes good sense Mike. Unfortunately it doesn't seem to avert the 
crash. My own app, which still encounters this crash from time to time, 
actually already does what you suggest: after the save operation has been 
completed, the accessory view removes itself from the NSSavePanel by calling 
[panel setAccessoryView:nil].

And after reviewing my code, it turns out that my app doesn't recycle/reuse 
accessory view instances after all. I thought it still did, but that was some 
time ago, when the open/save panels were slow as death under sandboxing.

~Martin Wierschin


 My thinking is _setSuperview: seems somewhat a surprising place to crash.
 
 I’m hazarding a guess that the accessory view is not a fresh one, and still 
 has a reference to its previous superview. Apple’s code doesn’t expect that 
 situation, and finds the pointer to the previous superview to be invalid 
 perhaps.
 
 This is Apple’s bug, but if my guess is correct, you could probably work 
 around it by manually _removing_ your accessory view from NSSavePanel once 
 the panel returns, rather than leaving semi-attached there.
 


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Safe time to add accessory view to NSSavePanel in sandboxed app?

[Mike Abdullah]

 On 16 Jul 2015, at 20:30, Martin Wierschin mar...@nisus.com wrote:
 
 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
 0   libobjc.A.dylib 0x7fff8b5b80dd objc_msgSend + 29
 1   com.apple.AppKit0x7fff9231bb94 -[NSView 
 _setSuperview:] + 2591
 2   com.apple.AppKit0x7fff9231ad78 -[NSView 
 addSubview:] + 436
 3   com.apple.AppKit0x7fff92346432 -[NSWindow 
 setContentView:] + 640
 4   com.apple.ViewBridge0x7fff93d460c1 setWindowContentView 
 + 75
 5   com.apple.ViewBridge0x7fff93d34d42 -[NSRemoteViewBase 
 setAccessoryView:] + 208
 6   com.myapp 0x00010ba36a1d 0x10b9ab000 
 + 571933
 
 Is it trying to be clever and re-use existing accessory views, or is a fresh 
 one created each time?
 
 Why do you ask? Is this a known problem?

My thinking is _setSuperview: seems somewhat a surprising place to crash.

I’m hazarding a guess that the accessory view is not a fresh one, and still has 
a reference to its previous superview. Apple’s code doesn’t expect that 
situation, and finds the pointer to the previous superview to be invalid 
perhaps.

This is Apple’s bug, but if my guess is correct, you could probably work around 
it by manually _removing_ your accessory view from NSSavePanel once the panel 
returns, rather than leaving semi-attached there.

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Safe time to add accessory view to NSSavePanel in sandboxed app?

[Martin Wierschin]

I've also seen this crash, as reported by users of my own sandboxed app, though 
I've never reproduced it myself. I've also seen other situations where 
NSSavePanel and NSOpenPanel trigger XPC assertions/exceptions. For example:

 *** Assertion failure in +[NSXPCSharedListener 
 connectionForListenerNamed:fromServiceNamed:], 
 /SourceCache/ViewBridge/ViewBridge-105/NSXPCSharedListener.m:394
 NSXPCSharedListener unable to create endpoint for listener named 
 com.apple.view-bridge

In this situation an instance of NSSavePanel simply could not be created, 
before my accessory view was even requested. This would deadlock my app as the 
NSDocument machinery tried to initiate a save operation– filed as 
rdar://21128102. I managed to prevent the deadlock by catching the exception, 
canceling the save, and alerting the user that OSX's save panel was temporarily 
unavailable. Not the most reassuring of error messages, but better than a hang.

There were a lot of these issues under OSX 10.9. For example -[NSRemoteView 
updateWindowEdgeResizingRegion] would trigger:

 NSRemoteView: 0x7fd8bbd0 is invalid; in: 
 NSInternalInconsistencyException line 0. 


They seemed harmless enough, but filled console logs. I haven't seen them as 
often lately, so hopefully things are improving.

 Is it trying to be clever and re-use existing accessory views, or is a fresh 
 one created each time?

Why do you ask? Is this a known problem? The Apple documentation implies that 
it's safe, as long as you handle the memory management properly:

 If you want to reuse the accessory view, you should not rely on the panel to 
 hold onto the accessory view until the next time you use it; instead, you 
 should maintain your own strong reference to the view.

~Martin Wierschin


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Safe time to add accessory view to NSSavePanel in sandboxed app?

[Graham Cox]

 On 17 Jul 2015, at 6:20 am, Mike Abdullah mabdul...@karelia.com wrote:
 
 Is it trying to be clever and re-use existing accessory views, or is a 
 fresh one created each time?
 
 Why do you ask? Is this a known problem?
 
 My thinking is _setSuperview: seems somewhat a surprising place to crash.
 
 I’m hazarding a guess that the accessory view is not a fresh one, and still 
 has a reference to its previous superview. Apple’s code doesn’t expect that 
 situation, and finds the pointer to the previous superview to be invalid 
 perhaps.
 
 This is Apple’s bug, but if my guess is correct, you could probably work 
 around it by manually _removing_ your accessory view from NSSavePanel once 
 the panel returns, rather than leaving semi-attached there.


In my case the accessory view is reused, in that it’s defined in a nib and 
referenced by an outlet. I keep a strong reference to it so it is ‘owned’ by 
the controller, and added to each save panel as needed. I’m not doing anything 
special to clean up when I’m done with the save panel - I’ll look into whether 
manually removing it and/or clearing the superview reference fixes the problem.

—Graham



___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Safe time to add accessory view to NSSavePanel in sandboxed app?

[Conrad Shultz]

 On Jul 15, 2015, at 3:53 PM, Graham Cox graham@bigpond.com wrote:
 
 This works 99% of the time, but sometimes it just crashes. This seems to 
 occur when the app has just been activated after using a different app, and 
 this save panel is requested within a few seconds of the activation, though 
 that’s a bit of a woolly description because the circumstances make it 
 difficult to reproduce reliably.

Do you have a crash log?

-Conrad
___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Safe time to add accessory view to NSSavePanel in sandboxed app?

[Graham Cox]

 On 16 Jul 2015, at 11:01 am, Conrad Shultz conrad_shu...@apple.com wrote:
 
 
 On Jul 15, 2015, at 3:53 PM, Graham Cox graham@bigpond.com wrote:
 
 This works 99% of the time, but sometimes it just crashes. This seems to 
 occur when the app has just been activated after using a different app, and 
 this save panel is requested within a few seconds of the activation, though 
 that’s a bit of a woolly description because the circumstances make it 
 difficult to reproduce reliably.
 
 Do you have a crash log?
 
 -Conrad


Pertinent details below - the line marked com.myapp contains the code listed 
previously, which is an action method invoked by a menu command.


Date/Time: 2015-07-15 10:32:36.027 -0400
OS Version:Mac OS X 10.10.4 (14E46)
Report Version:11
Anonymous UUID:2614ADC0-4001-6CA3-540E-6108024E52C9

Sleep/Wake UUID:   473E70D2-38EF-44CC-B867-61044E46EA90

Time Awake Since Boot: 19 seconds
Time Since Wake:   2600 seconds

Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:   KERN_INVALID_ADDRESS at 0x07f9a74a1988

VM Regions Near 0x7f9a74a1988:
MALLOC_LARGE   00012db2b000-00012dd27000 [ 2032K] rw-/rwx 
SM=PRV  
-- 
__TEXT 1234-1234004a5000 [ 4756K] r-x/rwx 
SM=COW  
/System/Library/Extensions/AppleIntelHD4000GraphicsGLDriver.bundle/Contents/MacOS/AppleIntelHD4000GraphicsGLDriver

Application Specific Information:
objc_msgSend() selector name: invalid
Performing @selector(exportAction:) from sender NSMenuItem 0x7f9a69c27d20

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib 0x7fff8b5b80dd objc_msgSend + 29
1   com.apple.AppKit0x7fff9231bb94 -[NSView 
_setSuperview:] + 2591
2   com.apple.AppKit0x7fff9231ad78 -[NSView 
addSubview:] + 436
3   com.apple.AppKit0x7fff92346432 -[NSWindow 
setContentView:] + 640
4   com.apple.ViewBridge0x7fff93d460c1 setWindowContentView 
+ 75
5   com.apple.ViewBridge0x7fff93d34d42 -[NSRemoteViewBase 
setAccessoryView:] + 208
6   com.myapp 0x00010ba36a1d 0x10b9ab000 + 571933
7   libsystem_trace.dylib   0x7fff8ba8acd7 
_os_activity_initiate + 75
8   com.apple.AppKit0x7fff92530eb1 -[NSApplication 
sendAction:to:from:] + 452
9   com.apple.AppKit0x7fff92530c4e -[NSMenuItem 
_corePerformAction] + 382
10  com.apple.AppKit0x7fff9253097c -[NSCarbonMenuImpl 
performActionWithHighlightingForItemAtIndex:] + 114
11  libsystem_trace.dylib   0x7fff8ba8acd7 
_os_activity_initiate + 75
12  com.apple.AppKit0x7fff925f7b00 -[NSMenu 
performActionForItemAtIndex:] + 131
13  com.apple.AppKit0x7fff925f7a66 -[NSMenu 
_internalPerformActionForItemAtIndex:] + 35
14  com.apple.AppKit0x7fff925f78b2 -[NSCarbonMenuImpl 
_carbonCommandProcessEvent:handlerCallRef:] + 107
15  com.apple.AppKit0x7fff92518d6b 
NSSLMMenuEventHandler + 724
16  com.apple.HIToolbox 0x7fff8bc12b6c 
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 
1260
17  com.apple.HIToolbox 0x7fff8bc11fae 
SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, 
HandlerCallRec*) + 386
18  com.apple.HIToolbox 0x7fff8bc27cb6 
SendEventToEventTarget + 40
19  com.apple.HIToolbox 0x7fff8bc61f45 
SendHICommandEvent(unsigned int, HICommand const*, unsigned int, unsigned int, 
unsigned char, void const*, OpaqueEventTargetRef*, OpaqueEventTargetRef*, 
OpaqueEventRef**) + 428
20  com.apple.HIToolbox 0x7fff8bc9fb8d 
SendMenuCommandWithContextAndModifiers + 59
21  com.apple.HIToolbox 0x7fff8bc9fb30 
SendMenuItemSelectedEvent + 188
22  com.apple.HIToolbox 0x7fff8bc9fa09 
FinishMenuSelection(SelectionData*, MenuResult*, MenuResult*) + 96
23  com.apple.HIToolbox 0x7fff8bca0481 
MenuSelectCore(MenuData*, Point, double, unsigned int, OpaqueMenuRef**, 
unsigned short*) + 702
24  com.apple.HIToolbox 0x7fff8bca00fe 
_HandleMenuSelection2 + 446
25  com.apple.AppKit0x7fff92436ce0 
_NSHandleCarbonMenuEvent + 277
26  com.apple.AppKit0x7fff9236dbfd _DPSNextEvent + 1828
27  com.apple.AppKit0x7fff9236ce58 -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:] + 346
28  com.apple.AppKit0x7fff92362af3 -[NSApplication run] 
+ 594
29  com.apple.AppKit0x7fff922df244 NSApplicationMain + 
1832


___