Date   

Re: Crash, but only in release version

John Brownie
 

Of course, as soon as I sent the message, I figured out a way to do the debugging, by setting the optimisation level for the debug version. So now I can see where the problem is, sort of.

It's weird. I unwrapped a bunch of macros and an inline function to get the various components visible in the debugger, and it works, but doesn't if I leave the macros and inline function there. Something strange in the optimiser, perhaps? I guess I'll leave the unwrapped version there since it works, and go from there.

John

Alex Zavatone via groups.io wrote on 20/4/20 14:46:

One thing I forgot is if you are debugging a release version (I expect that this is a Mac app), you may want to make sure that you are not stripping debug symbols.  

On Apr 20, 2020, at 6:44 AM, Alex Zavatone via groups.io <zav@...> wrote:

Report the properties of the URL beforehand.  At one case, I even had my old reporter get the properties, put them in a string and mail them to a specific email account to see what was going on.

You can also log to a specific file on disk and then open that up and tail it from the terminal to get only your specific output written to that file and updated instantly on screen right before the crash.



On Apr 20, 2020, at 6:22 AM, John Brownie <john_brownie@...> wrote:

I am getting a crash, but only in the release version. I get a very helpful "Error 1" if I try to debug the release version, and logging doesn't get me anything, as the crash prevents the log entry from appearing (I think).

Anyway, the crash is in CFURLCreateWithFileSystemPath, where it's calling length, and I get crash reports like the following:

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [40981]

VM Regions Near 0x3eaddd9f4338:
   MALLOC_LARGE_REUSABLE  0000000113885000-0000000114085000 [ 8192K] rw-/rwx SM=PRV
-->
   MALLOC_NANO            0000600000000000-0000600008000000 [128.0M] rw-/rwx SM=PRV

Application Specific Information:
objc_msgSend() selector name: length


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib                   0x00007fff6e14381d objc_msgSend + 29
1   com.apple.CoreFoundation          0x00007fff3544dfb5 _CFURLCreateWithFileSystemPath + 67

The VM Regions list can vary a bit, but it's always the same stack trace and signal.

It looks a bit weird that a Core Foundation function is trying to call an Objective-C method. Ironically, this crash is triggered when I'm attempting to show the user an error message, and the upstream call is essentially a call to get a localized version of a string.

Any pointers on how to debug this? How to get the debugger to connect with the release version? Or how to work out what is different between the release and debug versions that might be forcing the error?

Thanks,
John
-- 
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland







--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Re: Crash, but only in release version

Alex Zavatone
 

One thing I forgot is if you are debugging a release version (I expect that this is a Mac app), you may want to make sure that you are not stripping debug symbols.  

On Apr 20, 2020, at 6:44 AM, Alex Zavatone via groups.io <zav@...> wrote:

Report the properties of the URL beforehand.  At one case, I even had my old reporter get the properties, put them in a string and mail them to a specific email account to see what was going on.

You can also log to a specific file on disk and then open that up and tail it from the terminal to get only your specific output written to that file and updated instantly on screen right before the crash.



On Apr 20, 2020, at 6:22 AM, John Brownie <john_brownie@...> wrote:

I am getting a crash, but only in the release version. I get a very helpful "Error 1" if I try to debug the release version, and logging doesn't get me anything, as the crash prevents the log entry from appearing (I think).

Anyway, the crash is in CFURLCreateWithFileSystemPath, where it's calling length, and I get crash reports like the following:

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [40981]

VM Regions Near 0x3eaddd9f4338:
   MALLOC_LARGE_REUSABLE  0000000113885000-0000000114085000 [ 8192K] rw-/rwx SM=PRV
-->
   MALLOC_NANO            0000600000000000-0000600008000000 [128.0M] rw-/rwx SM=PRV

Application Specific Information:
objc_msgSend() selector name: length


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib                   0x00007fff6e14381d objc_msgSend + 29
1   com.apple.CoreFoundation          0x00007fff3544dfb5 _CFURLCreateWithFileSystemPath + 67

The VM Regions list can vary a bit, but it's always the same stack trace and signal.

It looks a bit weird that a Core Foundation function is trying to call an Objective-C method. Ironically, this crash is triggered when I'm attempting to show the user an error message, and the upstream call is essentially a call to get a localized version of a string.

Any pointers on how to debug this? How to get the debugger to connect with the release version? Or how to work out what is different between the release and debug versions that might be forcing the error?

Thanks,
John
-- 
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland







Re: Crash, but only in release version

Alex Zavatone
 

Report the properties of the URL beforehand. At one case, I even had my old reporter get the properties, put them in a string and mail them to a specific email account to see what was going on.

You can also log to a specific file on disk and then open that up and tail it from the terminal to get only your specific output written to that file and updated instantly on screen right before the crash.

On Apr 20, 2020, at 6:22 AM, John Brownie <john_brownie@sil.org> wrote:

I am getting a crash, but only in the release version. I get a very helpful "Error 1" if I try to debug the release version, and logging doesn't get me anything, as the crash prevents the log entry from appearing (I think).

Anyway, the crash is in CFURLCreateWithFileSystemPath, where it's calling length, and I get crash reports like the following:

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [40981]

VM Regions Near 0x3eaddd9f4338:
MALLOC_LARGE_REUSABLE 0000000113885000-0000000114085000 [ 8192K] rw-/rwx SM=PRV
-->
MALLOC_NANO 0000600000000000-0000600008000000 [128.0M] rw-/rwx SM=PRV

Application Specific Information:
objc_msgSend() selector name: length


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x00007fff6e14381d objc_msgSend + 29
1 com.apple.CoreFoundation 0x00007fff3544dfb5 _CFURLCreateWithFileSystemPath + 67

The VM Regions list can vary a bit, but it's always the same stack trace and signal.

It looks a bit weird that a Core Foundation function is trying to call an Objective-C method. Ironically, this crash is triggered when I'm attempting to show the user an error message, and the upstream call is essentially a call to get a localized version of a string.

Any pointers on how to debug this? How to get the debugger to connect with the release version? Or how to work out what is different between the release and debug versions that might be forcing the error?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland



Crash, but only in release version

John Brownie
 

I am getting a crash, but only in the release version. I get a very helpful "Error 1" if I try to debug the release version, and logging doesn't get me anything, as the crash prevents the log entry from appearing (I think).

Anyway, the crash is in CFURLCreateWithFileSystemPath, where it's calling length, and I get crash reports like the following:

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [40981]

VM Regions Near 0x3eaddd9f4338:
    MALLOC_LARGE_REUSABLE  0000000113885000-0000000114085000 [ 8192K] rw-/rwx SM=PRV
-->
    MALLOC_NANO            0000600000000000-0000600008000000 [128.0M] rw-/rwx SM=PRV

Application Specific Information:
objc_msgSend() selector name: length


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib                   0x00007fff6e14381d objc_msgSend + 29
1   com.apple.CoreFoundation          0x00007fff3544dfb5 _CFURLCreateWithFileSystemPath + 67

The VM Regions list can vary a bit, but it's always the same stack trace and signal.

It looks a bit weird that a Core Foundation function is trying to call an Objective-C method. Ironically, this crash is triggered when I'm attempting to show the user an error message, and the upstream call is essentially a call to get a localized version of a string.

Any pointers on how to debug this? How to get the debugger to connect with the release version? Or how to work out what is different between the release and debug versions that might be forcing the error?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Re: Strange controls behaviour in sheet modal window

jader.feijo@...
 

Hi Graham,

I have just encountered this exact same issue, and indeed, keeping a copy around of my window solved the issue. The approach that I took was a little different though and did not require me to create a property in the caller, but rather I managed to find a way to do it all locally.

So, my panel NSWindowController has a method which allows it to be presented in another NSWindow as a panel, here's what the method signature looks like (in Swift):
@objc func presentInWindow(_ window: NSWindow, callback: @escaping FileFormatSelectionResult)
Where FileFormatSelectionResult is a closure defined as:
typealias FileFormatSelectionResult = (SelectedFormat, Bool) -> Void
The closure is stored inside my NSWindowController instance until such time as the user makes a selection (Cancel or Import) which dismisses the sheet. After the sheet is dismissed, the callback closure is called.

This allowed me to write the following code in the caller (in Objective-C) which keeps the sheet NSWindowController around for the duration of the interaction:
__block FileFormatSelectionWindowController *fileFormatSelectionController = [[FileFormatSelectionWindowController alloc] initWithWindowNibName:@"FileFormatSelectionWindow"];
[fileFormatSelectionController presentInWindow:[[document mainWindowController] window] callback:^(enum SelectedFormat format, BOOL cancelled) {
if (!cancelled) {
// do something with the result
}
fileFormatSelectionController = nil;
}];
The __block variable for the panel NSWindowController instance allows the block to capture it, and set it to nil at the end of the interaction, without the need to introduce a property or a local variable in the caller. The same could be accomplished in Swift as well.

I thought I'd post this here in case someone else runs into this issue and needs a simple approach to solving it.

Hope it helps.


Re: String handling not working — am I going nuts?

 



On Apr 6, 2020, at 4:53 PM, Marco S Hyman <marc@...> wrote:

var str = try String(contentsOf: urlContext.url) // (1)
let lines = str.split(separator: “\r\n”) // (3)

works and is faster in that you’ve removed an O(n) operation,

You've also removed support for Unix line endings. Now it only supports Windows line endings; probably a bad idea.



On Apr 7, 2020, at 10:30 AM, Rick Aurbach via groups.io <rlaurb@...> wrote:

So I have a solution, but I don’t understand the original code didn’t work. Any insights?

I'm mystified too, but IMHO enumerateLines is a better way to do it.

—Jens


Re: String handling not working — am I going nuts?

Rick Aurbach
 

Ok, I still don’t understand what’s going on, but I’ve got an alternative solution. (Maybe somebody can clarify this for me??)

WHAT DOESN’T WORK IN MY CONTEXT:

do {
    var str = try String(contentsOf: urlContext.url)
    str.removeAll { $0 == “\r” }
    let lines = str.split(separator: “\n”)
   …
} catch {}

BUT THE FOLLOWING WORKS NICELY::

var lines = [String]()
do {
    let str = try String(contentsOf: urlContext.url)
    str.enumerateLines { (line, stop) in
        lines.append(line)
        stop = false
    }
} catch {}

Note: since enumerateLines is not labeled ’throws’, Xcode complains if I try to throw from it’s closure. So instead of working one line at a time within the closure, I need to build a line array and then process it (one line at a time) in a second do-block.

So I have a solution, but I don’t understand the original code didn’t work. Any insights?

Cheers,

Rick Aurbach


Re: manual item enabling

Graham Cox
 

Hi Kurt, re-reading the documentation on basic event handling might help:

particularly “The Path of Key Events”, and “Handling Key Equivalents"

Note that I mentioned NSResponder. Both NSApplication and NSView both subclass NSResponder, so there are two very different objects that receive events. I was thinking about this in terms of NSView, but NSApplication does things a little differently.

but if keyDown is what calls performKeyEquivalent, then how could performKeyEquivalent help

NSApplication’s -sendEvent: calls -performKeyEquivalent: but AFAICS, no -keyDown: method ever calls it - it’s always handled before that is called.

It’s still a little unclear to me why the standard approach that Cocoa takes to menu updating can’t be used here. In both the key equivalent case and the click on the menu case, the responder chain is asked to -validateMenuItem: for as many menu items as needed (I would expect this to be just one for a key equivalent), and you just return YES or NO to indicate the enable state of the item. But that validation method is free to examine any other property of the menu item, so if there is some legacy there of command numbers or whatever, the validation method can use it. The validation method can also change the text of a menu item.

Now I recall that in TCL, the whole menu structure (per menu? I forget now) was passed to the responder chain so it was less granular than Cocoa, so the update mechanism would enable a whole bunch of items at once. Is my understanding correct that you’d rather port that code more or less “as is”? In which case possibly the menu delegate approach is going to be more appropriate than validating individual items.

But I would suggest that handling individual items is not so very different - it’s the same concept, just broken down a little more so that you deal with one item at a time. In fact your code is generally written so that that multiple-calling situation is irrelevant. The same validation method handles ALL the cases pertaining to the current responder object, just as the TCL update method does. It’s just that the Cocoa method is called multiple times, but only one case applies, and the TCL method is called only once, but multiple cases apply. The difference between the two is actually minor. In the cocoa case, you just need to add an additional if() per item that checks that the passed item is actually the one you want.

so for example, in the TCL case, you’d have had code that was equivalent to:

- (void) updateMenu:(CMenu*) menu
{
menu.items[kNewItem].enable = YES;
menu.items[kOpenItem].enable = YES;
menu.items[kQuitItem].enable = YES;

[nextResponder updateMenu:menu];
}

and in Cocoa, you change that to:

- (BOOL) validateMenuItem:(NSMenuItem*) item
{
if( item.command == kNewItem )
return YES;

if( item.command == kOpenItem )
return YES;

if( item.command == kQuitItem )
return YES;

return [nextResponder validateMenuItem:item];
}

Note this is just conceptual code - there is no method on NSMenuItem called -command. So you’d have to deal with that difference, or use the menu item's -action property instead, which is the usual way.

So in my view, you’re overthinking this. Just let Cocoa do its thing and adapt the validation to suit rather than try to stick with your TCL approach and adapt the event handling to suit.

Of course I don’t have your code in front of me, so this may be off base.

—Graham





On 7 Apr 2020, at 10:47 am, Kurt Bigler <kkblists@...> wrote:

Hi,

Thanks Eric, Allan, and Graham for your help on this last November 24-25.  This issue got pushed into the background and I'm only now getting back to it.  I'm replying specifically to Graham's post due to the specifics I'm addressing.

I did not yet take Eric's advice to use menuNeedsUpdate since I'd like to take a shortcut for an interrim release we'd now like to do ASAP.  So this addresses that shortcut described by both Graham and Allan.

I used the approach of overriding NSMenu for the main app menu.  I update menus in the performKeyEquivalent override before calling super.  It does not help.

Curiously also and by implication in contrast with what Graham stated, I'm seeing performKeyEquivalent gets called from within my application-level override of sendEvent, where I added code conditional on [event type] == NSKeyDown prior to [super sendEvent...].  I use that code now just to log the occurrence.  But previously I had tried updating menus there, which also did not work.

So to state the obvious, if per Graham, "key equivalents are pulled out before -keyDown" but if keyDown is what calls performKeyEquivalent, then how could performKeyEquivalent help?  In fact it doesn't.  But I also see Graham mentioning views as possible places to trap performKeyEquivalent and I also wonder whether there is something about that that I'm missing.

Thanks!

-Kurt


On 11/24/19 2:58:17 PM, Graham Cox wrote:
Kurt,
The menu key equivalents are pulled out before -keyDown: is called. You can override that event in -performKeyEquivalent:, a methof of NSResponder (and therefore views, etc). You can probably call your menu update method and then call super to handle the key equivalent.
[...]
—Graham
On 25 Nov 2019, at 8:28 am, Kurt Bigler via Cocoa-dev <cocoa-dev@...> wrote:

The last possible moment for key equivalents is a keyDown event. Unfortunately Cocoa doesn't seem to let me catch this event and act on it to update menus prior to key equivalent processing.

-Kurt Bigler



Re: String handling not working — am I going nuts?

Marco S Hyman
 

do {
var str = try String(contentsOf: urlContext.url) // (1)
str.removeAll { $0 == “\r” } // (2)
let lines = str.split(separator: “\n”) // (3)
Oh. Yeah. That’s too much work.


var str = try String(contentsOf: urlContext.url) // (1)
let lines = str.split(separator: “\r\n”) // (3)

works and is faster in that you’ve removed an O(n) operation,

I created your test file with crlf end-of-line (thank you bbedit) and tried it using this code in a playground:

let url = URL(fileURLWithPath: “/path/to.foo.txt”)
if let str = try? String(contentsOf: url) {
let lines = str.split(separator: "\r\n") // (3)
print(lines)
}

Marc


Re: String handling not working — am I going nuts?

 

Doesn't Swift's String class have higher-level methods to break a string by lines? NSString certainly did.

—Jens


Re: String handling not working — am I going nuts?

Marco S Hyman
 

On Apr 6, 2020, at 3:29 PM, Rick Aurbach via groups.io <rlaurb=me.com@groups.io> wrote:

The file is UTF8, with lines terminated in “\r\n”
Are the lines terminated with a carriage return/line feed pair or are they terminated with the character string "\r\n”. The results of step 2 and 3 are what I’d expect if the string contained the character string \r\n instead of a carriage return/line feed pair.


String handling not working — am I going nuts?

Rick Aurbach
 

Can you take a look at this for me? I think I’ve been cooped up at home too long, because whatever is going on, I’m missing it.
 
Context:
I’m working on a data import function for a new app. It looks like I’ve set things up correctly, since if I drop the file (from my desktop to the Simulator), the sceneDelegate’s scene(_:openURLContexts:) method is called. I set up an operations queue to handle the input in background and instantiate the Operation subclass, passing it a URLContext.
 
In the Operation subclass’s main() method, I do the following:
 
do {
var str = try String(contentsOf: urlContext.url) // (1)
str.removeAll {  $0 == “\r” } // (2)
let lines = str.split(separator: “\n”) // (3)
 
The file is UTF8, with lines terminated in “\r\n”
 
After executing (1), the debugger shows:
 
str String "sugar,NO\r\n1/1/20,154\r\n1/2/20,141\r\n1/3/20,147\r\n1/4/20,154\r\n1/5/20,172\r\n1/6/20,170\r\n1/7/20,164\r\n1/8/20,201\r\n1/9/20,163\r\n1/10/20,171\r\n1/11/20,209\r\n1/12/20,202\r\n1/13/20,164\r\n1/14/20,232\r\n1/15/20,182\r\n1/16/20,211\r\n1/17/20,175\r\n1/18/20,174\r\n1/19/20,147\r\n1/20/20,148\r\n1/21/20,150\r\n1/22/20,141\r\n1/23/20,165\r\n1/24/20,169\r\n1/25/20,260\r\n1/26/20,168\r\n1/27/20,179\r\n1/28/20,160\r\n1/29/20,155\r\n1/30/20,181\r\n1/31/20,156\r\n2/1/20,178\r\n2/2/20,202\r\n2/3/20,188\r\n2/4/20,175\r\n2/5/20,157\r\n2/6/20,166\r\n2/7/20,165\r\n2/8/20,146\r\n2/9/20,192\r\n2/10/20,178\r\n2/11/20,172\r\n2/12/20,180\r\n2/13/20,140”
 
which is what I expect.
 
After executing (2), the string is UNCHANGED. (i.e., the “\r” characters were not removed.
 
After executing (3), the ‘lines’ variable contains 1 item which is the whole string (with both the “\r” and “\n” characters present.
 
I’m going nuts here. What’s going on??

Cheers,

Rick Aurbach


Clicking in SwiftUI View

Gerriet M. Denkmann
 

macOS 15.4

I have a SwiftUI ContentView, which contains a few vertically stacked Views.

For one of these I need the following functionality:
when the mouse moves inside the view, or when the view is clicked (or option clicked or whatsoever) I want to get notified of the mouse location in this view.

There is “onHover”, but this only tells me, whether the mouse has entered or left my view.

Then there is “onTapGesture”, which compiles, but never gets activated.

So: how to recognise mouse clicks in SwiftUI?

struct ContentView: View
{
VStack
{


ZStack
{
… draws a few Paths
}
.onTapGesture(perform: {print(#function)}) // never seen
.onHover()
{ pp in
print(“ ZStack \(pp ? "entered" : "left")")
}

...
}
}

Gerriet.


Re: Canceling NSSavePanel Hang App

Rafael Bugajewski
 

Hi Sandor,

from the stacks it looks like you’ve Finder Extensions installed on your system. Can you disable / uninstall them and verify if the issue is still reproducible?

Best,
Rafał

On 2020-01-04, at 11:31 PM, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

Ran into an interesting issue today…
Mac app
Xcode 9.4.1, 32bit, 10.12 SDK, 10.6 Deployment Target
non-sandboxed app

I am opening an NSSavePanel to allow a user to save the results of a report that is to be generated.

// Creating the save panel
NSSavePanel* savePanel = [NSSavePanel savePanel];
[savePanel setTitle:[NSString stringWithFormat:@"Export %@ Summary Data for %@", [self selectedReport], customerName]];

Opening the NSSavePanel using -runModal
savePanelUserAction = [savePanel runModal];

If the user enters a filename and clicks continue the save dialog closes, the report is generated, and the file is written to disk at the selected location.
if (savePanelUserAction == NSFileHandlingPanelOKButton)
[NSThread detachNewThreadSelector:@selector(createSummary:) toTarget:self withObject:[[savePanel URL] path]];

If the user clicks cancel, the program hangs. It hangs so badly that I have to go to the System Force-Quit dialog in order to fully terminate the app.
(i.e. Clicking stop program in Xcode does not fully terminate the app)
else
{
// Program hangs
}

I have checked that the NSSavePanel is being opened from the main thread.
I have included interesting backtraces below that are present if I stop the app in the de

Sandor

Thread 1 Queue : com.apple.main-thread (serial)
#0 0xa73d423e in kevent_id ()
#1 0x003305a6 in _dispatch_kq_poll ()
#2 0x00331141 in _dispatch_event_loop_wait_for_ownership ()
#3 0x00327b80 in _dispatch_sync_wait ()
#4 0x0031d500 in _dispatch_sync_f_slow ()
#5 0x0030f6d1 in dispatch_barrier_sync_f ()
#6 0x00316bf3 in dispatch_barrier_sync ()
#7 0x9387ebd4 in _VolumeObserverInvalidate ()
#8 0xa04ee78e in TSystemNotificationTask::~TSystemNotificationTask() ()
#9 0xa04ee818 in TSystemNotificationTask::FinalizeSystemNotificationTask() ()
#10 0xa04dda71 in NodeContextClose ()
#11 0x0afc689a in TFENode::Finalize() ()
#12 0x0b127290 in +[FIFinderViewGutsController finalizeCounted] ()
#13 0x0b127366 in __45+[FIFinderViewGutsController finalizeCounted]_block_invoke ()
#14 0x003167af in _dispatch_call_block_and_release ()
#15 0x0030e94d in _dispatch_client_callout ()
#16 0x0031ae6c in _dispatch_main_queue_callback_4CF ()
#17 0x937bb2ae in __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ ()
#18 0x9377ecf4 in __CFRunLoopRun ()
#19 0x9377dbd1 in CFRunLoopRunSpecific ()
#20 0x9377d93a in CFRunLoopRunInMode ()
#21 0x92d7b37b in RunCurrentEventLoopInMode ()
#22 0x92d7b0a2 in ReceiveNextEventCommon ()
#23 0x92d7ad7b in _BlockUntilNextEventMatchingListInModeWithFilter ()
#24 0x9137aafd in _DPSNextEvent ()
#25 0x91aece90 in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] ()
#26 0x91aec35d in -[NSApplication(NSEvent) nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#27 0x9136fa4d in -[NSApplication run] ()
#28 0x91341b0a in NSApplicationMain ()
#29 0x000026bc in main at /Users/username/repo/AppName/main.m:13
#30 0x00002685 in start ()
Enqueued from TBrowserViewDataSource (Thread 14) Queue : TBrowserViewDataSource (serial)
#0 0x0033f4dc in _dispatch_introspection_queue_item_enqueue ()
#1 0x00325cf8 in _dispatch_queue_push ()
#2 0x00323230 in _dispatch_continuation_push ()
#3 0x0032259b in _dispatch_continuation_async ()
#4 0x00316173 in dispatch_async ()
#5 0x0b1272f6 in +[FIFinderViewGutsController finalizeCounted] ()
#6 0x0b1aa3af in -[FI_TBrowserViewDataSource dealloc] ()
#7 0xa67a09f9 in objc_object::sidetable_release(bool) ()
#8 0xa679e2d0 in -[NSObject release] ()
#9 0x0b1aa762 in __destroy_helper_block_ ()
#10 0xa72c6b75 in _Block_release ()
#11 0x0030e94d in _dispatch_client_callout ()
#12 0x00324d3a in _dispatch_queue_serial_drain ()
#13 0x003162e2 in _dispatch_queue_invoke ()
#14 0x0032646e in _dispatch_root_queue_drain_deferred_wlh ()
#15 0x0032b4bb in _dispatch_workloop_worker_thread ()
#16 0x00381601 in _pthread_wqthread ()
#17 0x0038121e in start_wqthread ()
Enqueued from com.apple.main-thread (Thread 1) Queue : com.apple.main-thread (serial)
#0 0x0033f4dc in _dispatch_introspection_queue_item_enqueue ()
#1 0x00325cf8 in _dispatch_queue_push ()
#2 0x00323230 in _dispatch_continuation_push ()
#3 0x0032259b in _dispatch_continuation_async ()
#4 0x00316173 in dispatch_async ()
#5 0x0b1aa460 in -[FI_TBrowserViewDataSource aboutToTearDown] ()
#6 0x0b1e0aa5 in -[FI_TBrowserContainerController destroyBrowserView:] ()
#7 0x0b1e3ed4 in -[FIContainerController destroyBrowserView:] ()
#8 0x0b1e06c6 in -[FI_TBrowserContainerController aboutToTearDown] ()
#9 0x0b1e3f3b in -[FIContainerController aboutToTearDown] ()
#10 0xa67a0bda in -[NSObject performSelector:] ()
#11 0x0b042f47 in AboutToTearDownViewController(NSViewController*) ()
#12 0x0b07a83c in -[FI_TBrowserContentViewController aboutToTearDown] ()
#13 0xa67a0bda in -[NSObject performSelector:] ()
#14 0x0b042f47 in AboutToTearDownViewController(NSViewController*) ()
#15 0x0b1293f0 in -[FIFinderViewGutsController prepareToHide] ()
#16 0x0b12996f in -[FIFinderViewGutsController windowOrderedOut] ()
#17 0x0b13486f in -[FIFinderView windowOrderedOut] ()
#18 0x91e3ffe5 in -[NSNavFinderViewFileBrowser windowOrderedOut] ()
#19 0x91a4df5e in -[NSSavePanel _navViewWindowOrderedOut] ()
#20 0x91a4dfc5 in -[NSSavePanel orderOut:] ()
#21 0x91a5bffa in -[NSSavePanel _didEndSheet:returnCode:contextInfo:] ()
#22 0x91c27b17 in NSWindowEndWindowModalSession ()
#23 0x915acaf6 in -[NSWindow _endWindowBlockingModalSession:returnCode:] ()
#24 0x915aca86 in -[NSWindow endSheet:returnCode:] ()
#25 0x915f7367 in -[NSApplication endSheet:returnCode:] ()
#26 0x91a5e2cb in -[NSSavePanel _dismissWindowWithReturnCode:willRunSeamlessOpening:] ()
#27 0x91a5e2f1 in -[NSSavePanel _cancelAndClose] ()
#28 0x91a5e933 in -[NSSavePanel cancel:] ()
#29 0xa67a0c1c in -[NSObject performSelector:withObject:] ()
#30 0x91aeeca9 in __49-[NSApplication(NSResponder) sendAction:to:from:]_block_invoke ()
#31 0x91aeec4d in __NS_ACTIVITY_PERFORM_EXCEPTION_SAFE ()
#32 0x91aeeb4f in -[NSApplication(NSResponder) sendAction:to:from:] ()
#33 0x9159eda8 in -[NSControl sendAction:to:] ()
#34 0x9159ecc7 in __26-[NSCell _sendActionFrom:]_block_invoke ()
#35 0x917e5009 in __NS_ACTIVITY_PERFORM_EXCEPTION_SAFE ()
#36 0x9159ec11 in -[NSCell _sendActionFrom:] ()
#37 0x915dd6cb in -[NSButtonCell _sendActionFrom:] ()
#38 0x917e6e2c in __48-[NSCell trackMouse:inRect:ofView:untilMouseUp:]_block_invoke.1099 ()
#39 0x917e5009 in __NS_ACTIVITY_PERFORM_EXCEPTION_SAFE ()
#40 0x9159d58d in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] ()
#41 0x915dd420 in -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] ()
#42 0x9159bff4 in -[NSControl mouseDown:] ()
#43 0x91c922b4 in -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] ()
#44 0x91c9024f in -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] ()
#45 0x91c8e4c0 in -[NSWindow(NSEventRouting) sendEvent:] ()
#46 0x91aeb2d5 in -[NSApplication(NSEvent) sendEvent:] ()
#47 0x9136fa98 in -[NSApplication run] ()
#48 0x91341b0a in NSApplicationMain ()
#49 0x000026bc in main at /Users/username/repo/AppName/main.m:13
#50 0x00002685 in start ()


// Other threads that seemed interesting, but could be misleading???

Thread 2 Queue : com.apple.CFVolumeObserver.0x6af670 (serial)
#0 0xa73d242a in __getattrlist ()
#1 0x9ffa770f in volumePropertyProviderPrepareValues(__CFURL const*, __FileCache*, __CFString const* const*, void const**, long, void const*, __CFError**) ()
#2 0x9ffa1ebd in prepareValuesForBitmap(__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**) ()
#3 0x9ff9f858 in _FSURLCopyResourcePropertyForKeyInternal(__CFURL const*, __CFString const*, void*, void*, __CFError**, unsigned char) ()
#4 0x9ff9f779 in _FSURLCopyResourcePropertyForKey ()
#5 0x93765cd0 in CFURLCopyResourcePropertyForKey ()
#6 0x937dfaf6 in _VolumeObserverDiskAppearedCallback ()
#7 0x9513f6ab in _DADispatchCallback ()
#8 0x9513f439 in _DASessionCallback ()
#9 0x9513f304 in __DASessionSetDispatchQueue_block_invoke_2 ()
#10 0x0030e94d in _dispatch_client_callout ()
#11 0x00323464 in _dispatch_continuation_pop ()
#12 0x00310eba in _dispatch_source_invoke ()
#13 0x00324b73 in _dispatch_queue_serial_drain ()
#14 0x003162e2 in _dispatch_queue_invoke ()
#15 0x0032646e in _dispatch_root_queue_drain_deferred_wlh ()
#16 0x0032b4bb in _dispatch_workloop_worker_thread ()
#17 0x00381601 in _pthread_wqthread ()
#18 0x0038121e in start_wqthread ()


Thread 10 Queue : com.apple.CFVolumeObserver.0x6ac5d0 (serial)
#0 0xa73d242a in __getattrlist ()
#1 0x9ffa770f in volumePropertyProviderPrepareValues(__CFURL const*, __FileCache*, __CFString const* const*, void const**, long, void const*, __CFError**) ()
#2 0x9ffa1ebd in prepareValuesForBitmap(__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**) ()
#3 0x9ff9f858 in _FSURLCopyResourcePropertyForKeyInternal(__CFURL const*, __CFString const*, void*, void*, __CFError**, unsigned char) ()
#4 0x9ff9f779 in _FSURLCopyResourcePropertyForKey ()
#5 0x93765cd0 in CFURLCopyResourcePropertyForKey ()
#6 0x937dfaf6 in _VolumeObserverDiskAppearedCallback ()
#7 0x9513f6ab in _DADispatchCallback ()
#8 0x9513f439 in _DASessionCallback ()
#9 0x9513f304 in __DASessionSetDispatchQueue_block_invoke_2 ()
#10 0x0030e94d in _dispatch_client_callout ()
#11 0x00323464 in _dispatch_continuation_pop ()
#12 0x00310eba in _dispatch_source_invoke ()
#13 0x00324b73 in _dispatch_queue_serial_drain ()
#14 0x003162e2 in _dispatch_queue_invoke ()
#15 0x0032646e in _dispatch_root_queue_drain_deferred_wlh ()
#16 0x0032b4bb in _dispatch_workloop_worker_thread ()
#17 0x00381601 in _pthread_wqthread ()
#18 0x0038121e in start_wqthread ()


Re: Canceling NSSavePanel Hang App

Sandor Szatmari
 

Thanks Sak,

My discovery seemed random and unsettling, so I kept digging.  I will read the docs you’re referring to But a sheet does seem to do the trick.  What’s weird is this code has worked for years, so it must be some changes to the SDK I am updating to.


Sandor

On Apr 2, 2020, at 14:31, Sak Wathanasin <sw@...> wrote:



On 2 Apr 2020, at 18:54, Sandor Szatmari <admin.szatmari.net@...> wrote:

Took a guess and enabled sandbox and added read/write to user selected file and the hang went away.  Is it true that I cannot make an unsandboxed app and uses the NSSavePanel?  I know this is a data point of one, so I want to be careful what conclusions I draw… any thoughts?

No, I have a non-sandboxed app and it works fine. I think the problem is that you are using NSSavePanel:runModal. If you look in the doc'n, it says:

"This method invokes NSApplication's runModalForWindow ..."

If it's doing that, then you need to cancel the modal yourslef (as with any call of runModalForWindow). Try putting a

[NSApp stopModalWithCode:NSModalResponseCancel];

in your "else" clause.

However, it may be simpler to use a sheet modal:
...setup code...
    [panel beginSheetModalForWindow:owningWindow
                  completionHandler:^(NSInteger result){
                      if (result == NSFileHandlingPanelOKButton)
                      {
                          self.saveFileURL = [[panel URLs] objectAtIndex:0];
                          [self writeToFileAtURL:self.saveFileURL];
                      }
                  }
     ];

You can spin the writing to a file off to a separate thread if it takes a long time.

Hope this helps,

Sak



Re: Canceling NSSavePanel Hang App

Sak Wathanasin
 



On 2 Apr 2020, at 18:54, Sandor Szatmari <admin.szatmari.net@...> wrote:

Took a guess and enabled sandbox and added read/write to user selected file and the hang went away.  Is it true that I cannot make an unsandboxed app and uses the NSSavePanel?  I know this is a data point of one, so I want to be careful what conclusions I draw… any thoughts?

No, I have a non-sandboxed app and it works fine. I think the problem is that you are using NSSavePanel:runModal. If you look in the doc'n, it says:

"This method invokes NSApplication's runModalForWindow ..."

If it's doing that, then you need to cancel the modal yourslef (as with any call of runModalForWindow). Try putting a

[NSApp stopModalWithCode:NSModalResponseCancel];

in your "else" clause.

However, it may be simpler to use a sheet modal:
...setup code...
    [panel beginSheetModalForWindow:owningWindow
                  completionHandler:^(NSInteger result){
                      if (result == NSFileHandlingPanelOKButton)
                      {
                          self.saveFileURL = [[panel URLs] objectAtIndex:0];
                          [self writeToFileAtURL:self.saveFileURL];
                      }
                  }
     ];

You can spin the writing to a file off to a separate thread if it takes a long time.

Hope this helps,

Sak



Re: Canceling NSSavePanel Hang App

Sandor Szatmari
 

Already reading app sandbox design guide, was hoping for pointers to other apple resources, videos, etc…

Thanks,
Sandor

On Apr 2, 2020, at 13:54, Sandor Szatmari via groups.io <admin.szatmari.net=gmail.com@groups.io> wrote:

Took a guess and enabled sandbox and added read/write to user selected file and the hang went away. Is it true that I cannot make an unsandboxed app and uses the NSSavePanel? I know this is a data point of one, so I want to be careful what conclusions I draw… any thoughts?

Can anyone shed light/point me in the right direction as to where to update my knowledge?

Sandor

On Apr 1, 2020, at 17:31, Sandor Szatmari via groups.io <admin.szatmari.net=gmail.com@groups.io> wrote:

Ran into an interesting issue today…
Mac app
Xcode 9.4.1, 32bit, 10.12 SDK, 10.6 Deployment Target
non-sandboxed app

I am opening an NSSavePanel to allow a user to save the results of a report that is to be generated.

// Creating the save panel
NSSavePanel* savePanel = [NSSavePanel savePanel];
[savePanel setTitle:[NSString stringWithFormat:@"Export %@ Summary Data for %@", [self selectedReport], customerName]];

Opening the NSSavePanel using -runModal
savePanelUserAction = [savePanel runModal];

If the user enters a filename and clicks continue the save dialog closes, the report is generated, and the file is written to disk at the selected location.
if (savePanelUserAction == NSFileHandlingPanelOKButton)
[NSThread detachNewThreadSelector:@selector(createSummary:) toTarget:self withObject:[[savePanel URL] path]];

If the user clicks cancel, the program hangs. It hangs so badly that I have to go to the System Force-Quit dialog in order to fully terminate the app.
(i.e. Clicking stop program in Xcode does not fully terminate the app)
else
{
// Program hangs
}

I have checked that the NSSavePanel is being opened from the main thread.
I have included interesting backtraces below that are present if I stop the app in the de

Sandor

Thread 1 Queue : com.apple.main-thread (serial)
#0 0xa73d423e in kevent_id ()
#1 0x003305a6 in _dispatch_kq_poll ()
#2 0x00331141 in _dispatch_event_loop_wait_for_ownership ()
#3 0x00327b80 in _dispatch_sync_wait ()
#4 0x0031d500 in _dispatch_sync_f_slow ()
#5 0x0030f6d1 in dispatch_barrier_sync_f ()
#6 0x00316bf3 in dispatch_barrier_sync ()
#7 0x9387ebd4 in _VolumeObserverInvalidate ()
#8 0xa04ee78e in TSystemNotificationTask::~TSystemNotificationTask() ()
#9 0xa04ee818 in TSystemNotificationTask::FinalizeSystemNotificationTask() ()
#10 0xa04dda71 in NodeContextClose ()
#11 0x0afc689a in TFENode::Finalize() ()
#12 0x0b127290 in +[FIFinderViewGutsController finalizeCounted] ()
#13 0x0b127366 in __45+[FIFinderViewGutsController finalizeCounted]_block_invoke ()
#14 0x003167af in _dispatch_call_block_and_release ()
#15 0x0030e94d in _dispatch_client_callout ()
#16 0x0031ae6c in _dispatch_main_queue_callback_4CF ()
#17 0x937bb2ae in __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ ()
#18 0x9377ecf4 in __CFRunLoopRun ()
#19 0x9377dbd1 in CFRunLoopRunSpecific ()
#20 0x9377d93a in CFRunLoopRunInMode ()
#21 0x92d7b37b in RunCurrentEventLoopInMode ()
#22 0x92d7b0a2 in ReceiveNextEventCommon ()
#23 0x92d7ad7b in _BlockUntilNextEventMatchingListInModeWithFilter ()
#24 0x9137aafd in _DPSNextEvent ()
#25 0x91aece90 in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] ()
#26 0x91aec35d in -[NSApplication(NSEvent) nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#27 0x9136fa4d in -[NSApplication run] ()
#28 0x91341b0a in NSApplicationMain ()
#29 0x000026bc in main at /Users/username/repo/AppName/main.m:13
#30 0x00002685 in start ()
Enqueued from TBrowserViewDataSource (Thread 14) Queue : TBrowserViewDataSource (serial)
#0 0x0033f4dc in _dispatch_introspection_queue_item_enqueue ()
#1 0x00325cf8 in _dispatch_queue_push ()
#2 0x00323230 in _dispatch_continuation_push ()
#3 0x0032259b in _dispatch_continuation_async ()
#4 0x00316173 in dispatch_async ()
#5 0x0b1272f6 in +[FIFinderViewGutsController finalizeCounted] ()
#6 0x0b1aa3af in -[FI_TBrowserViewDataSource dealloc] ()
#7 0xa67a09f9 in objc_object::sidetable_release(bool) ()
#8 0xa679e2d0 in -[NSObject release] ()
#9 0x0b1aa762 in __destroy_helper_block_ ()
#10 0xa72c6b75 in _Block_release ()
#11 0x0030e94d in _dispatch_client_callout ()
#12 0x00324d3a in _dispatch_queue_serial_drain ()
#13 0x003162e2 in _dispatch_queue_invoke ()
#14 0x0032646e in _dispatch_root_queue_drain_deferred_wlh ()
#15 0x0032b4bb in _dispatch_workloop_worker_thread ()
#16 0x00381601 in _pthread_wqthread ()
#17 0x0038121e in start_wqthread ()
Enqueued from com.apple.main-thread (Thread 1) Queue : com.apple.main-thread (serial)
#0 0x0033f4dc in _dispatch_introspection_queue_item_enqueue ()
#1 0x00325cf8 in _dispatch_queue_push ()
#2 0x00323230 in _dispatch_continuation_push ()
#3 0x0032259b in _dispatch_continuation_async ()
#4 0x00316173 in dispatch_async ()
#5 0x0b1aa460 in -[FI_TBrowserViewDataSource aboutToTearDown] ()
#6 0x0b1e0aa5 in -[FI_TBrowserContainerController destroyBrowserView:] ()
#7 0x0b1e3ed4 in -[FIContainerController destroyBrowserView:] ()
#8 0x0b1e06c6 in -[FI_TBrowserContainerController aboutToTearDown] ()
#9 0x0b1e3f3b in -[FIContainerController aboutToTearDown] ()
#10 0xa67a0bda in -[NSObject performSelector:] ()
#11 0x0b042f47 in AboutToTearDownViewController(NSViewController*) ()
#12 0x0b07a83c in -[FI_TBrowserContentViewController aboutToTearDown] ()
#13 0xa67a0bda in -[NSObject performSelector:] ()
#14 0x0b042f47 in AboutToTearDownViewController(NSViewController*) ()
#15 0x0b1293f0 in -[FIFinderViewGutsController prepareToHide] ()
#16 0x0b12996f in -[FIFinderViewGutsController windowOrderedOut] ()
#17 0x0b13486f in -[FIFinderView windowOrderedOut] ()
#18 0x91e3ffe5 in -[NSNavFinderViewFileBrowser windowOrderedOut] ()
#19 0x91a4df5e in -[NSSavePanel _navViewWindowOrderedOut] ()
#20 0x91a4dfc5 in -[NSSavePanel orderOut:] ()
#21 0x91a5bffa in -[NSSavePanel _didEndSheet:returnCode:contextInfo:] ()
#22 0x91c27b17 in NSWindowEndWindowModalSession ()
#23 0x915acaf6 in -[NSWindow _endWindowBlockingModalSession:returnCode:] ()
#24 0x915aca86 in -[NSWindow endSheet:returnCode:] ()
#25 0x915f7367 in -[NSApplication endSheet:returnCode:] ()
#26 0x91a5e2cb in -[NSSavePanel _dismissWindowWithReturnCode:willRunSeamlessOpening:] ()
#27 0x91a5e2f1 in -[NSSavePanel _cancelAndClose] ()
#28 0x91a5e933 in -[NSSavePanel cancel:] ()
#29 0xa67a0c1c in -[NSObject performSelector:withObject:] ()
#30 0x91aeeca9 in __49-[NSApplication(NSResponder) sendAction:to:from:]_block_invoke ()
#31 0x91aeec4d in __NS_ACTIVITY_PERFORM_EXCEPTION_SAFE ()
#32 0x91aeeb4f in -[NSApplication(NSResponder) sendAction:to:from:] ()
#33 0x9159eda8 in -[NSControl sendAction:to:] ()
#34 0x9159ecc7 in __26-[NSCell _sendActionFrom:]_block_invoke ()
#35 0x917e5009 in __NS_ACTIVITY_PERFORM_EXCEPTION_SAFE ()
#36 0x9159ec11 in -[NSCell _sendActionFrom:] ()
#37 0x915dd6cb in -[NSButtonCell _sendActionFrom:] ()
#38 0x917e6e2c in __48-[NSCell trackMouse:inRect:ofView:untilMouseUp:]_block_invoke.1099 ()
#39 0x917e5009 in __NS_ACTIVITY_PERFORM_EXCEPTION_SAFE ()
#40 0x9159d58d in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] ()
#41 0x915dd420 in -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] ()
#42 0x9159bff4 in -[NSControl mouseDown:] ()
#43 0x91c922b4 in -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] ()
#44 0x91c9024f in -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] ()
#45 0x91c8e4c0 in -[NSWindow(NSEventRouting) sendEvent:] ()
#46 0x91aeb2d5 in -[NSApplication(NSEvent) sendEvent:] ()
#47 0x9136fa98 in -[NSApplication run] ()
#48 0x91341b0a in NSApplicationMain ()
#49 0x000026bc in main at /Users/username/repo/AppName/main.m:13
#50 0x00002685 in start ()


// Other threads that seemed interesting, but could be misleading???

Thread 2 Queue : com.apple.CFVolumeObserver.0x6af670 (serial)
#0 0xa73d242a in __getattrlist ()
#1 0x9ffa770f in volumePropertyProviderPrepareValues(__CFURL const*, __FileCache*, __CFString const* const*, void const**, long, void const*, __CFError**) ()
#2 0x9ffa1ebd in prepareValuesForBitmap(__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**) ()
#3 0x9ff9f858 in _FSURLCopyResourcePropertyForKeyInternal(__CFURL const*, __CFString const*, void*, void*, __CFError**, unsigned char) ()
#4 0x9ff9f779 in _FSURLCopyResourcePropertyForKey ()
#5 0x93765cd0 in CFURLCopyResourcePropertyForKey ()
#6 0x937dfaf6 in _VolumeObserverDiskAppearedCallback ()
#7 0x9513f6ab in _DADispatchCallback ()
#8 0x9513f439 in _DASessionCallback ()
#9 0x9513f304 in __DASessionSetDispatchQueue_block_invoke_2 ()
#10 0x0030e94d in _dispatch_client_callout ()
#11 0x00323464 in _dispatch_continuation_pop ()
#12 0x00310eba in _dispatch_source_invoke ()
#13 0x00324b73 in _dispatch_queue_serial_drain ()
#14 0x003162e2 in _dispatch_queue_invoke ()
#15 0x0032646e in _dispatch_root_queue_drain_deferred_wlh ()
#16 0x0032b4bb in _dispatch_workloop_worker_thread ()
#17 0x00381601 in _pthread_wqthread ()
#18 0x0038121e in start_wqthread ()


Thread 10 Queue : com.apple.CFVolumeObserver.0x6ac5d0 (serial)
#0 0xa73d242a in __getattrlist ()
#1 0x9ffa770f in volumePropertyProviderPrepareValues(__CFURL const*, __FileCache*, __CFString const* const*, void const**, long, void const*, __CFError**) ()
#2 0x9ffa1ebd in prepareValuesForBitmap(__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**) ()
#3 0x9ff9f858 in _FSURLCopyResourcePropertyForKeyInternal(__CFURL const*, __CFString const*, void*, void*, __CFError**, unsigned char) ()
#4 0x9ff9f779 in _FSURLCopyResourcePropertyForKey ()
#5 0x93765cd0 in CFURLCopyResourcePropertyForKey ()
#6 0x937dfaf6 in _VolumeObserverDiskAppearedCallback ()
#7 0x9513f6ab in _DADispatchCallback ()
#8 0x9513f439 in _DASessionCallback ()
#9 0x9513f304 in __DASessionSetDispatchQueue_block_invoke_2 ()
#10 0x0030e94d in _dispatch_client_callout ()
#11 0x00323464 in _dispatch_continuation_pop ()
#12 0x00310eba in _dispatch_source_invoke ()
#13 0x00324b73 in _dispatch_queue_serial_drain ()
#14 0x003162e2 in _dispatch_queue_invoke ()
#15 0x0032646e in _dispatch_root_queue_drain_deferred_wlh ()
#16 0x0032b4bb in _dispatch_workloop_worker_thread ()
#17 0x00381601 in _pthread_wqthread ()
#18 0x0038121e in start_wqthread ()



Re: Canceling NSSavePanel Hang App

Sandor Szatmari
 

Took a guess and enabled sandbox and added read/write to user selected file and the hang went away. Is it true that I cannot make an unsandboxed app and uses the NSSavePanel? I know this is a data point of one, so I want to be careful what conclusions I draw… any thoughts?

Can anyone shed light/point me in the right direction as to where to update my knowledge?

Sandor

On Apr 1, 2020, at 17:31, Sandor Szatmari via groups.io <admin.szatmari.net=gmail.com@groups.io> wrote:

Ran into an interesting issue today…
Mac app
Xcode 9.4.1, 32bit, 10.12 SDK, 10.6 Deployment Target
non-sandboxed app

I am opening an NSSavePanel to allow a user to save the results of a report that is to be generated.

// Creating the save panel
NSSavePanel* savePanel = [NSSavePanel savePanel];
[savePanel setTitle:[NSString stringWithFormat:@"Export %@ Summary Data for %@", [self selectedReport], customerName]];

Opening the NSSavePanel using -runModal
savePanelUserAction = [savePanel runModal];

If the user enters a filename and clicks continue the save dialog closes, the report is generated, and the file is written to disk at the selected location.
if (savePanelUserAction == NSFileHandlingPanelOKButton)
[NSThread detachNewThreadSelector:@selector(createSummary:) toTarget:self withObject:[[savePanel URL] path]];

If the user clicks cancel, the program hangs. It hangs so badly that I have to go to the System Force-Quit dialog in order to fully terminate the app.
(i.e. Clicking stop program in Xcode does not fully terminate the app)
else
{
// Program hangs
}

I have checked that the NSSavePanel is being opened from the main thread.
I have included interesting backtraces below that are present if I stop the app in the de

Sandor

Thread 1 Queue : com.apple.main-thread (serial)
#0 0xa73d423e in kevent_id ()
#1 0x003305a6 in _dispatch_kq_poll ()
#2 0x00331141 in _dispatch_event_loop_wait_for_ownership ()
#3 0x00327b80 in _dispatch_sync_wait ()
#4 0x0031d500 in _dispatch_sync_f_slow ()
#5 0x0030f6d1 in dispatch_barrier_sync_f ()
#6 0x00316bf3 in dispatch_barrier_sync ()
#7 0x9387ebd4 in _VolumeObserverInvalidate ()
#8 0xa04ee78e in TSystemNotificationTask::~TSystemNotificationTask() ()
#9 0xa04ee818 in TSystemNotificationTask::FinalizeSystemNotificationTask() ()
#10 0xa04dda71 in NodeContextClose ()
#11 0x0afc689a in TFENode::Finalize() ()
#12 0x0b127290 in +[FIFinderViewGutsController finalizeCounted] ()
#13 0x0b127366 in __45+[FIFinderViewGutsController finalizeCounted]_block_invoke ()
#14 0x003167af in _dispatch_call_block_and_release ()
#15 0x0030e94d in _dispatch_client_callout ()
#16 0x0031ae6c in _dispatch_main_queue_callback_4CF ()
#17 0x937bb2ae in __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ ()
#18 0x9377ecf4 in __CFRunLoopRun ()
#19 0x9377dbd1 in CFRunLoopRunSpecific ()
#20 0x9377d93a in CFRunLoopRunInMode ()
#21 0x92d7b37b in RunCurrentEventLoopInMode ()
#22 0x92d7b0a2 in ReceiveNextEventCommon ()
#23 0x92d7ad7b in _BlockUntilNextEventMatchingListInModeWithFilter ()
#24 0x9137aafd in _DPSNextEvent ()
#25 0x91aece90 in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] ()
#26 0x91aec35d in -[NSApplication(NSEvent) nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#27 0x9136fa4d in -[NSApplication run] ()
#28 0x91341b0a in NSApplicationMain ()
#29 0x000026bc in main at /Users/username/repo/AppName/main.m:13
#30 0x00002685 in start ()
Enqueued from TBrowserViewDataSource (Thread 14) Queue : TBrowserViewDataSource (serial)
#0 0x0033f4dc in _dispatch_introspection_queue_item_enqueue ()
#1 0x00325cf8 in _dispatch_queue_push ()
#2 0x00323230 in _dispatch_continuation_push ()
#3 0x0032259b in _dispatch_continuation_async ()
#4 0x00316173 in dispatch_async ()
#5 0x0b1272f6 in +[FIFinderViewGutsController finalizeCounted] ()
#6 0x0b1aa3af in -[FI_TBrowserViewDataSource dealloc] ()
#7 0xa67a09f9 in objc_object::sidetable_release(bool) ()
#8 0xa679e2d0 in -[NSObject release] ()
#9 0x0b1aa762 in __destroy_helper_block_ ()
#10 0xa72c6b75 in _Block_release ()
#11 0x0030e94d in _dispatch_client_callout ()
#12 0x00324d3a in _dispatch_queue_serial_drain ()
#13 0x003162e2 in _dispatch_queue_invoke ()
#14 0x0032646e in _dispatch_root_queue_drain_deferred_wlh ()
#15 0x0032b4bb in _dispatch_workloop_worker_thread ()
#16 0x00381601 in _pthread_wqthread ()
#17 0x0038121e in start_wqthread ()
Enqueued from com.apple.main-thread (Thread 1) Queue : com.apple.main-thread (serial)
#0 0x0033f4dc in _dispatch_introspection_queue_item_enqueue ()
#1 0x00325cf8 in _dispatch_queue_push ()
#2 0x00323230 in _dispatch_continuation_push ()
#3 0x0032259b in _dispatch_continuation_async ()
#4 0x00316173 in dispatch_async ()
#5 0x0b1aa460 in -[FI_TBrowserViewDataSource aboutToTearDown] ()
#6 0x0b1e0aa5 in -[FI_TBrowserContainerController destroyBrowserView:] ()
#7 0x0b1e3ed4 in -[FIContainerController destroyBrowserView:] ()
#8 0x0b1e06c6 in -[FI_TBrowserContainerController aboutToTearDown] ()
#9 0x0b1e3f3b in -[FIContainerController aboutToTearDown] ()
#10 0xa67a0bda in -[NSObject performSelector:] ()
#11 0x0b042f47 in AboutToTearDownViewController(NSViewController*) ()
#12 0x0b07a83c in -[FI_TBrowserContentViewController aboutToTearDown] ()
#13 0xa67a0bda in -[NSObject performSelector:] ()
#14 0x0b042f47 in AboutToTearDownViewController(NSViewController*) ()
#15 0x0b1293f0 in -[FIFinderViewGutsController prepareToHide] ()
#16 0x0b12996f in -[FIFinderViewGutsController windowOrderedOut] ()
#17 0x0b13486f in -[FIFinderView windowOrderedOut] ()
#18 0x91e3ffe5 in -[NSNavFinderViewFileBrowser windowOrderedOut] ()
#19 0x91a4df5e in -[NSSavePanel _navViewWindowOrderedOut] ()
#20 0x91a4dfc5 in -[NSSavePanel orderOut:] ()
#21 0x91a5bffa in -[NSSavePanel _didEndSheet:returnCode:contextInfo:] ()
#22 0x91c27b17 in NSWindowEndWindowModalSession ()
#23 0x915acaf6 in -[NSWindow _endWindowBlockingModalSession:returnCode:] ()
#24 0x915aca86 in -[NSWindow endSheet:returnCode:] ()
#25 0x915f7367 in -[NSApplication endSheet:returnCode:] ()
#26 0x91a5e2cb in -[NSSavePanel _dismissWindowWithReturnCode:willRunSeamlessOpening:] ()
#27 0x91a5e2f1 in -[NSSavePanel _cancelAndClose] ()
#28 0x91a5e933 in -[NSSavePanel cancel:] ()
#29 0xa67a0c1c in -[NSObject performSelector:withObject:] ()
#30 0x91aeeca9 in __49-[NSApplication(NSResponder) sendAction:to:from:]_block_invoke ()
#31 0x91aeec4d in __NS_ACTIVITY_PERFORM_EXCEPTION_SAFE ()
#32 0x91aeeb4f in -[NSApplication(NSResponder) sendAction:to:from:] ()
#33 0x9159eda8 in -[NSControl sendAction:to:] ()
#34 0x9159ecc7 in __26-[NSCell _sendActionFrom:]_block_invoke ()
#35 0x917e5009 in __NS_ACTIVITY_PERFORM_EXCEPTION_SAFE ()
#36 0x9159ec11 in -[NSCell _sendActionFrom:] ()
#37 0x915dd6cb in -[NSButtonCell _sendActionFrom:] ()
#38 0x917e6e2c in __48-[NSCell trackMouse:inRect:ofView:untilMouseUp:]_block_invoke.1099 ()
#39 0x917e5009 in __NS_ACTIVITY_PERFORM_EXCEPTION_SAFE ()
#40 0x9159d58d in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] ()
#41 0x915dd420 in -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] ()
#42 0x9159bff4 in -[NSControl mouseDown:] ()
#43 0x91c922b4 in -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] ()
#44 0x91c9024f in -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] ()
#45 0x91c8e4c0 in -[NSWindow(NSEventRouting) sendEvent:] ()
#46 0x91aeb2d5 in -[NSApplication(NSEvent) sendEvent:] ()
#47 0x9136fa98 in -[NSApplication run] ()
#48 0x91341b0a in NSApplicationMain ()
#49 0x000026bc in main at /Users/username/repo/AppName/main.m:13
#50 0x00002685 in start ()


// Other threads that seemed interesting, but could be misleading???

Thread 2 Queue : com.apple.CFVolumeObserver.0x6af670 (serial)
#0 0xa73d242a in __getattrlist ()
#1 0x9ffa770f in volumePropertyProviderPrepareValues(__CFURL const*, __FileCache*, __CFString const* const*, void const**, long, void const*, __CFError**) ()
#2 0x9ffa1ebd in prepareValuesForBitmap(__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**) ()
#3 0x9ff9f858 in _FSURLCopyResourcePropertyForKeyInternal(__CFURL const*, __CFString const*, void*, void*, __CFError**, unsigned char) ()
#4 0x9ff9f779 in _FSURLCopyResourcePropertyForKey ()
#5 0x93765cd0 in CFURLCopyResourcePropertyForKey ()
#6 0x937dfaf6 in _VolumeObserverDiskAppearedCallback ()
#7 0x9513f6ab in _DADispatchCallback ()
#8 0x9513f439 in _DASessionCallback ()
#9 0x9513f304 in __DASessionSetDispatchQueue_block_invoke_2 ()
#10 0x0030e94d in _dispatch_client_callout ()
#11 0x00323464 in _dispatch_continuation_pop ()
#12 0x00310eba in _dispatch_source_invoke ()
#13 0x00324b73 in _dispatch_queue_serial_drain ()
#14 0x003162e2 in _dispatch_queue_invoke ()
#15 0x0032646e in _dispatch_root_queue_drain_deferred_wlh ()
#16 0x0032b4bb in _dispatch_workloop_worker_thread ()
#17 0x00381601 in _pthread_wqthread ()
#18 0x0038121e in start_wqthread ()


Thread 10 Queue : com.apple.CFVolumeObserver.0x6ac5d0 (serial)
#0 0xa73d242a in __getattrlist ()
#1 0x9ffa770f in volumePropertyProviderPrepareValues(__CFURL const*, __FileCache*, __CFString const* const*, void const**, long, void const*, __CFError**) ()
#2 0x9ffa1ebd in prepareValuesForBitmap(__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**) ()
#3 0x9ff9f858 in _FSURLCopyResourcePropertyForKeyInternal(__CFURL const*, __CFString const*, void*, void*, __CFError**, unsigned char) ()
#4 0x9ff9f779 in _FSURLCopyResourcePropertyForKey ()
#5 0x93765cd0 in CFURLCopyResourcePropertyForKey ()
#6 0x937dfaf6 in _VolumeObserverDiskAppearedCallback ()
#7 0x9513f6ab in _DADispatchCallback ()
#8 0x9513f439 in _DASessionCallback ()
#9 0x9513f304 in __DASessionSetDispatchQueue_block_invoke_2 ()
#10 0x0030e94d in _dispatch_client_callout ()
#11 0x00323464 in _dispatch_continuation_pop ()
#12 0x00310eba in _dispatch_source_invoke ()
#13 0x00324b73 in _dispatch_queue_serial_drain ()
#14 0x003162e2 in _dispatch_queue_invoke ()
#15 0x0032646e in _dispatch_root_queue_drain_deferred_wlh ()
#16 0x0032b4bb in _dispatch_workloop_worker_thread ()
#17 0x00381601 in _pthread_wqthread ()
#18 0x0038121e in start_wqthread ()


Canceling NSSavePanel Hang App

Sandor Szatmari
 

Ran into an interesting issue today…
Mac app
Xcode 9.4.1, 32bit, 10.12 SDK, 10.6 Deployment Target
non-sandboxed app

I am opening an NSSavePanel to allow a user to save the results of a report that is to be generated.

// Creating the save panel
NSSavePanel* savePanel = [NSSavePanel savePanel];
[savePanel setTitle:[NSString stringWithFormat:@"Export %@ Summary Data for %@", [self selectedReport], customerName]];

Opening the NSSavePanel using -runModal
savePanelUserAction = [savePanel runModal];

If the user enters a filename and clicks continue the save dialog closes, the report is generated, and the file is written to disk at the selected location.
if (savePanelUserAction == NSFileHandlingPanelOKButton)
[NSThread detachNewThreadSelector:@selector(createSummary:) toTarget:self withObject:[[savePanel URL] path]];

If the user clicks cancel, the program hangs. It hangs so badly that I have to go to the System Force-Quit dialog in order to fully terminate the app.
(i.e. Clicking stop program in Xcode does not fully terminate the app)
else
{
// Program hangs
}

I have checked that the NSSavePanel is being opened from the main thread.
I have included interesting backtraces below that are present if I stop the app in the de

Sandor

Thread 1 Queue : com.apple.main-thread (serial)
#0 0xa73d423e in kevent_id ()
#1 0x003305a6 in _dispatch_kq_poll ()
#2 0x00331141 in _dispatch_event_loop_wait_for_ownership ()
#3 0x00327b80 in _dispatch_sync_wait ()
#4 0x0031d500 in _dispatch_sync_f_slow ()
#5 0x0030f6d1 in dispatch_barrier_sync_f ()
#6 0x00316bf3 in dispatch_barrier_sync ()
#7 0x9387ebd4 in _VolumeObserverInvalidate ()
#8 0xa04ee78e in TSystemNotificationTask::~TSystemNotificationTask() ()
#9 0xa04ee818 in TSystemNotificationTask::FinalizeSystemNotificationTask() ()
#10 0xa04dda71 in NodeContextClose ()
#11 0x0afc689a in TFENode::Finalize() ()
#12 0x0b127290 in +[FIFinderViewGutsController finalizeCounted] ()
#13 0x0b127366 in __45+[FIFinderViewGutsController finalizeCounted]_block_invoke ()
#14 0x003167af in _dispatch_call_block_and_release ()
#15 0x0030e94d in _dispatch_client_callout ()
#16 0x0031ae6c in _dispatch_main_queue_callback_4CF ()
#17 0x937bb2ae in __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ ()
#18 0x9377ecf4 in __CFRunLoopRun ()
#19 0x9377dbd1 in CFRunLoopRunSpecific ()
#20 0x9377d93a in CFRunLoopRunInMode ()
#21 0x92d7b37b in RunCurrentEventLoopInMode ()
#22 0x92d7b0a2 in ReceiveNextEventCommon ()
#23 0x92d7ad7b in _BlockUntilNextEventMatchingListInModeWithFilter ()
#24 0x9137aafd in _DPSNextEvent ()
#25 0x91aece90 in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] ()
#26 0x91aec35d in -[NSApplication(NSEvent) nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#27 0x9136fa4d in -[NSApplication run] ()
#28 0x91341b0a in NSApplicationMain ()
#29 0x000026bc in main at /Users/username/repo/AppName/main.m:13
#30 0x00002685 in start ()
Enqueued from TBrowserViewDataSource (Thread 14) Queue : TBrowserViewDataSource (serial)
#0 0x0033f4dc in _dispatch_introspection_queue_item_enqueue ()
#1 0x00325cf8 in _dispatch_queue_push ()
#2 0x00323230 in _dispatch_continuation_push ()
#3 0x0032259b in _dispatch_continuation_async ()
#4 0x00316173 in dispatch_async ()
#5 0x0b1272f6 in +[FIFinderViewGutsController finalizeCounted] ()
#6 0x0b1aa3af in -[FI_TBrowserViewDataSource dealloc] ()
#7 0xa67a09f9 in objc_object::sidetable_release(bool) ()
#8 0xa679e2d0 in -[NSObject release] ()
#9 0x0b1aa762 in __destroy_helper_block_ ()
#10 0xa72c6b75 in _Block_release ()
#11 0x0030e94d in _dispatch_client_callout ()
#12 0x00324d3a in _dispatch_queue_serial_drain ()
#13 0x003162e2 in _dispatch_queue_invoke ()
#14 0x0032646e in _dispatch_root_queue_drain_deferred_wlh ()
#15 0x0032b4bb in _dispatch_workloop_worker_thread ()
#16 0x00381601 in _pthread_wqthread ()
#17 0x0038121e in start_wqthread ()
Enqueued from com.apple.main-thread (Thread 1) Queue : com.apple.main-thread (serial)
#0 0x0033f4dc in _dispatch_introspection_queue_item_enqueue ()
#1 0x00325cf8 in _dispatch_queue_push ()
#2 0x00323230 in _dispatch_continuation_push ()
#3 0x0032259b in _dispatch_continuation_async ()
#4 0x00316173 in dispatch_async ()
#5 0x0b1aa460 in -[FI_TBrowserViewDataSource aboutToTearDown] ()
#6 0x0b1e0aa5 in -[FI_TBrowserContainerController destroyBrowserView:] ()
#7 0x0b1e3ed4 in -[FIContainerController destroyBrowserView:] ()
#8 0x0b1e06c6 in -[FI_TBrowserContainerController aboutToTearDown] ()
#9 0x0b1e3f3b in -[FIContainerController aboutToTearDown] ()
#10 0xa67a0bda in -[NSObject performSelector:] ()
#11 0x0b042f47 in AboutToTearDownViewController(NSViewController*) ()
#12 0x0b07a83c in -[FI_TBrowserContentViewController aboutToTearDown] ()
#13 0xa67a0bda in -[NSObject performSelector:] ()
#14 0x0b042f47 in AboutToTearDownViewController(NSViewController*) ()
#15 0x0b1293f0 in -[FIFinderViewGutsController prepareToHide] ()
#16 0x0b12996f in -[FIFinderViewGutsController windowOrderedOut] ()
#17 0x0b13486f in -[FIFinderView windowOrderedOut] ()
#18 0x91e3ffe5 in -[NSNavFinderViewFileBrowser windowOrderedOut] ()
#19 0x91a4df5e in -[NSSavePanel _navViewWindowOrderedOut] ()
#20 0x91a4dfc5 in -[NSSavePanel orderOut:] ()
#21 0x91a5bffa in -[NSSavePanel _didEndSheet:returnCode:contextInfo:] ()
#22 0x91c27b17 in NSWindowEndWindowModalSession ()
#23 0x915acaf6 in -[NSWindow _endWindowBlockingModalSession:returnCode:] ()
#24 0x915aca86 in -[NSWindow endSheet:returnCode:] ()
#25 0x915f7367 in -[NSApplication endSheet:returnCode:] ()
#26 0x91a5e2cb in -[NSSavePanel _dismissWindowWithReturnCode:willRunSeamlessOpening:] ()
#27 0x91a5e2f1 in -[NSSavePanel _cancelAndClose] ()
#28 0x91a5e933 in -[NSSavePanel cancel:] ()
#29 0xa67a0c1c in -[NSObject performSelector:withObject:] ()
#30 0x91aeeca9 in __49-[NSApplication(NSResponder) sendAction:to:from:]_block_invoke ()
#31 0x91aeec4d in __NS_ACTIVITY_PERFORM_EXCEPTION_SAFE ()
#32 0x91aeeb4f in -[NSApplication(NSResponder) sendAction:to:from:] ()
#33 0x9159eda8 in -[NSControl sendAction:to:] ()
#34 0x9159ecc7 in __26-[NSCell _sendActionFrom:]_block_invoke ()
#35 0x917e5009 in __NS_ACTIVITY_PERFORM_EXCEPTION_SAFE ()
#36 0x9159ec11 in -[NSCell _sendActionFrom:] ()
#37 0x915dd6cb in -[NSButtonCell _sendActionFrom:] ()
#38 0x917e6e2c in __48-[NSCell trackMouse:inRect:ofView:untilMouseUp:]_block_invoke.1099 ()
#39 0x917e5009 in __NS_ACTIVITY_PERFORM_EXCEPTION_SAFE ()
#40 0x9159d58d in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] ()
#41 0x915dd420 in -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] ()
#42 0x9159bff4 in -[NSControl mouseDown:] ()
#43 0x91c922b4 in -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] ()
#44 0x91c9024f in -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] ()
#45 0x91c8e4c0 in -[NSWindow(NSEventRouting) sendEvent:] ()
#46 0x91aeb2d5 in -[NSApplication(NSEvent) sendEvent:] ()
#47 0x9136fa98 in -[NSApplication run] ()
#48 0x91341b0a in NSApplicationMain ()
#49 0x000026bc in main at /Users/username/repo/AppName/main.m:13
#50 0x00002685 in start ()


// Other threads that seemed interesting, but could be misleading???

Thread 2 Queue : com.apple.CFVolumeObserver.0x6af670 (serial)
#0 0xa73d242a in __getattrlist ()
#1 0x9ffa770f in volumePropertyProviderPrepareValues(__CFURL const*, __FileCache*, __CFString const* const*, void const**, long, void const*, __CFError**) ()
#2 0x9ffa1ebd in prepareValuesForBitmap(__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**) ()
#3 0x9ff9f858 in _FSURLCopyResourcePropertyForKeyInternal(__CFURL const*, __CFString const*, void*, void*, __CFError**, unsigned char) ()
#4 0x9ff9f779 in _FSURLCopyResourcePropertyForKey ()
#5 0x93765cd0 in CFURLCopyResourcePropertyForKey ()
#6 0x937dfaf6 in _VolumeObserverDiskAppearedCallback ()
#7 0x9513f6ab in _DADispatchCallback ()
#8 0x9513f439 in _DASessionCallback ()
#9 0x9513f304 in __DASessionSetDispatchQueue_block_invoke_2 ()
#10 0x0030e94d in _dispatch_client_callout ()
#11 0x00323464 in _dispatch_continuation_pop ()
#12 0x00310eba in _dispatch_source_invoke ()
#13 0x00324b73 in _dispatch_queue_serial_drain ()
#14 0x003162e2 in _dispatch_queue_invoke ()
#15 0x0032646e in _dispatch_root_queue_drain_deferred_wlh ()
#16 0x0032b4bb in _dispatch_workloop_worker_thread ()
#17 0x00381601 in _pthread_wqthread ()
#18 0x0038121e in start_wqthread ()


Thread 10 Queue : com.apple.CFVolumeObserver.0x6ac5d0 (serial)
#0 0xa73d242a in __getattrlist ()
#1 0x9ffa770f in volumePropertyProviderPrepareValues(__CFURL const*, __FileCache*, __CFString const* const*, void const**, long, void const*, __CFError**) ()
#2 0x9ffa1ebd in prepareValuesForBitmap(__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**) ()
#3 0x9ff9f858 in _FSURLCopyResourcePropertyForKeyInternal(__CFURL const*, __CFString const*, void*, void*, __CFError**, unsigned char) ()
#4 0x9ff9f779 in _FSURLCopyResourcePropertyForKey ()
#5 0x93765cd0 in CFURLCopyResourcePropertyForKey ()
#6 0x937dfaf6 in _VolumeObserverDiskAppearedCallback ()
#7 0x9513f6ab in _DADispatchCallback ()
#8 0x9513f439 in _DASessionCallback ()
#9 0x9513f304 in __DASessionSetDispatchQueue_block_invoke_2 ()
#10 0x0030e94d in _dispatch_client_callout ()
#11 0x00323464 in _dispatch_continuation_pop ()
#12 0x00310eba in _dispatch_source_invoke ()
#13 0x00324b73 in _dispatch_queue_serial_drain ()
#14 0x003162e2 in _dispatch_queue_invoke ()
#15 0x0032646e in _dispatch_root_queue_drain_deferred_wlh ()
#16 0x0032b4bb in _dispatch_workloop_worker_thread ()
#17 0x00381601 in _pthread_wqthread ()
#18 0x0038121e in start_wqthread ()


Re: Drawing to a PDF context

Sandor Szatmari
 

Jim,

On Mar 4, 2020, at 11:56 AM, Jim <jimcfl@gmail.com> wrote:


On Mar 4, 2020, at 11:06 AM, Quincey Morris <quinceymorris@rivergatesoftware.com> wrote:

On Mar 4, 2020, at 06:52 , Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

I need to replace calls to CGShowTextAtPoint() with calls to -drawAtPoint:withAttributes:

I made this change and drawing fails… :/
i.e. no text rendered, no exception, logging of errors, etc. simply no text
Well, by default, NWView coordinates are flipped vs. CGContext coordinates. I suggest you try temporarily forcing the point you’re drawing at to be the center of the context or view, and see if the text even appears. If so, you should be able to see what you need to do to transform the point at which you’re drawing (based on which direction the text is running, and whether it’s upside down).

Are you switching over to PDFKit? In that case, you’ll have to respect whatever coordinate system it uses. It looks like there’s some advice on that subject in the “Override the Draw Method and Add Your Custom Graphic” section of https://developer.apple.com/documentation/pdfkit/adding_custom_graphics_to_a_pdf.
When I wrote an app that added things to an existing PDF a couple years ago, I was able to use text and custom annotations to display elements on a document in a PDFView, but was unable to figure out how to use PDFKit to save the annotations into the document so that they would be visible with Preview or Acrobat. It appears that PDFKit is primarily oriented around on-screen display and markup of a PDF, not creating or modifying a PDF.

So to save the changes I had to redraw the existing document in a CGPDFContext and then draw the elements as images in that context as well. This turns each PDF page into an image, which wasn’t a problem in my case, but is usually not desirable.
Yea, we are printing and distributing the PDF so it’s important to retain the vector nature of the PDF. People need to be able to zoom in to read the finer details.

Thanks!

Jim Crate



201 - 220 of 1426