Re: Crash in [[NSString alloc] initWithCString:msg]
Re: Crash in [[NSString alloc] initWithCString:msg]
- Subject: Re: Crash in [[NSString alloc] initWithCString:msg]
- From: Vince DeMarco <email@hidden>
- Date: Fri, 9 Apr 2004 15:10:55 -0700
It looks like the string msg is bad. Foundation is thread safe
immediately.
On Apr 9, 2004, at 11:35 AM, Glenn Andreas wrote:
At 6:34 PM +0200 4/9/04, JoanBa wrote:
Hi,
I'm having a problem with Cocoa... I'm using a GUI created with Xcode
+
Interface Builder, this GUI, which corresponds to class FlyController,
has a NSTextView object which I use as a console. I want to redirect
to
this view all messages generated from the different threads of my app,
so in class FlyController
[snip]
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSString *wip = [[NSString alloc] initWithCString:msg]; // offending
line !!!!!
Step in the debugger msg is probably pointing to junk.
objc_msgSend(mcontroller, sel_getUid("appendToLog:"), wip);
Out of curiousity, why bother with objc_msgSend when you could just
code the method call directly like the other lines:
[mcontroller appendToLog: wip]
[pool release];
return;
}
When I put my application in trace mode, a lot of messages need to be
output in the console and the apps crash with logs like this:
[snip]
Date/Time: 2004-04-08 13:32:46 +0200
OS Version: 10.3.3 (Build 7F44)
Report Version: 2
Command: FlyMotion
Path:
/projectes/FlyMotion/codi/FlyMotion/build/FlyMotion.app/Contents/
MacOS/
FlyMotion
Version: 0.1 (0.1)
PID: 1271
Thread: 2
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0xa1b1c1db
Thread 0:
[snip]
Thread 2 Crashed:
0 libSystem.B.dylib 0x900035a4 szone_malloc + 0x744
1 libSystem.B.dylib 0x90001174 malloc_zone_malloc + 0x94
2 com.apple.CoreFoundation 0x90191f8c _CFRuntimeCreateInstance +
0xc8
3 com.apple.CoreFoundation 0x90195268
__CFStringCreateImmutableFunnel3 + 0x634
4 com.apple.CoreFoundation 0x901a663c CFStringCreateWithCString +
0x5c
5 FlyUDPReceiver.ob 0x00298504 FlyUDPReceiver::msgToLog(char
const*, ...) + 0x108 (FlyUDPReceiver.mm:52)
6 FlyUDPReceiver.ob 0x00298ed8 FlyUDPReceiver::run() + 0x45c
(FlyUDPReceiver.mm:250)
7 thread.ob 0x000f9c88 threadLauncher + 0x44
(thread.cpp:28)
8 libSystem.B.dylib 0x900247e8 _pthread_body + 0x28
It looks like your secondary threads are created with a pthread
directly, and not via NSThread.
It may be that Cocoa isn't then in "multi-threaded mode" yet - until
an instance of NSThread exists, it runs in "single thread mode" and
none of the runtime data structures are locked with semaphores to
make them re-entrant.
See the documentation for [NSThread isMultiThreaded] for more
details, as well as all the other Cocoa threading documentation -
especially the section on thread safety:
* To use Cocoa from multiple threads, the Cocoa framework must
be put into multithreading mode, which activates greater thread
safety measures. This happens automatically when the first NSThread
is detached. If you use the POSIX thread APIs to create threads,
your application must detach at least one NSThread, which may
immediately exit, before any pthreads can use Cocoa.
--
Glenn Andreas email@hidden
mondo blobbo, Cythera, Theldrow, oh my!
Mad, Bad, and Dangerous to Know
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.