Open Instruments, add the object allocation instrument, turn on
reference count recording and zombie detection in the instrument,
and then record your app. Do what you need to do to reproduce the
problem. When it triggers, you'll get a backtrace of both the
offending access and everything that retained or released the
object. If that takes too long, then have the instrument only record
NSUndoManager objects instead of everything.
Great! thanks - I'll give that a shot.
I've just tried taking my subclass out of the equation and get the
same result, implying that this ought to be seen by everyone. It's
possible it's being masked by having very large numbers of undo levels
- I set just 4 so I can trigger the bug quickly. The crash occurs when
beginning to type after selecting text in a text view.
#0 0x95eebd27 in ___forwarding___
#1 0x95eebbf2 in __forwarding_prep_0___
#2 0x96182052 in -[_NSUndoStack _removeBottom]
#3 0x9605adde in -[_NSUndoStack markEnd]
#4 0x9605acf9 in -[NSUndoManager _endUndoGroupRemovingIfEmpty:]
#5 0x9605ab39 in -[NSUndoManager endUndoGrouping]
#6 0x9601d01b in +[NSUndoManager(NSPrivate) _endTopLevelGroupings]
#7 0x902f7725 in -[NSApplication run]
#8 0x902ef735 in NSApplicationMain
#9 0x0010048c in main at main.m:14
On 16/09/2009, at 11:54 AM, Graham Cox wrote:
While I am subclassing NSUndoManager in this case it's not doing
anything special - endUndoGrouping just calls super. However I would
be prepared to believe that something in the creation of the undo
task is wrong where a bit more work is being done in my subclass,
like coalescing identical consecutive tasks into one.
_______________________________________________
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/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
