On 31 Aug 2009, at 03:50, Kyle Sluder wrote:
Except his previous stack trace seems to indicate that the at-fault
code is in QTKit…
When logging image and library names as they are loaded and calls to
class and category +load methods it looks like you can see below.
Interestingly -- or no
Le 31 août 2009 à 02:27, Seth Willits a écrit :
On Aug 30, 2009, at 2:05 PM, Keith Duncan wrote:
Does anyone know what I *should* be breaking on? I'd obviously
like to track this down.
A fallback option is to break on NSLog/printf to see where that
message is being output from, but you c
On Aug 30, 2009, at 6:29 PM, Roland King wrote:
What does that macro do - does it create an autoreleased NSString
from its argument and then NSLog it? If so, that NSString is being
leaked as the message suggests.
Except his previous stack trace seems to indicate that the at-fault
code is
On 31 Aug 2009, at 03:29, Roland King wrote:
DKT_LOG("initialize ODE library");
What does that macro do - does it create an autoreleased NSString
from its argument and then NSLog it? If so, that NSString is being
leaked as the message suggests.
The macro DKT_LOG is implemented in the fo
Definitely sounds like a framework bug.
--Kyle Sluder
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsub
Klaus Backert wrote:
On 31 Aug 2009, at 02:45, Kyle Sluder wrote:
On Aug 30, 2009, at 5:33 PM, Klaus Backert online.de> wrote:
No Objective-C program code of my own has been executed up to this
point. I have not been able to manage this.
Are you doing anything before calling NSApplicat
On 31 Aug 2009, at 02:45, Kyle Sluder wrote:
On Aug 30, 2009, at 5:33 PM, Klaus Backert online.de> wrote:
No Objective-C program code of my own has been executed up to this
point. I have not been able to manage this.
Are you doing anything before calling NSApplicationMain?
My NSApplicati
On 30 aug 2009, at 17.33, Klaus Backert wrote:
For me such a message, e.g.
*** _NSAutoreleaseNoPool(): Object 0xa0c13290 of class NSCFString
autoreleased with no pool in place - just leaking
appeared in Mac OS X 10.5.8 already, and has not been there in
10.5.7. The function name has only on
On Aug 30, 2009, at 5:33 PM, Klaus Backert
wrote:
No Objective-C program code of my own has been executed up to this
point. I have not been able to manage this.
Are you doing anything before calling NSApplicationMain?
--Kyle Sluder
___
Cocoa-de
On 30 Aug 2009, at 23:00, Seth Willits wrote:
In Snow Leopard I started seeing this:
*** __NSAutoreleaseNoPool(): Object 0x100a49ec0 of class NSCFString
autoreleased with no pool in place - just leaking
I have no idea where this is happening so I tried to break in
_NSAutoreleaseNoPool j
On Aug 30, 2009, at 2:05 PM, Keith Duncan wrote:
Does anyone know what I *should* be breaking on? I'd obviously like
to track this down.
A fallback option is to break on NSLog/printf to see where that
message is being output from, but you could be using those
frequently elsewhere dependin
It's __ (2 underscores) and not _
--
Julien from his iPhone
Le 30 août 2009 à 23:00, Seth Willits a écrit :
In Snow Leopard I started seeing this:
*** __NSAutoreleaseNoPool(): Object 0x100a49ec0 of class NSCFString
autoreleased with no pool in place - just leaking
I have no idea wher
On Aug 30, 2009, at 2:00 PM, Seth Willits wrote:
Does anyone know what I *should* be breaking on? I'd obviously like
to track this down.
Check the 10.6 Foundation release notes. A lot of this stuff was
removed with no replacement.
--Kyle Sluder
___
Does anyone know what I *should* be breaking on? I'd obviously like
to track this down.
A fallback option is to break on NSLog/printf to see where that
message is being output from, but you could be using those frequently
elsewhere depending on what you're writing.
Keith
_
14 matches
Mail list logo
