What's the best way to obtain a video cards model when there's no monitor attached? I can obtain this information fine by obtaining a CGDisplayIOServerPort from a CGDirectDisplayID then access via IORegistryEntry. But problem occurs when there's no monitor device attached, how can I get this information without a monitor present? programmatically id prefer. Thanks.
I have found some leaks in the system frameworks. I know exactly what property is over-retained when a new object of certain classes is created. Now my question is whether it is possible using this knowledge to avoid this leak? I could imagine to just send a release to the property. However that may be dangerous, because when Apple fixes the bug in the future that would lead to an over-release (and a crash). So would there be some way to avoid that? Thanks, Christiaan
Christiaan Hofman wrote: > I have found some leaks in the system frameworks. I know exactly what property is over-retained when a new object of certain classes is created. Now my question is whether it is possible using this knowledge to avoid this leak? I could imagine to just send a release to the property. However that may be dangerous, because when Apple fixes the bug in the future that would lead to an over-release (and a crash). So would there be some way to avoid that? Well, I would say the first thing that needs to happen is that you have to be really sure that you're seeing what you think you're seeing, and *not* misinterpreting a legitimate and intentional behavior. Overwhelmingly that seems to be the case for threads that start, "I've found some leaks in the system frameworks...." If you identified some of these leaks here, it might be that some others could verify your observations or explain them. Next is that any bugs really need to be submitted to Apple. As for dealing with them in your own code: The best solution is to find an alternative technique that sidesteps the bug. It may not result in theoretically optimal code, but it's much better than violating the memory contract by trying to second-guess the frameworks. Try really hard to go this route. It's very rare that there's exactly one way to do something. Failing that, and again making absolutely sure that this is *really* a bug, I would say that you might be able to get by by coming up with a very rigorous and detectable set of circumstances under which the bug exists and deal with the issue only when those circumstances hold true. Needless to say, one of those circumstances is going to be the precise versions of the specific framework(s) involved. If you detect any deviations from those conditions, don't mess with it.
On Aug 14, 2010, at 21:50, Gregory Weston wrote: > Christiaan Hofman wrote: > >> I have found some leaks in the system frameworks. I know exactly what property is over-retained when a new object of certain classes is created. Now my question is whether it is possible using this knowledge to avoid this leak? I could imagine to just send a release to the property. However that may be dangerous, because when Apple fixes the bug in the future that would lead to an over-release (and a crash). So would there be some way to avoid that? > > Well, I would say the first thing that needs to happen is that you have to be really sure that you're seeing what you think you're seeing, and *not* misinterpreting a legitimate and intentional behavior. Overwhelmingly that seems to be the case for threads that start, "I've found some leaks in the system frameworks...." If you identified some of these leaks here, it might be that some others could verify your observations or explain them. > Yes, I am 100% sure. I can consistently reproduce it using leaks and other tests (for instance sending an extra release to the object doesn't lead to a crash or a zombie). You can easily check it yourself, it's the initial PDFBorder ivar of a PDFAnnotationXXX (for any XXX that has a border initially). Here's a test: run the following with leaks: [[[[PDFAnnotationCircle alloc] init] autorelease] setBorder:nil]; or just run the following code that should crash in memory-managed code: [[[[[PDFAnnotationCircle alloc] init] autorelease] border] release]; You can't say that those results are as they should be.(Continue reading)
On Aug 15, 2010, at 15:35, Hans Larsen wrote: > Override the init method IMP for this class, call the original init, check for releaseCount after init of the border, release it if there's a problem. That might be the closest to a durable proof, and if it's fixed should give you some time to release a minor version with the code removed. > > - written on a software keyboard > HansL You should know that releaseCount says nothing. It doesn't count autorelease, and because it's private I don't know even what the true net releaseCount should be. And removing the code in a minor release is not an option, because it's not true that my users are using the same OS version that I do. Christiaan > > On 2010-08-14, at 16:34, Christiaan Hofman <cmhofman@...> wrote: > >> >> On Aug 14, 2010, at 21:50, Gregory Weston wrote: >> >>> Christiaan Hofman wrote: >>> >>>> I have found some leaks in the system frameworks. I know exactly what property is over-retained when a new object of certain classes is created. Now my question is whether it is possible using this knowledge to avoid this leak? I could imagine to just send a release to the property. However that may be dangerous, because when Apple fixes the bug in the future that would lead to an over-release (and a crash). So would there be some way to avoid that? >>>(Continue reading)
(Sorry. Had originally, unintentionally, not done a reply-to-all. I infer that it's okay to re-add the list as a recipient because the last part of your message included an appeal that obviously was addressed to a collective.) >>> or just run the following code that should crash in memory-managed code: >>> >>> [[[[[PDFAnnotationCircle alloc] init] autorelease] border] release]; >>> >>> You can't say that those results are as they should be. >> >> You can't say that they aren't. What you're consistently reproducing is that the default border object associated with a newly-created annotation object is being retained more than you expect for reasons of which you're unaware. You don't actually know, though, that it's unintentional so you don't know that it's a leak. > > I am NOT looking at the retainCount or something. I am looking at Leaks, which tells me that the object is leaked (if you don't believe the result, than you're basically saying that Leaks is wrong and a useless program). Moreover, the second statement SHOULD crash in memory managed code (or when I use NSZombiesEnabled it should report a zombie eventually), and it doesn't (and I do wait long enough). This OBVIOUSLY cannot be intentional. Note that after the first statement the object that's leaked is not even referenced anywhere anymore. If you don't use autorelease but multiple statements it's even more obvious. Actually, leaks has been known to report false positives under certain rare circumstances. And I dispute that the line of code you present above *should* crash in that there are numerous trivial scenarios in which it won't. It comes down to two things: The initial border object, by the time you have access to it, has been retained more than you expect. Leaks is unable to find anything that appears to be a reference to that object allowing that extra retain to be balanced.(Continue reading)
On Aug 15, 2010, at 16:25, Gregory Weston wrote: > (Sorry. Had originally, unintentionally, not done a reply-to-all. I infer that it's okay to re-add the list as a recipient because the last part of your message included an appeal that obviously was addressed to a collective.) > Yea, I sometimes get that as well, I find it annoying this list doesn't automatically reply to the list. >>>> or just run the following code that should crash in memory-managed code: >>>> >>>> [[[[[PDFAnnotationCircle alloc] init] autorelease] border] release]; >>>> >>>> You can't say that those results are as they should be. >>> >>> You can't say that they aren't. What you're consistently reproducing is that the default border object associated with a newly-created annotation object is being retained more than you expect for reasons of which you're unaware. You don't actually know, though, that it's unintentional so you don't know that it's a leak. >> >> I am NOT looking at the retainCount or something. I am looking at Leaks, which tells me that the object is leaked (if you don't believe the result, than you're basically saying that Leaks is wrong and a useless program). Moreover, the second statement SHOULD crash in memory managed code (or when I use NSZombiesEnabled it should report a zombie eventually), and it doesn't (and I do wait long enough). This OBVIOUSLY cannot be intentional. Note that after the first statement the object that's leaked is not even referenced anywhere anymore. If you don't use autorelease but multiple statements it's even more obvious. > > Actually, leaks has been known to report false positives under certain rare circumstances.(Continue reading)
There are indeed leaks in the frameworks. I verified at WWDC with one engineer (code was looked at) they had chosen to retain a delegate in one framework even though delegates generally do not get retained unless documented. Also one of the methods in the speech synthesizer returns a dictionary of properties (phonemes) you must release even though it's name suggests you must retain it yourself if you want it. Unfortunately, I can never have a clean analyzer build due to this. If you believe in your case, write a bug and possibly use an incident report for a definite solution. - Gary L. Wade (Sent from my iPhone)
On Sun, Aug 15, 2010 at 4:00 PM, Gary L. Wade <garywade@...> wrote: > There are indeed leaks in the frameworks. I verified at WWDC with one engineer (code was looked at) they had chosen to retain a delegate in one framework even though delegates generally do not get retained unless documented. Also one of the methods in the speech synthesizer returns a dictionary of properties (phonemes) you must release even though it's name suggests you must retain it yourself if you want it. Unfortunately, I can never have a clean analyzer build due to this. If you believe in your case, write a bug and possibly use an incident report for a definite solution. One way to fool the analyzer is to explicitly call objc_msgSend. Document it heavily and file a bug asking for the correct analyzer annotation to be added to the framework header file. --Kyle Sluder
On Aug 16, 2010, at 1:00, Gary L. Wade wrote: > There are indeed leaks in the frameworks. I verified at WWDC with one engineer (code was looked at) they had chosen to retain a delegate in one framework even though delegates generally do not get retained unless documented. Can you tell where, in case I ever need it? The only cases I do know about this is in CoreAnimation, but that's partly documented (but not completely, because of undocumented stuff that happens behind the scenes, and which adds more retains that are not documented). > Also one of the methods in the speech synthesizer returns a dictionary of properties (phonemes) you must release even though it's name suggests you must retain it yourself if you want it. Unfortunately, I can never have a clean analyzer build due to this. If you believe in your case, write a bug and possibly use an incident report for a definite solution. > > - Gary L. Wade (Sent from my iPhone) This particular framework (PDFKit) is actually full of bugs, some were confirmed by Apple engineers. Some are considerably more serious (reproducible crashers), and there I do not agree with the statement that you should only add a fix when you're sure that the bug is there. But in this case, I think it may just be better to do nothing (fixing a leak while risking a crasher is not a good idea, while fixing a crasher while risking a leak my be worthwhile). Christiaan
RSS Feed3 | |
|---|---|
1 | |
1 | |
5 | |
3 | |
6 | |
1 | |
6 | |
11 | |
28 | |
14 | |
2 | |
10 | |
14 | |
25 | |
11 | |
11 | |
7 | |
4 | |
15 | |
25 | |
38 | |
23 | |
29 | |
13 | |
14 | |
16 | |
17 | |
5 | |
50 | |
31 | |
63 | |
50 | |
57 | |
47 | |
81 | |
133 | |
38 | |
45 | |
65 | |
40 | |
52 | |
40 | |
38 | |
96 | |
80 | |
137 | |
128 | |
56 | |
82 | |
111 | |
141 | |
122 | |
73 | |
140 | |
85 | |
90 | |
60 | |
102 | |
110 | |
62 | |
54 | |
50 | |
42 | |
88 | |
89 | |
114 | |
170 | |
144 | |
71 | |
51 | |
180 | |
137 | |
138 | |
110 | |
129 | |
138 | |
123 | |
217 | |
175 | |
104 | |
84 | |
237 | |
219 | |
147 | |
219 | |
214 | |
328 | |
321 | |
155 | |
303 | |
303 | |
315 | |
285 | |
201 | |
239 | |
279 | |
500 | |
488 | |
404 | |
541 | |
541 | |
450 | |
560 | |
590 | |
597 | |
550 | |
376 | |
369 | |
477 | |
716 | |
480 | |
460 | |
521 | |
457 | |
462 | |
605 | |
461 | |
580 | |
606 | |
519 |
