Objective C Command Failing When Run Through OSX Cron - objective-c

Question

I've coded a standalone Objective C command application. If I run it through a LaunchDaemon, it runs just fine when connected by an ObjC client application over DistriutedObjects communication. If I run it at command line, it runs just fine. If I run it when called by a Bash script, it runs just fine. However, in various ways that I've attempted to run this through the root user's crontab, it does a crash report about pointer allocation:
Apr 14 05:27:00 volomike cron[72531]: cron(72531,0x7fff7d2fa000) malloc: *** error for object 0x7fb9c8400213: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Apr 14 05:27:00 volomike diagnosticd[70689]: error evaluating process info - pid: 72531, puniqueid: 72531
Apr 14 05:27:00 volomike com.apple.xpc.launchd[1] (com.vix.cron[72531]): Service exited due to signal: Abort trap: 6
Apr 14 05:27:00 volomike com.apple.xpc.launchd[1] (com.apple.ReportCrash.Root[72550]): Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.ReportCrash.DirectoryService
Apr 14 05:27:00 volomike ReportCrash[72550]: Saved crash report for cron[72531] version 39 to /Library/Logs/DiagnosticReports/cron_2016-04-14-052700_volomike.crash
The significant part of that crash report reads:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
abort() called
*** error for object 0x7fb9c8400213: pointer being freed was not allocated
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff9490ff06 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff9c45e4ec pthread_kill + 90
2 libsystem_c.dylib 0x00007fff9345b6e7 abort + 129
3 libsystem_malloc.dylib 0x00007fff9c02f041 free + 425
4 cron 0x000000010367aa41 0x103677000 + 14913
5 cron 0x000000010367a7e4 0x103677000 + 14308
6 cron 0x0000000103679572 0x103677000 + 9586
7 cron 0x000000010367925a 0x103677000 + 8794
8 cron 0x000000010367885e 0x103677000 + 6238
9 libdyld.dylib 0x00007fff949835ad start + 1
In the various ways, I've done it with these various cron lines, but they crash immediately when trying to call the command, and even when I have NSLog() writing stuff to /var/log/system.log all the way from the start of main to the end of the application, nothing writes -- it's like when cron tries to call my command, it dies immediately with a crash report about pointer allocation.
41 5 * * * /bin/bash '/Applications/My App.app/Contents/Resources/mytoolcommand.sh' /q /sched
41 5 * * * /bin/bash '/Applications/My App.app/Contents/Resources/mytoolcommand.sh' /q /sched &
41 5 * * * '/Applications/My App.app/Contents/Resources/mytoolcommand' /q /sched
41 5 * * * '/Applications/My App.app/Contents/Resources/mytoolcommand' /q /sched &
Note again that if I do '/Applications/My App.app/Contents/Resources/mytoolcommand.sh' /q /sched, it runs just fine, as does /bin/bash '/Applications/My App.app/Contents/Resources/mytoolcommand.sh' /q /sched, as does '/Applications/My App.app/Contents/Resources/mytoolcommand' /q /sched
I even did a variation where cron called my mytoolcommand.sh script and simply wrote Hello World to /tmp/out.txt, and it ran just fine. So, I know my crontab is working.
Can you help me figure out what I'm doing wrong? Some suspected possible issues:
Perhaps OSX El Capitan is shutting my application down for some reason, such as not being signed properly. (I'm debugging right now. I never had signature issues come up before unless it dealt with .app folders. Besides, I can run it just fine from command line without having a signature warning.)
I have debug messages loading from main() right off the bat. They should be writing to /var/log/system.log, but they're not. This tells me the application is crashing immediately when called by cron. So, is there something special I need to load into my application's libraries in order for it to run properly when called under cron?
DEVELOPMENTS
I suspected that El Capitan Gatekeeper may have been the cause. So, I created a simplistic Objective C console application like so in a main.mm file and compiled.
#import <Foundation/Foundation.h>
int main(int argc, const char * argv[]) {
#autoreleasepool {
NSString *sTest = #"Hello World";
[sTest writeToFile:#"/tmp/test.txt" atomically:YES encoding:NSUTF8StringEncoding error:nil];
}
return 0;
}
Cron seems to run this just fine, so it's not looking like a Gatekeeper problem.
I got the problem to go away, but only briefly. I recompiled the project in a brand new project, copying over source code and settings. I then ran the command through the cron about 4 times without an issue. However, when I ran it the fifth time, it failed again and continued failing.
So, I guess I'm going to have to figure out how to convert this into a LaunchAgent.

Answer 1

The answer is YOU DON'T. You don't use cron anymore on OSX for your applications you are coding. Instead, switch to a LaunchAgent. Sure, Apple keeps it around for POSIX support, and therefore may keep it around for a very long time, but even their website encourages people to no longer use cron for application coding.
"Note: Although it is still supported, cron is not a recommended
solution. It has been deprecated in favor of launchd."
SOURCE: https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/ScheduledJobs.html
Unfortunately, though, LaunchAgents don't yet (in 10.11.4 at least) support cron-style syntax. (Yeah, I've already filed that suggestion to Apple for you.) So, there's no use of dash, comma, or backslash. Instead, it only supports an integer and multiple blocks to create each timeframe. And if that's not suitable enough, then set at least the most minimal timeframes and then do the rest of the code in whatever you are launching so that, for instance, if you want something only to run on the first Monday of the month, the LaunchDaemon launches in the first seven days but your application does a shutdown if it's not the first Monday of the month.