When I try to turn on sandboxing on a helper tool, it crashes on launch. I thought my problem was solved when I found the post Sandboxed Helper Tool Crashing in libsystem_secinit, but no. I set CODE_SIGN_INJECT_BASE_ENTITLEMENTS = NO in the target that builds the tool, and verified that the only entitlement in the built tool is that com.apple.security.app-sandbox is true, but it still crashes.
Backtrace:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_secinit.dylib 0x7ff81af68400 _libsecinit_appsandbox.cold.7 + 49
1 libsystem_secinit.dylib 0x7ff81af6793c _libsecinit_appsandbox + 1831
2 libsystem_trace.dylib 0x7ff80f06649c _os_activity_initiate_impl + 51
3 libsystem_secinit.dylib 0x7ff81af671d4 _libsecinit_initializer + 67
4 libSystem.B.dylib 0x7ff81af7b8b9 libSystem_initializer + 286
5 dyld 0x7ff80efa1618 invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 172
6 dyld 0x7ff80efe0de9 invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 242
7 dyld 0x7ff80efd4ef7 invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 557
8 dyld 0x7ff80ef870b7 dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 245
9 dyld 0x7ff80efd40a7 dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 175
10 dyld 0x7ff80efe08d2 dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 470
11 dyld 0x7ff80efa14f6 dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 150
12 dyld 0x7ff80efa9fd4 dyld4::PrebuiltLoader::runInitializers(dyld4::RuntimeState&) const + 30
13 dyld 0x7ff80efc100d dyld4::APIs::runAllInitializersForMain() + 71
14 dyld 0x7ff80ef8c369 dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 3743
15 dyld 0x7ff80ef8b281 start + 2289
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I'm trying to download a small data file using NSURLSession, but the completion handler is never called (where "never" means I waited long after the specified timeout).
NSURLSessionConfiguration* config =
NSURLSessionConfiguration.ephemeralSessionConfiguration;
config.timeoutIntervalForResource = 120.0;
config.timeoutIntervalForRequest = 120.0;
NSURLSession* session = [NSURLSession sessionWithConfiguration: config];
[session dataTaskWithURL: inURL
completionHandler:
^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error)
{
...
}];
I'm trying to update some old code that used the deprecated NSURLConnection class, and am using the same URL, so I know that the URL is good.
I have a view (custom subclass of NSView) that overrides mouseDown: and mouseUp:. If I double-click the view, I expect to see a sequence of events:
mouseDown with clickCount == 1
mouseUp with clickCount == 1
mouseDown with clickCount == 2
mouseUp with clickCount == 2
Usually, that's what happens. But occasionally, the second or both mouse up events don't arrive. That's a problem, because it's my understanding that if you want to handle a double-click, you should be looking for the second mouse up. I am certain that the mouse location is always within the bounds of the view. What could cause this? (Testing on macOS 13.6.4.)
Added: I use a subclass of NSApplication, and override nextEventMatchingMask:untilDate:inMode:dequeue: and sendEvent:. The overrides usually just call through to the superclass method. Logging mouse events from these methods, I see that in the problematic cases, the mouse up events are received from the queue, but never sent.
I have a repeating timer installed like this:
_cmdTimer = [NSTimer timerWithTimeInterval: 0.5
target: self
selector: @selector(timedTask:)
userInfo: nil
repeats: YES];
[NSRunLoop.mainRunLoop addTimer: _cmdTimer
forMode: NSModalPanelRunLoopMode];
[NSRunLoop.mainRunLoop addTimer: _cmdTimer
forMode: NSDefaultRunLoopMode];
The first time the timer fires, it opens a modal dialog. But then the timer does not fire again until the dialog is closed. I don't get that, since I scheduled the timer in NSModalPanelRunLoopMode. To verify that the dialog was running in that mode, just before opening the dialog I said
[self performSelector: @selector(testMe)
withObject: nil
afterDelay: 0.7
inModes: @[NSModalPanelRunLoopMode] ];
and the testMe method did get executed while the dialog was open.
As an exercise in learning Swift, I rewrote a toy C++ command line tool in Swift. After switching to an UnsafeRawBufferPointer in a critical part of the code, the Release build of the Swift version was a little faster than the Release build of the C++ version. But the Debug build took around 700 times as long. I expect a Debug build to be somewhat slower, but by that much?
Here's the critical part of the code, a function that gets called many thousands of times. The two string parameters are always 5-letter words in plain ASCII (it's related to Wordle). By the way, if I change the loop ranges from 0..<5 to [0,1,2,3,4], then it runs about twice as fast in Debug, but twice as slow in Release.
func Score( trial: String, target: String ) -> Int
{
var score = 0
withUnsafeBytes(of: trial.utf8) { rawTrial in
withUnsafeBytes(of: target.utf8) { rawTarget in
for i in 0..<5
{
let trial_i = rawTrial[i];
if trial_i == rawTarget[i] // strong hit
{
score += kStrongScore
}
else // check for weak hit
{
for j in 0..<5
{
if j != i
{
let target_j = rawTarget[j];
if (trial_i == target_j) &&
(rawTrial[j] != target_j)
{
score += kWeakScore
break
}
}
}
}
}
}
}
return score
}
I'm trying to do a piecemeal conversion of a big macOS Objective-C++ code base to use Automatic Reference Counting (ARC), and started with a fairly complex modal dialog. I converted all the classes involved to use ARC. When the dialog closes, the window itself, and some of the controller objects, get deallocated as they should, but some do not. When I look at the memory debugging graph in Xcode, I see a bunch of things of the form NSKVONotifying_MyClassName. Here's an example:
It does not look as though any of my objects have strong references to GRMorphController, so what am I to make of this?
I'm getting a runtime assertion failure like this:
"<FFRender3DView 0x616000271580> has reached dealloc but still has a super view. Super views strongly reference their children, so this is being over-released, or has been over-released in the past."
Looking at the code, I can't see any strong reference to the view except by its superview, so I can't see how it could be released other than by removal from its superview. My first instinct was to override release and set a breakpoint there, but that's not possible in ARC code.
I'm looking at a case where a handler for NSWindowDidBecomeMain gets the NSWindow* from the notification object and verifies that window.isVisible == YES, window.windowNumber > 0 and window.screen != nil. However, window.windowNumber is missing from the array [NSWindow windowNumbersWithOptions: NSWindowNumberListAllSpaces] and from CGWindowListCopyWindowInfo( kCGWindowListOptionOnScreenOnly, kCGNullWindowID ), how can that be?
The window number is in the array returned by CGWindowListCopyWindowInfo( kCGWindowListOptionAll, kCGNullWindowID ).
I'm seeing this issue in macOS 15, maybe 14, but not 13.
If I use [UTType exportedTypeWithIdentifier:] to get one of the types in my app's Info.plist, and then ask for the preferredFilenameExtension of that UTType, I get the wrong extension, i.e., not the first file extension listed for that UTI in my Info.plist. Is this one of those situations where AppKit is looking in some database that can get out of sync with what's actually in the Info.plist?
Topic:
UI Frameworks
SubTopic:
AppKit
I have a document-based macOS app written in Objective-C, and each document window contains a scrollable NSTextView. I know that printing can get complicated if you want to do nice pagination, but is there a quick and dirty way to get basic printing working? As it is, the print panel shows up, but its preview area is totally blank. Here's the current printing part of my NSDocument subclass.
- (NSPrintInfo *)printInfo
{
NSPrintInfo *printInfo = [super printInfo];
[printInfo setHorizontalPagination: NSPrintingPaginationModeFit];
[printInfo setHorizontallyCentered: NO];
[printInfo setVerticallyCentered: NO];
[printInfo setLeftMargin: 72.0];
[printInfo setRightMargin: 72.0];
[printInfo setTopMargin: 72.0];
[printInfo setBottomMargin: 72.0];
return printInfo;
}
- (void)printDocumentWithSettings:(NSDictionary<NSPrintInfoAttributeKey, id> *)printSettings
showPrintPanel:(BOOL)showPrintPanel
delegate:(id)delegate
didPrintSelector:(SEL)didPrintSelector
contextInfo:(void *)contextInfo
{
NSPrintInfo* thePrintInfo = [self printInfo];
[thePrintInfo setVerticallyCentered: NO ];
NSPrintOperation *op = [NSPrintOperation
printOperationWithView: _textView
printInfo: thePrintInfo ];
[op runOperationModalForWindow: _docWindow
delegate: delegate
didRunSelector: didPrintSelector
contextInfo: contextInfo];
}
When I upload a mac app for developer ID notarization, I get an error saying:
App Store Connect Operation Error
You must first sign the relevant contracts online (1048)
Why would App Store contracts be relevant to distribution outside the App Store?
Topic:
App Store Distribution & Marketing
SubTopic:
App Store Connect
Tags:
App Store Connect
macOS
Developer ID
When I use the Xcode 13 beta to build an app, view-based NSTableViews don't draw anything when the app is run under macOS 10.12 or earlier. I filed a bug (FB9278241), just wondering if anyone has any insight or workaround.
When I tried reading the orderedIndex property of an NSWindow, either in my own code or in lldb, I got 9223372036854775807, which happens to be the largest signed 64-bit integer. I can live without it, but just wondering if anyone else noticed this.
I have a project with several targets, which use different header paths and have some C++ code conditionalized by preprocessor symbols with #if. The targets build without error, but "live issues" produces errors, because apparently it's using the wrong headers but the right preprocessor symbols. I've tried nuking the derived data. Any other suggestions? I'm using Xcode 13.2.
In the documentation of -[NSBitmapImageRep initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel:], it says that the bitmap format mask can include NSBitmapFormatFloatingPointSamples, which suggests that the answer is yes, but it also says that the number of bits per component can be at most 16, which suggests that the answer is no.