Re: A question about NSScreen being autoreleased during loadNib()
Re: A question about NSScreen being autoreleased during loadNib()
- Subject: Re: A question about NSScreen being autoreleased during loadNib()
- From: Fritz Anderson <email@hidden>
- Date: Tue, 04 Jun 2013 14:00:10 -0500
On 28 May 2013, at 5:50 AM, "Jacky.Seraph Mu" <email@hidden> wrote:
[On a Retina machine, after instantiating an NSWindow from a new window controller, an NSScreen pointer obtained earlier from another window/controller apparently is released, and the debugger shows funny values in its struct members. The backtrace identified with the screen release shows it happens in a cascade from an NSArray, which I'd wager is the static NSScreen screen list.]
Random comments, most of which are merely suggestive, and some of which you will say are obviously wrong-headed; but if everything you thought was impossible was in fact impossible, you wouldn't have a bug:
You don't outright say what the consequence of the strange behavior is. Do you crash? Where?
I'd not be surprised if NSScreen on HiDPI machines worked differently than on "normal" ones. The struct members aren't API, and don't necessarily mean what they obviously meant in earlier versions.
Are you using ARC?
If not, do you -retain the screen object while you are interested in it? It would be strange if the current autorelease pool were drained in the course of the code you show, but not impossible.
If you're not using ARC, have you tried zombie detection?
Have you run the application against the Allocations instrument, with full retain/release histories captured?
Does the other debugger (lldb vs gdb) help?
Just for grins, what do you get when you "po screen"? If it's still an NSScreen, or apparent subclass, overrelease isn't your problem.
Are you accessing the passed-in NSScreen pointer after the line you flag? How? Does it become "normal" then?
What do you get if you acquire a fresh NSScreen pointer? Compared to the new value? Compared to the one before the putative release?
I believe sending -window to your controllers will instantiate the windows. What leads you to believe that window.screen is valid at the time you call it? Is the window on-screen then?
This is wild even for me, but do you make _any_ changes to the display parameters between the time you acquire the pointer and the time you discover the fault? The API does not _promise_ that NSScreen objects will be per-screen singletons; a change in display configuration might result in the screen list being thrown away. (I'd be astonished if that were so, but there is no contract that it not be.)
— F
--
Fritz Anderson
Xcode 4 Unleashed: 4.5 supplement for free!
http://www.informit.com/store/xcode-4-unleashed-9780672333279
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden