Apple

On Feb 8, 2008, at 10:25 AM, Seth Pellegrino wrote:

Hello list,

I'm attempting to run the maxima engine (http://maxima.sourceforge.net/) via an NSTask to provide a simple GUI, very much like Apple's Moriarity (http://developer.apple.com/samplecode/Moriarity/index.html). In fact, changing line 96 (in -sleuth:) of MoriarityController.m to (assuming maxima is properly installed in /usr/local/bin):

searchTask=[[TaskWrapper alloc] initWithController:self arguments:[NSArray arrayWithObjects:@"/usr/local/bin/maxima",[@"--batch-string=" stringByAppendingString:[findTextField stringValue]],nil]];

gives both an approximation of my goal and excellent sample of my difficulty. When run via finder, the modified Moriarity runs exactly as expected; it serves as a command line interface. However, when run from Xcode, the application works only once, subsequent attempts to evaluate expressions result in a program hang/crash. The confusing exception to this rule is that, if gdb is forced attached to the application before the crash, the program does not hang, but instead returns maxima's output (something is causing it to seg fault). The error logs for these events can be found below.

At this point, I find myself completely lost. What could be causing this behavior? I apologize for the open ended nature of my question, any guidance at all would be greatly appreciated.

Thank you for your time,

Seth Pellegrino

In the event of a crash, the stack traces on each of the threads is:

Thread 1:

#0 0x956668e6 in mach_msg_trap ()
#1 0x9566e0dc in mach_msg ()
#2 0x90e8a0fe in CFRunLoopRunSpecific ()
#3 0x90e8ad38 in CFRunLoopRunInMode ()
#4 0x94a108a4 in RunCurrentEventLoopInMode ()
#5 0x94a106bd in ReceiveNextEventCommon ()
#6 0x94a10531 in BlockUntilNextEventMatchingListInMode ()
#7 0x90602d5b in _DPSNextEvent ()
#8 0x906026a0 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#9 0x905fb6d1 in -[NSApplication run] ()
#10 0x905c89ba in NSApplicationMain ()
#11 0x00001eca in main (argc=1, argv=0xbffff770) at main.m:5

Thread 2:

#0 0x9566dace in __semwait_signal ()
#1 0x9566d94f in nanosleep$UNIX2003 ()
#2 0x9566d896 in usleep$UNIX2003 ()
#3 0x90669122 in -[NSUIHeartBeat _heartBeatThread:] ()
#4 0x952f504d in -[NSThread main] ()
#5 0x952f4bf4 in __NSThread__main__ ()
#6 0x95697075 in _pthread_start ()
#7 0x95696f32 in thread_start ()

Thread 3:

#0 0x956968e6 in kevent ()
#1 0x90e5f42f in __monitor_file_descriptor__ ()
#2 0x95697075 in _pthread_start ()
#3 0x95696f32 in thread_start ()

If gdb is attached before the crash, maxima returns multiple segfaults that look like:

*** - handle_fault error2 ! address = 0x1b7560 not in [0x19d9b000,0x1a14f088) !
SIGSEGV cannot be cured. Fault address = 0x1b7560.
Permanently allocated: 88736 bytes.
Currently in use: 7533304 bytes.
Free space: 386302 bytes.

References:
	>gdb/Xcode crashing process run via NSTask (From: Seth Pellegrino <email@hidden>)