ieleak-devel Mailing List for IE Leak Detector (Drip/IE Sieve) (Page 5)
Brought to you by:
matthiasmiller
You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
(13) |
Jun
(32) |
Jul
(2) |
Aug
(27) |
Sep
(20) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
(10) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Matthias M. <Blog@OutOfHanwell.com> - 2006-05-31 23:01:41
|
I haven't had a chance to look at it closely, but these might be helpful: * http://blogs.msdn.com/ericlippert/archive/2004/10/07/239289.aspx * http://blogs.msdn.com/greggm/archive/2004/08/23/218964.aspx I'd like to look into further when I have a chance. -Matthias Miller Johan Rosman wrote: > Hi Matthias, > > Sounds reasonable, catching all functions by hooking the attachEvent() > function in the same way as we hook into createElement() and > cloneNode() etc.. In the onpropertychange eventhandler we can catch > all property changes where the value of the property is typeof function. > > But maybe there is a way to collect all the function instances in > general? Functions can be either static in the javascript soruce or > created dynamically with new Function() or var x = function() {....} > for example. I am thinking isn't there a kind of debugger API > available for the scripthost engine? I think there should be, because > also the javascript debuggers are able to give all kind of information > about functions, call stack, locals etc. May be we can hook into the > script engine? I didn't explore on that further. Any Ideas? > > Regards, > Johan. > > > ----- Original Message ----- From: "Matthias Miller" > <Blog@OutOfHanwell.com> > To: <iel...@li...> > Sent: Wednesday, May 31, 2006 3:47 PM > Subject: [Ieleak-devel] reporting cross references > > >> Johan Rosman suggested a Cross Reference feature, so I'm splitting >> this off into another thread. Here's the original idea: >>> Another very usefull addition for 'Drip' could be: Cross Reference: >>> When you have the list of leaked elements you see a 'refcount' >>> showing the number of references to a leaked element. It will be >>> definately very helpfull to detect the reason of a memory leak if >>> you are able to see which elements (or script) are still holding a >>> reference to the leaked element. As soon you know who are pointing >>> to a leaked element it is very easy to solve and avoid the leak. I >>> am thinking for some time how to implement such a feature but until >>> now the only thing i can imagine is to iterate over all properties >>> of all 'elements in use' and see if there are some expando >>> properties pointing to another HTML element. You can show this in >>> the UI in a tree-control for example. But the biggest pain are the >>> closures. (references to HTML elements enclosed in function >>> instances e.g. eventhandlers). Any ideas how to implement such a >>> cross reference feature? >> When iterating over properties, I think Drip can fairly easily flag >> which object properties are nodes and which are other objects. These >> could perhaps be displayed in a bold font or in an alternate color, >> allowing the user to easily look at an element and find expandos. >> This seems simple enough. >> >> The closures are the trick, of course, and I don't know if we can >> catch all scenarios for closures. Obviously, if a closure causes a >> circular reference, these functions will be leaked. Just as Drip >> collects references to DOM nodes, it could also collect references to >> functions in attachEvent or through other means. These functions, if >> leaked, would somehow be reported when Drip reports memory leaks. The >> user could look at the function source code, identify its function >> name, find the corresponding location in the JavaScript, and fix the >> closure. This does not provide specifics on which element was leaked, >> but it should help a lot in pin-pointing the problem. >> >> Ideas? Am I crazy? The trick will be getting references to all of the >> appropriate functions, I think. >> >> -Matthias Miller >> >> >> >> ------------------------------------------------------- >> All the advantages of Linux Managed Hosting--Without the Cost and Risk! >> Fully trained technicians. The highest number of Red Hat >> certifications in >> the hosting industry. Fanatical Support. Click to learn more >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 >> _______________________________________________ >> Ieleak-devel mailing list >> Iel...@li... >> https://lists.sourceforge.net/lists/listinfo/ieleak-devel >> > > > > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without the Cost and Risk! > Fully trained technicians. The highest number of Red Hat > certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > _______________________________________________ > Ieleak-devel mailing list > Iel...@li... > https://lists.sourceforge.net/lists/listinfo/ieleak-devel > > |
From: Johan R. <jsr...@wa...> - 2006-05-31 20:52:56
|
Hi Matthias, Sounds reasonable, catching all functions by hooking the attachEvent() function in the same way as we hook into createElement() and cloneNode() etc.. In the onpropertychange eventhandler we can catch all property changes where the value of the property is typeof function. But maybe there is a way to collect all the function instances in general? Functions can be either static in the javascript soruce or created dynamically with new Function() or var x = function() {....} for example. I am thinking isn't there a kind of debugger API available for the scripthost engine? I think there should be, because also the javascript debuggers are able to give all kind of information about functions, call stack, locals etc. May be we can hook into the script engine? I didn't explore on that further. Any Ideas? Regards, Johan. ----- Original Message ----- From: "Matthias Miller" <Blog@OutOfHanwell.com> To: <iel...@li...> Sent: Wednesday, May 31, 2006 3:47 PM Subject: [Ieleak-devel] reporting cross references > Johan Rosman suggested a Cross Reference feature, so I'm splitting this > off into another thread. Here's the original idea: >> Another very usefull addition for 'Drip' could be: Cross Reference: When >> you have the list of leaked elements you see a 'refcount' showing the >> number of references to a leaked element. It will be definately very >> helpfull to detect the reason of a memory leak if you are able to see >> which elements (or script) are still holding a reference to the leaked >> element. As soon you know who are pointing to a leaked element it is very >> easy to solve and avoid the leak. I am thinking for some time how to >> implement such a feature but until now the only thing i can imagine is to >> iterate over all properties of all 'elements in use' and see if there are >> some expando properties pointing to another HTML element. You can show >> this in the UI in a tree-control for example. But the biggest pain are >> the closures. (references to HTML elements enclosed in function instances >> e.g. eventhandlers). Any ideas how to implement such a cross reference >> feature? > When iterating over properties, I think Drip can fairly easily flag which > object properties are nodes and which are other objects. These could > perhaps be displayed in a bold font or in an alternate color, allowing the > user to easily look at an element and find expandos. This seems simple > enough. > > The closures are the trick, of course, and I don't know if we can catch > all scenarios for closures. Obviously, if a closure causes a circular > reference, these functions will be leaked. Just as Drip collects > references to DOM nodes, it could also collect references to functions in > attachEvent or through other means. These functions, if leaked, would > somehow be reported when Drip reports memory leaks. The user could look at > the function source code, identify its function name, find the > corresponding location in the JavaScript, and fix the closure. This does > not provide specifics on which element was leaked, but it should help a > lot in pin-pointing the problem. > > Ideas? Am I crazy? The trick will be getting references to all of the > appropriate functions, I think. > > -Matthias Miller > > > > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without the Cost and Risk! > Fully trained technicians. The highest number of Red Hat certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > _______________________________________________ > Ieleak-devel mailing list > Iel...@li... > https://lists.sourceforge.net/lists/listinfo/ieleak-devel > |
From: Matthias M. <Blog@OutOfHanwell.com> - 2006-05-31 13:48:17
|
Johan Rosman suggested a Cross Reference feature, so I'm splitting this off into another thread. Here's the original idea: > Another very usefull addition for 'Drip' could be: Cross > Reference: When you have the list of leaked elements you see a > 'refcount' showing the number of references to a leaked element. It > will be definately very helpfull to detect the reason of a memory leak > if you are able to see which elements (or script) are still holding a > reference to the leaked element. As soon you know who are pointing to > a leaked element it is very easy to solve and avoid the leak. I am > thinking for some time how to implement such a feature but until now > the only thing i can imagine is to iterate over all properties of all > 'elements in use' and see if there are some expando properties > pointing to another HTML element. You can show this in the UI in a > tree-control for example. But the biggest pain are the closures. > (references to HTML elements enclosed in function instances e.g. > eventhandlers). Any ideas how to implement such a cross reference > feature? When iterating over properties, I think Drip can fairly easily flag which object properties are nodes and which are other objects. These could perhaps be displayed in a bold font or in an alternate color, allowing the user to easily look at an element and find expandos. This seems simple enough. The closures are the trick, of course, and I don't know if we can catch all scenarios for closures. Obviously, if a closure causes a circular reference, these functions will be leaked. Just as Drip collects references to DOM nodes, it could also collect references to functions in attachEvent or through other means. These functions, if leaked, would somehow be reported when Drip reports memory leaks. The user could look at the function source code, identify its function name, find the corresponding location in the JavaScript, and fix the closure. This does not provide specifics on which element was leaked, but it should help a lot in pin-pointing the problem. Ideas? Am I crazy? The trick will be getting references to all of the appropriate functions, I think. -Matthias Miller |
From: Matthias M. <Blog@OutOfHanwell.com> - 2006-05-28 02:17:16
|
Matthias Miller wrote: > At this point, it looks like the proposed changes are: > > -Put two buttons on the main dialog: "View DOM Usage" and "View DOM > Leaks" (in that order). Both will use the same underlying dialog, but > with different titles, etc. > > -Add a radio button to the DOM Usage/Leaks dialog that says: > (-) Show new DOM [usage/leaks] ( ) Show all DOM [usage/leaks] > These radio buttons apply only to the respective dialog. Opening the > DOM Usage dialog will not affect the DOM Leaks dialog, and vice versa. > ... > If we're agreed on these changes, I'll be creating several relatively > small tracker items for these jobs. Or I'll just implement these changes (which is what I've done). I haven't implemented the real-time "Total DOM References" counter because of performance concerns. Because Drip maintains a reference to all elements, it must have its own garbage collection pass following IE's garbage collection in order to get an accurate number. The more elements it tracks, the more expensive this becomes. A good solution may be for Drip to run its own garbage collection pass in an OnKickIdle handler (perhaps one element at a time), allowing it to stay up-to-date without locking up the application. -Matthias |
From: Matthias M. <Blog@OutOfHanwell.com> - 2006-05-24 12:54:23
|
I forgot to mention these changes as well: -Add a "Total DOM Nodes" counter to the main dialog. I'm still undecided about the real-time summary showing the nodes with the most references. This is also something that can be discussed now (if you like) or can be deferred until later. Matthias Miller wrote: > I like your analogy. What you described is referred to as "setting the > tare". I believe most electronic scales will have a button simply > labeled "TARE". > > I agree with you on the "Clear in Use" button. Isn't that the purpose > of the radio buttons? Johan, I'm glad to discuss reasons that we > should or should not add it, if you think it should be added. > > At this point, it looks like the proposed changes are: > > -Put two buttons on the main dialog: "View DOM Usage" and "View DOM > Leaks" (in that order). Both will use the same underlying dialog, but > with different titles, etc. > > -Add a radio button to the DOM Usage/Leaks dialog that says: > (-) Show new DOM [usage/leaks] ( ) Show all DOM [usage/leaks] > These radio buttons apply only to the respective dialog. Opening the > DOM Usage dialog will not affect the DOM Leaks dialog, and vice versa. > > -The "Clear in Use" button will not be added, at least for now. > > If we're agreed on these changes, I'll be creating several relatively > small tracker items for these jobs. > > -Matthias |
From: Matthias M. <Blog@OutOfHanwell.com> - 2006-05-24 12:50:41
|
I like your analogy. What you described is referred to as "setting the tare". I believe most electronic scales will have a button simply labeled "TARE". I agree with you on the "Clear in Use" button. Isn't that the purpose of the radio buttons? Johan, I'm glad to discuss reasons that we should or should not add it, if you think it should be added. At this point, it looks like the proposed changes are: -Put two buttons on the main dialog: "View DOM Usage" and "View DOM Leaks" (in that order). Both will use the same underlying dialog, but with different titles, etc. -Add a radio button to the DOM Usage/Leaks dialog that says: (-) Show new DOM [usage/leaks] ( ) Show all DOM [usage/leaks] These radio buttons apply only to the respective dialog. Opening the DOM Usage dialog will not affect the DOM Leaks dialog, and vice versa. -The "Clear in Use" button will not be added, at least for now. If we're agreed on these changes, I'll be creating several relatively small tracker items for these jobs. -Matthias Hristo Deshev wrote: > Hi guys, > > I like the idea of both displaying absolute and relative element usage > statistics. > > I don't know if having an explicit "Clear In Use" button is better as > a UI experience. It might be hard to understand for some people. I > am thinking of renaming it to "Set baseline" or "Establish baseline." > I might not know the correct English term here -- I am thinking about > the analogy with electronic scales. When you want to weigh a liquid > in a bowl, you place the bowl on the scales, press a button that will > zero out the display, and then you pour the liquid inside the bowl. > The scale will display the weight of the liquid only, not taking the > weight of the bowl in account.. > > That analogy might help people with the UI. Anyway the default of > displaying elements looks good enough. I don't know if making the > interface more complex will be worth it. One thing is certain -- we > can easily add the new button later. > > Hristo Deshev |
From: Hristo D. <hri...@gm...> - 2006-05-24 08:54:17
|
SGkgZ3V5cywKCkkgbGlrZSB0aGUgaWRlYSBvZiBib3RoIGRpc3BsYXlpbmcgYWJzb2x1dGUgYW5k IHJlbGF0aXZlIGVsZW1lbnQgdXNhZ2UKc3RhdGlzdGljcy4KCkkgZG9uJ3Qga25vdyBpZiBoYXZp bmcgYW4gZXhwbGljaXQgIkNsZWFyIEluIFVzZSIgYnV0dG9uIGlzIGJldHRlciBhcyBhIFVJCmV4 cGVyaWVuY2UuICBJdCBtaWdodCBiZSBoYXJkIHRvIHVuZGVyc3RhbmQgZm9yIHNvbWUgcGVvcGxl LiAgSSBhbSB0aGlua2luZwpvZiByZW5hbWluZyBpdCB0byAiU2V0IGJhc2VsaW5lIiBvciAiRXN0 YWJsaXNoIGJhc2VsaW5lLiIgIEkgbWlnaHQgbm90IGtub3cKdGhlIGNvcnJlY3QgRW5nbGlzaCB0 ZXJtIGhlcmUgLS0gSSBhbSB0aGlua2luZyBhYm91dCB0aGUgYW5hbG9neSB3aXRoCmVsZWN0cm9u aWMgc2NhbGVzLiAgV2hlbiB5b3Ugd2FudCB0byB3ZWlnaCBhIGxpcXVpZCBpbiBhIGJvd2wsIHlv dSBwbGFjZSB0aGUKYm93bCBvbiB0aGUgc2NhbGVzLCBwcmVzcyBhIGJ1dHRvbiB0aGF0IHdpbGwg emVybyBvdXQgdGhlIGRpc3BsYXksIGFuZCB0aGVuCnlvdSBwb3VyIHRoZSBsaXF1aWQgaW5zaWRl IHRoZSBib3dsLiAgVGhlIHNjYWxlIHdpbGwgZGlzcGxheSB0aGUgd2VpZ2h0IG9mCnRoZSBsaXF1 aWQgb25seSwgbm90IHRha2luZyB0aGUgd2VpZ2h0IG9mIHRoZSBib3dsIGluIGFjY291bnQuLgoK VGhhdCBhbmFsb2d5IG1pZ2h0IGhlbHAgcGVvcGxlIHdpdGggdGhlIFVJLiAgQW55d2F5IHRoZSBk ZWZhdWx0IG9mCmRpc3BsYXlpbmcgZWxlbWVudHMgbG9va3MgZ29vZCBlbm91Z2guICBJIGRvbid0 IGtub3cgaWYgbWFraW5nIHRoZSBpbnRlcmZhY2UKbW9yZSBjb21wbGV4IHdpbGwgYmUgd29ydGgg aXQuICBPbmUgdGhpbmcgaXMgY2VydGFpbiAtLSB3ZSBjYW4gZWFzaWx5IGFkZAp0aGUgbmV3IGJ1 dHRvbiBsYXRlci4KCkhyaXN0byBEZXNoZXYKCgpPbiA1LzIzLzA2LCBKb2hhbiBSb3NtYW4gPGpz cm9zbWFuQHdhbmFkb28ubmw+IHdyb3RlOgo+Cj4gSGkgTWF0dGhpYXMsCj4KPiBQbGVhc2Ugc2Vl IG15IGNvbW1lbnRzIGlubGluZToKPgo+IFJlZ2FyZHMsCj4gSm9oYW4KPiAtLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogIk1hdHRoaWFzIE1pbGxlciIgPEJsb2dAT3V0T2ZIYW53 ZWxsLmNvbT4KPiBUbzogPGllbGVhay1kZXZlbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQ+Cj4gU2Vu dDogTW9uZGF5LCBNYXkgMjIsIDIwMDYgNjowMyBQTQo+IFN1YmplY3Q6IFJlOiBbSWVsZWFrLWRl dmVsXSByZWFsLXRpbWUgdXNhZ2UgcmVwb3J0aW5nCj4KPgo+ID4ganNyb3NtYW4gd3JvdGU6Cj4g Pj4gVGhlIGJ1dHRvbiAnQ2hlY2sgTGVha3MnICBjb3VsZCBiZSByZXBsYWNlZCBpbiAzIHNpbmds ZSBidXR0b25zOiBBKQo+ID4+IEFib3V0OmJsYW5rICBCKSBTaG93IGluIFVzZSBDKSBDbGVhciBp biBVc2UuICBwcmVzc2luZyB0aGUgYnV0dG9ucyBBKQo+ID4+IGZvbGxvd2VkIGJ5IEIpIHdpbGwg aGF2ZSB0aGUgc2FtZSBlZmZlY3QgYXMgcHJlc3NpbmcgdGhlICdDaGVjayBMZWFrcycKPiA+PiAu Li4uCj4gPiBJIHRoaW5rIHRoaXMgd291bGQgYmUgdXNlZnVsLiBDYW4gd2Ugc2ltcGxpZnkgdGhl IHVzZXIgaW50ZXJmYWNlCj4gc29tZXdoYXQ/Cj4gPiBJIHdvdWxkIGxpa2UgdG8gbWFrZSBpdCBl YXN5IGZvciB3ZWIgZGV2ZWxvcGVycyB3aG8gYXJlIGxlc3MgZmFtaWxpYXIKPiB3aXRoCj4gPiB0 aGUgaW5uZXIgd29ya2luZ3Mgb2YgRHJpcC4gV2hhdCBpZiB3ZSB3b3VsZCBoYXZlIHR3byBidXR0 b25zIG9uIHRoZQo+IG1haW4KPiA+IGRpYWxvZzogIlZpZXcgRE9NIFVzYWdlIiBhbmQgIlZpZXcg RE9NIExlYWtzIj8KPgo+ID4gT25lIHF1ZXN0aW9uIGFib3V0IHRoZSAiQ2xlYXIgaW4gVXNlIiBi dXR0b24uIElmIHlvdSBjbGljayB0aGF0IGJ1dHRvbiwKPiA+IHdpbGwgdGhvc2UgZWxlbWVudHMg c3RpbGwgc2hvdyB1cCBpbiB0aGUgbGlzdCBvZiBtZW1vcnkgbGVha3M/IEFsc28sCj4gd2hhdAo+ ID4gaGFwcGVucyByZWZlcmVuY2VzIGFyZSBhZGRlZCB0byBvciByZW1vdmVkIGZyb20gdGhhdCBl bGVtZW50PyBEb2VzIGl0Cj4gPiByZWFwcGVhciBpbiB0aGUgbGlzdD8KPiBZZXMgaWYgcmVmY291 bnQgaW5jcmVhc2VzIHRoZW4gdGhlIGhpZGRlbiBlbGVtZW50IHdpbGwgcmVhcHBlYXIgaW4gdGhl Cj4gbGlzdC4KPiBXaGVuIHRoZSByZWZjb3VudCBkZWNyZWFzZXMgeW91IGNhbiBrZWVwIHRoZW0g aGlkZGVuIElNTy4gSG93ZXZlciB3aXRoIGEKPiAnc2hvdyBhbGwnIHRvZ2dsZSB5b3UgY2FuIG1h a2UgYWxsIChoaWRkZW4pIGVsZW1lbnRzIHZpc2libGUgYWdhaW4uCj4KPiA+IEkgd29uZGVyIHdo ZXRoZXIgdGhpcyBidXR0b24gY291bGQgYmUgbW92ZWQgdG8gdGhlICJWaWV3IERPTSBVc2FnZSIK PiA+IGRpYWxvZywgcGVyaGFwcyBjYWxsZWQgIkNsZWFyIExpc3QiLiBXaGVuIHlvdSBjbGljayB0 aGlzIGJ1dHRvbiwgeW91Cj4gd291bGQKPiA+IHN0aWxsIHNlZSB0aGVtIHdoZW4geW91IGNoZWNr IGZvciBtZW1vcnkgbGVha3MuIFRodXMsIEkgYXNzdW1lIHRoYXQgdGhpcwo+ID4gYnV0dG9uIGRv ZXMgbm90IGxpdGVyYWxseSBjbGVhciB0aGUgbGlzdCwgcGVyIHNlLCBidXQgc2ltcGx5IHRyYWNr cyB0aGUKPiA+IG51bWJlciBvZiByZWZlcmVuY2VzIGFuZCBzdXBwcmVzc2VzIHRoZW0gaW4gdGhl ICJWaWV3IERPTSBVc2FnZSIgZGlhbG9nCj4gaWYKPiA+IG51bWJlciBvZiByZWZlcmVuY2VzIGhh c24ndCBpbmNyZWFzZWQuIEdpdmVuIHRoaXMgZGVzaWduLCB0aGUgbGlzdCBvZgo+ID4gaXRlbXMg d291bGQgc3RpbGwgYmUgY2xlYXJlZCB3aGVuIHlvdSBjbGljayB0aGUgVmlldyBET00gTGVha3Mg YnV0dG9uCj4gPiAoanVzdCBhcyBpdCBkb2VzIG5vdy4pCj4gPgo+ID4gQXMgYW4gYWx0ZXJuYXRp dmUgdG8gdGhlIENsZWFyIGluIFVzZSBvciBDbGVhciBMaXN0IGJ1dHRvbiwgdGhlIFZldyBET00K PiA+IFVzYWdlIGRpYWxvZyBjb3VsZCBoYXZlIGEgdG9nZ2xlIGJ1dHRvbiB0byBzd2l0Y2ggYmV0 d2VlbiBhbGwgZWxlbWVudHMKPiBhbmQKPiA+IG9ubHkgdGhvc2UgZWxlbWVudHMgdGhhdCBoYXZl IGNoYW5nZWQgc2luY2UgdGhlIGRpYWxvZyB3YXMgbGFzdCBvcGVuZWQuCj4gPiBUaGlzIGNvdWxk IGJlIHVzZWZ1bCBpbiBib3RoIGRpYWxvZ3MsIEkgZ3Vlc3MuCj4gWW91J3IgcmlnaHQgeW91IGhh dmUgdGhlIHNhbWUgc29sdXRpb24gaW4gbWluZCA6LSksICBJIHVzZWQgY29sb3JzIHRvbyB0bwo+ IGluZGljYXRlIG5ldyBlbGVtZW50cyBpbiB1c2UgYW5kIGEgZGlmZmVyZW50IGNvbG9yIGZvciBl bGVtZW50cyB3aXRoCj4gaW5jcmVhc2VkIHJlZmNvdW50IGFuZCBhIHNpbXBsZSB0b2dnbGUgJ3No b3cgYWxsJy4gQW5kIGFsc28gdGhlCj4gbWFpbmJyb3dzZXIKPiBkaWFsb2cgYW5kIHRoZSAobW9k ZWxlc3MpIFZpZXcgRE9NIGRpYWxvZyBhbHNvIGhhcyB0aGUgc2FtZSAyIGJ1dHRvbnMKPiAnU2hv dwo+IGluIFVzZScgYW5kICdDbGVhciBpbiBVc2UnLiBUaGlzIGFyZSBhbGwgZmFpciBzaW1wbGUg Y2hhbmdlcyBpbiB0aGUgVUkuCj4gSnVzdAo+IG9ubHkgMiBhZGRpdGlvbmFsIGJ1dHRvbnMgb24g Ym90aCBkaWFsb2dzLgo+Cj4gPgo+ID4gTXkgZ29hbCBpcyB0byBwcm92aWRlIGEgc2ltcGxlIGlu dGVyZmFjZSBmb3IgZmluZGluZyBtZW1vcnkgbGVha3MsIHdoaWxlCj4gPiBzdGlsbCBjYXRlcmlu ZyB0byBtb3JlIGFkdmFuY2VkIHVzZXJzLgo+IElNTywgdGhpcyB0b29sIHdpbCBvbmx5IGJlIHVz ZWQgYnkgIGFkdmFuY2VkIHVzZXJzICh3ZWIgZnJvbnQtZW5kCj4gZGV2ZWxvcGVycykKPiB3aG8g aGF2ZSB0aGUga25vd2xlZGdlIHRvIHJlcGFpciB0aGUgamF2YXNjcmlwdCBhbmQgd29ya2Fyb3Vu ZCB0aGUgSUUKPiBsZWFrcy4KPgo+ID4KPiA+IC1NYXR0aGlhcwo+ID4KPiA+Cj4gPgo+ID4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ID4g VXNpbmcgVG9tY2F0IGJ1dCBuZWVkIHRvIGRvIG1vcmU/IE5lZWQgdG8gc3VwcG9ydCB3ZWIgc2Vy dmljZXMsCj4gc2VjdXJpdHk/Cj4gPiBHZXQgc3R1ZmYgZG9uZSBxdWlja2x5IHdpdGggcHJlLWlu dGVncmF0ZWQgdGVjaG5vbG9neSB0byBtYWtlIHlvdXIgam9iCj4gPiBlYXNpZXIKPiA+IERvd25s b2FkIElCTSBXZWJTcGhlcmUgQXBwbGljYXRpb24gU2VydmVyIHYuMS4wLjEgYmFzZWQgb24gQXBh Y2hlCj4gR2Vyb25pbW8KPiA+IGh0dHA6Ly9zZWwuYXMtdXMuZmFsa2FnLm5ldC9zZWw/Y21kPWxu ayZraWQ9MTIwNzA5JmJpZD0yNjMwNTcmZGF0PTEyMTY0Mgo+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+IEllbGVhay1kZXZlbCBtYWlsaW5nIGxp c3QKPiA+IEllbGVhay1kZXZlbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKPiA+IGh0dHBzOi8vbGlz dHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2llbGVhay1kZXZlbAo+ID4KPgo+Cj4K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Cj4gVXNpbmcgVG9tY2F0IGJ1dCBuZWVkIHRvIGRvIG1vcmU/IE5lZWQgdG8gc3VwcG9ydCB3ZWIg c2VydmljZXMsIHNlY3VyaXR5Pwo+IEdldCBzdHVmZiBkb25lIHF1aWNrbHkgd2l0aCBwcmUtaW50 ZWdyYXRlZCB0ZWNobm9sb2d5IHRvIG1ha2UgeW91ciBqb2IKPiBlYXNpZXIKPiBEb3dubG9hZCBJ Qk0gV2ViU3BoZXJlIEFwcGxpY2F0aW9uIFNlcnZlciB2LjEuMC4xIGJhc2VkIG9uIEFwYWNoZSBH ZXJvbmltbwo+IGh0dHA6Ly9zZWwuYXMtdXMuZmFsa2FnLm5ldC9zZWw/Y21kPWxuayZraWQ9MTIw NzA5JmJpZD0yNjMwNTcmZGF0PTEyMTY0Mgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCj4gSWVsZWFrLWRldmVsIG1haWxpbmcgbGlzdAo+IEllbGVhay1k ZXZlbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5l dC9saXN0cy9saXN0aW5mby9pZWxlYWstZGV2ZWwKPgoKCgotLSAKSHJpc3RvIERlc2hldgpodHRw Oi8vYmxvZ3MudGVsZXJpay5jb20vQmxvZ3MvdHdpc3RlZF9hc3BfbmV0Cg== |
From: Johan R. <jsr...@wa...> - 2006-05-23 08:38:48
|
Hi Matthias, Please see my comments inline: Regards, Johan ----- Original Message ----- From: "Matthias Miller" <Blog@OutOfHanwell.com> To: <iel...@li...> Sent: Monday, May 22, 2006 6:03 PM Subject: Re: [Ieleak-devel] real-time usage reporting > jsrosman wrote: >> The button 'Check Leaks' could be replaced in 3 single buttons: A) >> About:blank B) Show in Use C) Clear in Use. pressing the buttons A) >> followed by B) will have the same effect as pressing the 'Check Leaks' >> .... > I think this would be useful. Can we simplify the user interface somewhat? > I would like to make it easy for web developers who are less familiar with > the inner workings of Drip. What if we would have two buttons on the main > dialog: "View DOM Usage" and "View DOM Leaks"? > One question about the "Clear in Use" button. If you click that button, > will those elements still show up in the list of memory leaks? Also, what > happens references are added to or removed from that element? Does it > reappear in the list? Yes if refcount increases then the hidden element will reappear in the list. When the refcount decreases you can keep them hidden IMO. However with a 'show all' toggle you can make all (hidden) elements visible again. > I wonder whether this button could be moved to the "View DOM Usage" > dialog, perhaps called "Clear List". When you click this button, you would > still see them when you check for memory leaks. Thus, I assume that this > button does not literally clear the list, per se, but simply tracks the > number of references and suppresses them in the "View DOM Usage" dialog if > number of references hasn't increased. Given this design, the list of > items would still be cleared when you click the View DOM Leaks button > (just as it does now.) > > As an alternative to the Clear in Use or Clear List button, the Vew DOM > Usage dialog could have a toggle button to switch between all elements and > only those elements that have changed since the dialog was last opened. > This could be useful in both dialogs, I guess. You'r right you have the same solution in mind :-), I used colors too to indicate new elements in use and a different color for elements with increased refcount and a simple toggle 'show all'. And also the mainbrowser dialog and the (modeless) View DOM dialog also has the same 2 buttons 'Show in Use' and 'Clear in Use'. This are all fair simple changes in the UI. Just only 2 additional buttons on both dialogs. > > My goal is to provide a simple interface for finding memory leaks, while > still catering to more advanced users. IMO, this tool wil only be used by advanced users (web front-end developers) who have the knowledge to repair the javascript and workaround the IE leaks. > > -Matthias > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Ieleak-devel mailing list > Iel...@li... > https://lists.sourceforge.net/lists/listinfo/ieleak-devel > |
From: Matthias M. <Blog@OutOfHanwell.com> - 2006-05-22 16:03:22
|
jsrosman wrote: > The button 'Check Leaks' could be replaced in 3 single buttons: A) > About:blank B) Show in Use C) Clear in Use. pressing the buttons A) > followed by B) will have the same effect as pressing the 'Check Leaks' > button in the current 'Drip'. However as long as a web page is loaded > you can press the buttons 'Show in Use' and 'Clear in Use'. The 'Show > in Use' reports all elements currently in use (with refcount as > well). After pressing the 'Clear in Use' button the list will be > cleared. Then after doing some small action in your webpage you can > see the newly created elements from the moment you pressed the 'clear > in use' button. Using the buttons at the right moments you can > monitor which elements are newly created and not garbage collected. I > got this idea from the Rational Purify software. <snip> I think this would be useful. Can we simplify the user interface somewhat? I would like to make it easy for web developers who are less familiar with the inner workings of Drip. What if we would have two buttons on the main dialog: "View DOM Usage" and "View DOM Leaks"? One question about the "Clear in Use" button. If you click that button, will those elements still show up in the list of memory leaks? Also, what happens references are added to or removed from that element? Does it reappear in the list? I wonder whether this button could be moved to the "View DOM Usage" dialog, perhaps called "Clear List". When you click this button, you would still see them when you check for memory leaks. Thus, I assume that this button does not literally clear the list, per se, but simply tracks the number of references and suppresses them in the "View DOM Usage" dialog if number of references hasn't increased. Given this design, the list of items would still be cleared when you click the View DOM Leaks button (just as it does now.) As an alternative to the Clear in Use or Clear List button, the Vew DOM Usage dialog could have a toggle button to switch between all elements and only those elements that have changed since the dialog was last opened. This could be useful in both dialogs, I guess. My goal is to provide a simple interface for finding memory leaks, while still catering to more advanced users. > > Another very usefull addition for 'Drip' could be: Cross > Reference: When you have the list of leaked elements you see a > 'refcount' showing the number of references to a leaked element. It > will be definately very helpfull to detect the reason of a memory leak > if you are able to see which elements (or script) are still holding a > reference to the leaked element. As soon you know who are pointing to > a leaked element it is very easy to solve and avoid the leak. I am > thinking for some time how to implement such a feature but until now > the only thing i can imagine is to iterate over all properties of all > 'elements in use' and see if there are some expando properties > pointing to another HTML element. You can show this in the UI in a > tree-control for example. But the biggest pain are the closures. > (references to HTML elements enclosed in function instances e.g. > eventhandlers). Any ideas how to implement such a cross reference > feature? > An excellent idea, IMO. My first idea was to iterate through the properties and temporarily break references, checking whether doing so would allow the element to be garbage collected. But in order to do that, you'd have to completely discard the property, so that doesn't work! Hmm... -Matthias |
From: jsrosman <jsr...@wa...> - 2006-05-22 08:53:27
|
<html> <head> <script> var count=3D0; function addContent() { container.appendChild(document.createElement("DIV")); container.lastChild.innerText =3D "Item " + count++; } function removeContent() { if (container.lastChild && container.lastChild.tagName =3D=3D "DIV" ) { container.removeChild(container.lastChild); } } </script> </head> <body> <button onclick=3D"addContent()">Add Content</button> <button onclick=3D"removeContent()">Remove Content and create PseudoLeak</b= utton> <hr /> <div id=3D"container"> <strong>Contents of the container: </strong> </div> <hr /> </body> </html> |
From: Matthias M. <Blog@OutOfHanwell.com> - 2006-05-19 23:02:46
|
Hristo Deshev wrote: > That sounds good, but I don't have any idea how "leaked" elements can > be monitored and detected before the page unloads. Maybe we don't > need to display all elements references real time. They can get > logged and a report can be shown at the end of the session. I am > thinking of the same thing that memory profilers do -- which elements > were most frequently created, which ones occupied the most memory (can > we do that at all?), etc. There's really no way of knowing whether an element is leaked until the page is unloaded, but you can monitor how many references exist to different elements. There should be nothing keeping us from showing the same information as the "Check Leaks" dialog at runtime, except obviously it won't be leaked objects. It'll simply show object references. Rather than making such an extensive change to the UI, we might be able to gain just as much by making fairly simple improvements to the leak reporting. --I'm guessing there'd be a way of monitoring the size of an element, but I'm not sure where to start--maybe with a memory allocation hooks? Certainly that could be very helpful in knowing which elements to go after. This would be an excellent feature. > As far as real time display is concerned, we can provide some really > valuable information without much effort by displaying a runinng total > of all elements created, and the top 3 (2, 5, more?) element types, so > that people can go "Hmm, the element count goes up and I am creating > mostly div's and tables" and optimize that. --By "total number of objects created", I assume you mean only the number of objects that are currently allocated, not the total number of elements ever created. This seems like another very useful feature. It complements the "total allocated memory" nicely. --I'm not sure what summary people want to see on the main dialog. Grouping by tag name seems reasonable--do you show the groups with the most references or (if we can find this) the most memory allocated? > What other real time stats do we need to display? --Another option might be to display a real-time listing of elements as they're created or attached to the DOM. (Basically, as soon as the JSHook discovers them.) This may help you establish a trend in the memory leaks. -Matthias |
From: Hristo D. <hri...@gm...> - 2006-05-19 22:15:09
|
SGkgTWF0dGhpYXMsCgpUaGF0IHNvdW5kcyBnb29kLCBidXQgSSBkb24ndCBoYXZlIGFueSBpZGVh IGhvdyAibGVha2VkIiBlbGVtZW50cyBjYW4gYmUKbW9uaXRvcmVkIGFuZCBkZXRlY3RlZCBiZWZv cmUgdGhlIHBhZ2UgdW5sb2Fkcy4gIE1heWJlIHdlIGRvbid0IG5lZWQgdG8KZGlzcGxheSBhbGwg ZWxlbWVudHMgcmVmZXJlbmNlcyByZWFsIHRpbWUuICBUaGV5IGNhbiBnZXQgbG9nZ2VkIGFuZCBh IHJlcG9ydApjYW4gYmUgc2hvd24gYXQgdGhlIGVuZCBvZiB0aGUgc2Vzc2lvbi4gIEkgYW0gdGhp bmtpbmcgb2YgdGhlIHNhbWUgdGhpbmcKdGhhdCBtZW1vcnkgcHJvZmlsZXJzIGRvIC0tIHdoaWNo IGVsZW1lbnRzIHdlcmUgbW9zdCBmcmVxdWVudGx5IGNyZWF0ZWQsCndoaWNoIG9uZXMgb2NjdXBp ZWQgdGhlIG1vc3QgbWVtb3J5IChjYW4gd2UgZG8gdGhhdCBhdCBhbGw/KSwgZXRjLgoKQXMgZmFy IGFzIHJlYWwgdGltZSBkaXNwbGF5IGlzIGNvbmNlcm5lZCwgd2UgY2FuIHByb3ZpZGUgc29tZSBy ZWFsbHkKdmFsdWFibGUgaW5mb3JtYXRpb24gd2l0aG91dCBtdWNoIGVmZm9ydCBieSBkaXNwbGF5 aW5nIGEgcnVuaW5uZyB0b3RhbCBvZgphbGwgZWxlbWVudHMgY3JlYXRlZCwgYW5kIHRoZSB0b3Ag MyAoMiwgNSwgbW9yZT8pIGVsZW1lbnQgdHlwZXMsIHNvIHRoYXQKcGVvcGxlIGNhbiBnbyAiSG1t LCB0aGUgZWxlbWVudCBjb3VudCBnb2VzIHVwIGFuZCBJIGFtIGNyZWF0aW5nIG1vc3RseSBkaXYn cwphbmQgdGFibGVzIiBhbmQgb3B0aW1pemUgdGhhdC4KCldoYXQgb3RoZXIgcmVhbCB0aW1lIHN0 YXRzIGRvIHdlIG5lZWQgdG8gZGlzcGxheT8KCkhyaXN0bwoKCk9uIDUvMTkvMDYsIE1hdHRoaWFz IE1pbGxlciA8QmxvZ0BvdXRvZmhhbndlbGwuY29tPiB3cm90ZToKPgo+IEhlcmUncyB0aGUgcHJv YmxlbToKPgo+IERyaXAgY3VycmVudGx5IG9ubHkgY2hlY2tzIGZvciBsZWFrZWQgZWxlbWVudHMg d2hlbiB0aGUgcGFnZSBpcwo+IHVubG9hZGVkLiBGb3IgQWpheCBhcHBsaWNhdGlvbnMsIHRoYXQn cyBub3QgZW5vdWdoLiBBcyBwYXJ0cyBvZiB0aGUgcGFnZQo+IGFyZSBsb2FkZWQgYW5kIHJlZnJl c2hlZCwgdGhlIG1lbW9yeSBmb3IgdGhvc2UgZWxlbWVudHMgbWF5IG5vdCBiZQo+IGltbWVkaWF0 ZWx5IGZyZWVkLiBEcmlwIGN1cnJlbnRseSBoYXMgbm8gd2F5IG9mIHJlcG9ydGluZyB0aGVzZQo+ ICJwc2V1ZG8tbGVha3MiLgo+Cj4gSSB3b25kZXIgaWYgRHJpcCBzaG91bGQgYmUgY2hhbmdlZCB0 byBtb25pdG9yIGVsZW1lbnQgcmVmZXJlbmNlcwo+IHJlYWwtdGltZS4gKFRoaXMgbWF5IG1lYW4g YSBzaWduaWZpY2FudCByZWRlc2lnbiBvZiB0aGUgVUkuKSBUaGlzIHdvdWxkCj4gYWxsb3cgeW91 IHRvIHdhdGNoIGVsZW1lbnQgcmVmZXJlbmNlcyBlYmIgYW5kIGZsb3cgYXMgeW91IHVzZSB0aGUg cGFnZSwKPiBwcm92aWRpbmcgbXVjaCBiZXR0ZXIgZmVlZGJhY2sgZm9yIHRyYWNraW5nIGxlYWtz Lgo+Cj4gSWYgdGhpcyBzb3VuZHMgcmVhc29uYWJsZSBlbm91Z2gsIHdlIHNob3VsZCB0YWNrbGUg c29tZSBvZiB0aGUgdG91Z2gKPiBxdWVzdGlvbnMgb2YgaG93IHRoaXMgbWlnaHQgYmUgaW50ZXJm YWNlZC4KPgo+IC1NYXR0aGlhcwo+Cj4KPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBVc2luZyBUb21jYXQgYnV0IG5lZWQgdG8gZG8g bW9yZT8gTmVlZCB0byBzdXBwb3J0IHdlYiBzZXJ2aWNlcywgc2VjdXJpdHk/Cj4gR2V0IHN0dWZm IGRvbmUgcXVpY2tseSB3aXRoIHByZS1pbnRlZ3JhdGVkIHRlY2hub2xvZ3kgdG8gbWFrZSB5b3Vy IGpvYgo+IGVhc2llcgo+IERvd25sb2FkIElCTSBXZWJTcGhlcmUgQXBwbGljYXRpb24gU2VydmVy IHYuMS4wLjEgYmFzZWQgb24gQXBhY2hlIEdlcm9uaW1vCj4gaHR0cDovL3NlbC5hcy11cy5mYWxr YWcubmV0L3NlbD9jbWQ9bG5rJmtpZD0xMjA3MDkmYmlkPTI2MzA1NyZkYXQ9MTIxNjQyCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBJZWxlYWstZGV2 ZWwgbWFpbGluZyBsaXN0Cj4gSWVsZWFrLWRldmVsQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAo+IGh0 dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2llbGVhay1kZXZlbAo+ CgoKCi0tIApIcmlzdG8gRGVzaGV2Cmh0dHA6Ly9ibG9ncy50ZWxlcmlrLmNvbS9CbG9ncy90d2lz dGVkX2FzcF9uZXQK |
From: Matthias M. <Blog@OutOfHanwell.com> - 2006-05-19 15:11:42
|
Here's the problem: Drip currently only checks for leaked elements when the page is unloaded. For Ajax applications, that's not enough. As parts of the page are loaded and refreshed, the memory for those elements may not be immediately freed. Drip currently has no way of reporting these "pseudo-leaks". I wonder if Drip should be changed to monitor element references real-time. (This may mean a significant redesign of the UI.) This would allow you to watch element references ebb and flow as you use the page, providing much better feedback for tracking leaks. If this sounds reasonable enough, we should tackle some of the tough questions of how this might be interfaced. -Matthias |
From: Matthias M. <Blog@OutOfHanwell.com> - 2006-04-27 14:10:59
|
Although I haven't closely examined all the available options, it looks like you've made a good choice. It's comprehensible, and I like that. I've also added your changes to the VS 2003 project and confirmed that it compiles and the tests pass. -Matthias Hristo Deshev (SF) wrote: > Hi Matthias, > > I've added the smallest C++ unit testing framework that I could find. > It's called NanoCppUnit and has been developed by Phlip. The homepage > is at http://www.xpsd.org/cgi-bin/wiki?NanoCppUnit . > > I have surrounded all the code that uses it in #ifdef TEST ... #endif > blocks, so that we can build the release version without the tests. > The tests are being executed in the application's InitInstance > method. All failures will be logged to the debug output window of the > IDE and a failed assertion will additionally trigger a breakpoint that > takes you to the exact location of the failure. That's my favorite > feature of the framework. > > Writing tests is easy, far easier than it is for cppunit. You just > add a class that inherits from TestCase and define several test > methods using the TEST_ macro. The class can override the setup() and > teardown() methods to provide for test fixture initialization and > cleanup. > > My plan is to cover with tests code that I change, so that we keep > regression problems to a minimum. > > Of course I don't have a specific preference for a unit testing > framework and I have no problems with switching to another one if it > would be more convenient to you. > > -- > Hristo Deshev > http://blogs.telerik.com/Blogs/twisted_asp_net |
From: Hristo D. (SF) <hri...@gm...> - 2006-04-27 05:48:17
|
SGkgTWF0dGhpYXMsCgpJJ3ZlIGFkZGVkIHRoZSBzbWFsbGVzdCBDKysgdW5pdCB0ZXN0aW5nIGZy YW1ld29yayB0aGF0IEkgY291bGQgZmluZC4gIEl0J3MKY2FsbGVkIE5hbm9DcHBVbml0IGFuZCBo YXMgYmVlbiBkZXZlbG9wZWQgYnkgUGhsaXAuICBUaGUgaG9tZXBhZ2UgaXMgYXQKaHR0cDovL3d3 dy54cHNkLm9yZy9jZ2ktYmluL3dpa2k/TmFub0NwcFVuaXQgLgoKSSBoYXZlIHN1cnJvdW5kZWQg YWxsIHRoZSBjb2RlIHRoYXQgdXNlcyBpdCBpbiAjaWZkZWYgVEVTVCAuLi4gI2VuZGlmCmJsb2Nr cywgc28gdGhhdCB3ZSBjYW4gYnVpbGQgdGhlIHJlbGVhc2UgdmVyc2lvbiB3aXRob3V0IHRoZSB0 ZXN0cy4gIFRoZQp0ZXN0cyBhcmUgYmVpbmcgZXhlY3V0ZWQgaW4gdGhlIGFwcGxpY2F0aW9uJ3Mg SW5pdEluc3RhbmNlIG1ldGhvZC4gIEFsbApmYWlsdXJlcyB3aWxsIGJlIGxvZ2dlZCB0byB0aGUg ZGVidWcgb3V0cHV0IHdpbmRvdyBvZiB0aGUgSURFIGFuZCBhIGZhaWxlZAphc3NlcnRpb24gd2ls bCBhZGRpdGlvbmFsbHkgdHJpZ2dlciBhIGJyZWFrcG9pbnQgdGhhdCB0YWtlcyB5b3UgdG8gdGhl IGV4YWN0CmxvY2F0aW9uIG9mIHRoZSBmYWlsdXJlLiAgVGhhdCdzIG15IGZhdm9yaXRlIGZlYXR1 cmUgb2YgdGhlIGZyYW1ld29yay4KCldyaXRpbmcgdGVzdHMgaXMgZWFzeSwgZmFyIGVhc2llciB0 aGFuIGl0IGlzIGZvciBjcHB1bml0LiAgWW91IGp1c3QgYWRkIGEKY2xhc3MgdGhhdCBpbmhlcml0 cyBmcm9tIFRlc3RDYXNlIGFuZCBkZWZpbmUgc2V2ZXJhbCB0ZXN0IG1ldGhvZHMgdXNpbmcgdGhl ClRFU1RfIG1hY3JvLiAgVGhlIGNsYXNzIGNhbiBvdmVycmlkZSB0aGUgc2V0dXAoKSBhbmQgdGVh cmRvd24oKSBtZXRob2RzIHRvCnByb3ZpZGUgZm9yIHRlc3QgZml4dHVyZSBpbml0aWFsaXphdGlv biBhbmQgY2xlYW51cC4KCk15IHBsYW4gaXMgdG8gY292ZXIgd2l0aCB0ZXN0cyBjb2RlIHRoYXQg SSBjaGFuZ2UsIHNvIHRoYXQgd2Uga2VlcApyZWdyZXNzaW9uIHByb2JsZW1zIHRvIGEgbWluaW11 bS4KCk9mIGNvdXJzZSBJIGRvbid0IGhhdmUgYSBzcGVjaWZpYyBwcmVmZXJlbmNlIGZvciBhIHVu aXQgdGVzdGluZyBmcmFtZXdvcmsKYW5kIEkgaGF2ZSBubyBwcm9ibGVtcyB3aXRoIHN3aXRjaGlu ZyB0byBhbm90aGVyIG9uZSBpZiBpdCB3b3VsZCBiZSBtb3JlCmNvbnZlbmllbnQgdG8geW91LgoK LS0KSHJpc3RvIERlc2hldgpodHRwOi8vYmxvZ3MudGVsZXJpay5jb20vQmxvZ3MvdHdpc3RlZF9h c3BfbmV0Cg== |
From: Hristo D. <hri...@gm...> - 2006-04-25 05:11:42
|
SnVzdCBmaXhlZCBpdC4gIFZTMjAwNSBhdXRvbWF0aWNhbGx5IGdlbmVyYXRlcyBhIG1hbmlmZXN0 IGZvciB5b3UgYW5kIHdhcwpjb21wbGFpbmluZyBhYm91dCB0aGUgb25lIGluIHRoZSByYyBmaWxl LiAgSSB0dXJuZWQgdGhlIGF1dG9tYXRpYyBtYW5pZmVzdAplbWJlZGRpbmcgb2ZmIGFuZCBpdCdz IGFsbCBnb29kIG5vdy4KCkhyaXN0bwoKT24gNC8yNS8wNiwgTWF0dGhpYXMgTWlsbGVyIDxCbG9n QG91dG9maGFud2VsbC5jb20+IHdyb3RlOgo+Cj4gQXQgbGVhc3QgaW4gVlMgMjAwMywgdGhpcyBm aWxlIGlzIG5lY2Vzc2FyeSBmb3IgV2luZG93cyBYUCB0aGVtZSBzdXBwb3J0IC4KCi0tLS0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0KPiBTdWJqZWN0OiAgICAgICAgW0llbGVhay1jb21t aXRdIFNGLm5ldCBTVk46IGllbGVhazogWzE4XSB0cnVuay9zcmMvZHJpcC5yYwo+IERhdGU6ICAg TW9uLCAyNCBBcHIgMjAwNiAxMDoxNToyNyAtMDcwMAo+IEZyb206ICAgaHJpc3RvX2Rlc2hldkB1 c2Vycy5zb3VyY2Vmb3JnZS5uZXQKPiBUbzogICAgIGllbGVhay1jb21taXRAbGlzdHMuc291cmNl Zm9yZ2UubmV0Cj4KPgo+Cj4gUmV2aXNpb246IDE4Cj4gQXV0aG9yOiAgIGhyaXN0b19kZXNoZXYK PiBEYXRlOiAgICAgMjAwNi0wNC0yNCAxMDoxNToyMSAtMDcwMCAoTW9uLCAyNCBBcHIgMjAwNikK PiBWaWV3Q1ZTOiAgaHR0cDovL3N2bi5zb3VyY2Vmb3JnZS5uZXQvaWVsZWFrLz9yZXY9MTgmdmll dz1yZXYKPgo+IExvZyBNZXNzYWdlOgo+IC0tLS0tLS0tLS0tCj4gcmVtb3ZlZCB0aGUgbWFuaWZl c3QgcmVmZXJlbmNlLiAgdnMyMDA1IGRvZXMgbm90IGxpa2UgaXQsIGFuZCBJIGFzc3VtZSB3ZQo+ IGRvbid0IG5lZWQgaXQgYXQgYWxsCj4KPiBNb2RpZmllZCBQYXRoczoKPiAtLS0tLS0tLS0tLS0t LQo+ICAgICB0cnVuay9zcmMvZHJpcC5yYwo+IE1vZGlmaWVkOiB0cnVuay9zcmMvZHJpcC5yYwo+ ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KPiAtLS0gdHJ1bmsvc3JjL2RyaXAucmMgICAyMDA2LTA0LTI0IDE3OjEyOjM5 IFVUQyAocmV2IDE3KQo+ICsrKyB0cnVuay9zcmMvZHJpcC5yYyAgIDIwMDYtMDQtMjQgMTc6MTU6 MjEgVVRDIChyZXYgMTgpCj4gQEAgLTI1NSw3ICsyNTUsNyBAQAo+IC8vIFJUX01BTklGRVNUCj4g Ly8KPgo+IC0xICAgICAgICAgICAgICAgICAgICAgICBSVF9NQU5JRkVTVCAgICAgICAgICAgICAi cmVzXFxydF9tYW5pZi5iaW4iCj4gKy8vMSAgICAgICAgICAgICAgICAgICAgICAgUlRfTUFOSUZF U1QgICAgICAgICAgICAgInJlc1xccnRfbWFuaWYuYmluIgo+ICNlbmRpZiAgICAvLyBFbmdsaXNo IChVLlMuKSByZXNvdXJjZXMKPgo+IC8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vCj4KPgo+Cj4K |
From: Hristo D. <hri...@gm...> - 2006-04-25 05:03:54
|
T24gNC8yNS8wNiwgTWF0dGhpYXMgTWlsbGVyIDxCbG9nQG91dG9maGFud2VsbC5jb20+IHdyb3Rl Ogo+Cj4gSXQgdHVybnMgb3V0IHRoYXQgdGhhdCBMUkVTVUxUICppcyogd2hhdCB3ZSBuZWVkIGZv ciB0aGUgMjAwMy0tc2VlCj4gaHR0cDovL2ZvcnVtcy5taWNyb3NvZnQuY29tL21zZG4vc2hvd3Bv c3QuYXNweD9wb3N0aWQ9ODY2MyZzaXRlaWQ9MSBhbmQKPiBodHRwOi8vZm9ydW1zLm1pY3Jvc29m dC5jb20vbXNkbi9zaG93cG9zdC5hc3B4P3Bvc3RpZD04NjYzJnNpdGVpZD0xLiBTZWUKPiByZXZp c2lvbiAyMCBmb3IgdGhlIGZpeC4KPgo+IENTdHJpbmdXIGhhcyBhICJjb25zdCB3Y2hhcl90KiIg b3BlcmF0b3IuIEluIENMZWFrRGxnOjpwb3B1bGF0ZUxlYWtzLAo+IHlvdSBjYW4gY3JlYXRlIGEg Q1N0cmluZ1cgYW5kIHBhc3MgaXQgaW50byBTZXRJdGVtVGV4dC4gR2V0TWVtb3J5VXNhZ2UKPiBj YW4gYmUgY2hhbmdlZCB0byByZXR1cm4gYSBDU3RyaW5nVy4gRm9yIG5vdywgeW91IGNob3VsZCBk byBhIGRvdWJsZQo+IHR5cGVjYXN0OiAoTFBBUkFNKShjb25zdCB3Y2hhcl90KilzdHIuIEEgYmV0 dGVyIHNvbHV0aW9uLCBpZiB5b3Ugd291bGQKPiBsaWtlIHRvIHRha2UgdGhlIHRpbWUsIHdvdWxk IGJlIHRvIHN1YmNsYXNzIHRoZSBjb250cm9scyBhbmQgdXNlCj4gQ0VkaXQ6OlNldFdpbmRvd1Rl eHQgYW5kIENMaXN0Qm94OjpJbnNlcnRJdGVtIGluc3RlYWQuCgoKCkknbGwgdHJ5IHRvIGRvIHRo ZSBsYXR0ZXIuICBJJ2xsIGJlIHJlYWxseSBoYXBweSBpZiBJIGNhbiBtYWtlIHRoZSBjb2RlIHVz ZQp0aGUgTUZDIGNvbnRyb2wgY2xhc3NlcyBhbmQgZ2V0IHJpZCBvZiBhbGwgdGhvc2UgU2VuZE1l c3NhZ2UgY2FsbHMuCgpIcmlzdG8K |
From: Matthias M. <Blog@OutOfHanwell.com> - 2006-04-24 21:25:43
|
At least in VS 2003, this file is necessary for Windows XP theme support . -------- Original Message -------- Subject: [Ieleak-commit] SF.net SVN: ieleak: [18] trunk/src/drip.rc Date: Mon, 24 Apr 2006 10:15:27 -0700 From: hri...@us... To: iel...@li... Revision: 18 Author: hristo_deshev Date: 2006-04-24 10:15:21 -0700 (Mon, 24 Apr 2006) ViewCVS: http://svn.sourceforge.net/ieleak/?rev=18&view=rev Log Message: ----------- removed the manifest reference. vs2005 does not like it, and I assume we don't need it at all Modified Paths: -------------- trunk/src/drip.rc Modified: trunk/src/drip.rc =================================================================== --- trunk/src/drip.rc 2006-04-24 17:12:39 UTC (rev 17) +++ trunk/src/drip.rc 2006-04-24 17:15:21 UTC (rev 18) @@ -255,7 +255,7 @@ // RT_MANIFEST // -1 RT_MANIFEST "res\\rt_manif.bin" +//1 RT_MANIFEST "res\\rt_manif.bin" #endif // English (U.S.) resources ///////////////////////////////////////////////////////////////////////////// This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Ieleak-commit mailing list Iel...@li... https://lists.sourceforge.net/lists/listinfo/ieleak-commit |
From: Matthias M. <Blog@OutOfHanwell.com> - 2006-04-24 21:22:49
|
It turns out that that LRESULT *is* what we need for the 2003--see http://forums.microsoft.com/msdn/showpost.aspx?postid=8663&siteid=1 and http://forums.microsoft.com/msdn/showpost.aspx?postid=8663&siteid=1. See revision 20 for the fix. CStringW has a "const wchar_t*" operator. In CLeakDlg::populateLeaks, you can create a CStringW and pass it into SetItemText. GetMemoryUsage can be changed to return a CStringW. For now, you chould do a double typecast: (LPARAM)(const wchar_t*)str. A better solution, if you would like to take the time, would be to subclass the controls and use CEdit::SetWindowText and CListBox::InsertItem instead. I think it would be nicer to use CStringW so that we don't worry about buffer overflows. Matthias Miller wrote: > Forwarding this to the new mailing list. > > -------- Original Message -------- > Subject: Re: [Ieleak-forum] Re: building the code under VS2003 and > VS2005 > Date: Mon, 24 Apr 2006 20:22:17 +0300 > From: Hristo Deshev <hri...@gm...> > To: Matthias Miller <Bl...@ou...> > References: > <7f3...@ma...> > <444CD246.7010807@OutOfHanwell.com> > > > > > > On 4/24/06, *Matthias Miller* <Bl...@ou... > <mailto:Bl...@ou...>> wrote: > > [snip] > It's a bit suboptimal to need to maintain two projects, but it's > probably ok. > > > > Yes, I don't like it too, but we actually won't be maintainting two > projects. The vs2003 project will be the "official" one and I will do > my best to keep the vs2005 version up to date, so that I can do some > work :). When I break the vs2003 build you can just slap my hand and > I will do my best to fix it. > > >> The VS2005 CRT libraries have some changes and I got warnings and >> errors. >> >> The warnings were all about the _itow function -- I think VS2005 >> introduced a secure version of the CRT and issued a warning that >> one was supposed to use the _itow_s function (a safe variant that >> required that the wchar_t* buffer length being passed in order to >> avoid buffer overflows). I "fixed" that by defining a >> preprocessor constant (_CRT_SECURE_NO_DEPRECATE) that stopped the >> warnings from appearing. I first changed the two calls of _itow >> to _itow_s, but I wasn't sure if those functions were available >> in VS2003's version of the CRT. > Could we solve this by using CStringW::Format instead? I know the > format specifiers have their own share of security problems, but > at least it would provide a variable-length buffer. > > > > The two occurrences required copying to an externally allocated > wchar_t* buffer, so I just used wsprintf instead. I am sure this will > compile in vs2003 -- hey, it was available in vc++ 6.0 :). Another > thing -- I was not sure how I can copy a CStringW's data to a wchar_t* > buffer and that's why I left the wsprintf solution. > > > I've committed my changes, and I think everything should be OK now. > > -- > Hristo Deshev > http://blogs.telerik.com/Blogs/twisted_asp_net |
From: Matthias M. <Blog@OutOfHanwell.com> - 2006-04-24 20:11:13
|
Forwarding this to the new mailing list. -------- Original Message -------- Subject: Re: [Ieleak-forum] Re: building the code under VS2003 and VS2005 Date: Mon, 24 Apr 2006 20:22:17 +0300 From: Hristo Deshev <hri...@gm...> To: Matthias Miller <Bl...@ou...> References: <7f3...@ma...> <444CD246.7010807@OutOfHanwell.com> On 4/24/06, *Matthias Miller* <Bl...@ou... <mailto:Bl...@ou...>> wrote: [snip] It's a bit suboptimal to need to maintain two projects, but it's probably ok. Yes, I don't like it too, but we actually won't be maintainting two projects. The vs2003 project will be the "official" one and I will do my best to keep the vs2005 version up to date, so that I can do some work :). When I break the vs2003 build you can just slap my hand and I will do my best to fix it. > The VS2005 CRT libraries have some changes and I got warnings and > errors. > > The warnings were all about the _itow function -- I think VS2005 > introduced a secure version of the CRT and issued a warning that > one was supposed to use the _itow_s function (a safe variant that > required that the wchar_t* buffer length being passed in order to > avoid buffer overflows). I "fixed" that by defining a > preprocessor constant (_CRT_SECURE_NO_DEPRECATE) that stopped the > warnings from appearing. I first changed the two calls of _itow > to _itow_s, but I wasn't sure if those functions were available in > VS2003's version of the CRT. Could we solve this by using CStringW::Format instead? I know the format specifiers have their own share of security problems, but at least it would provide a variable-length buffer. The two occurrences required copying to an externally allocated wchar_t* buffer, so I just used wsprintf instead. I am sure this will compile in vs2003 -- hey, it was available in vc++ 6.0 :). Another thing -- I was not sure how I can copy a CStringW's data to a wchar_t* buffer and that's why I left the wsprintf solution. I've committed my changes, and I think everything should be OK now. -- Hristo Deshev http://blogs.telerik.com/Blogs/twisted_asp_net |
From: Matthias M. <Blog@OutOfHanwell.com> - 2006-04-24 20:10:24
|
Forwarding this to the new mailing list. -------- Original Message -------- Subject: Re: building the code under VS2003 and VS2005 Date: Mon, 24 Apr 2006 08:27:34 -0500 From: Matthias Miller <Blog@OutOfHanwell.com> To: iel...@li... References: <7f3...@ma...> > I noticed that the project and solution file are in VS2003 format and > I have VS2005 on this machine. > > First I thought "no problem, I'll just convert the solution, slap a > "_vs2005" suffix to the vcproj and sln file names and that will be > it." Not so fast! It's a bit suboptimal to need to maintain two projects, but it's probably ok. > The VS2005 CRT libraries have some changes and I got warnings and > errors. > > The warnings were all about the _itow function -- I think VS2005 > introduced a secure version of the CRT and issued a warning that one > was supposed to use the _itow_s function (a safe variant that required > that the wchar_t* buffer length being passed in order to avoid buffer > overflows). I "fixed" that by defining a preprocessor constant > (_CRT_SECURE_NO_DEPRECATE) that stopped the warnings from appearing. > I first changed the two calls of _itow to _itow_s, but I wasn't sure > if those functions were available in VS2003's version of the CRT. Could we solve this by using CStringW::Format instead? I know the format specifiers have their own share of security problems, but at least it would provide a variable-length buffer. > The errors are even trickier. VS2005 is supposed to be 64-bit ready > and some of the hittest functions had their parameters declared as > UINT's with VS doing silent conversions to LRESULT's behind the scenes: > > UINT CLeakDlg::OnNcHitTest(CPoint point) > { > UINT ht = CDialog::OnNcHitTest(point); > m_resizeHelper.OnGripperNcHitTest(point, ht); > return ht; > } > > I think the error comes up because LRESULT are 32-bit wide and UINT's > can be 64-bit or vice versa -- that's my best guess after a google > search. Changing the code to: > > LRESULT CLeakDlg::OnNcHitTest(CPoint point) > { > LRESULT ht = CDialog::OnNcHitTest(point); > m_resizeHelper.OnGripperNcHitTest(point, ht); > return ht; > } This is correct, since OnNcHitTest is defined as returning an LRESULT (see http://msdn2.microsoft.com/en-US/library/923b34d9(VS.80).aspx). > Fixed the build, but again, I am not sure if this will compile on VS2003. > > All this brings me to the question of how do we make changes to Drip > using different versions of the IDE and the runtime libraries in the > SDK? The simplest thing that I can come up with is just to add the > VS2005 project and solution files to the SVN repo, and commit. I > think official releases should be made by compiling against the same > version of the runtime libraries, say the VS2003 ones. I hope > checkins done by me under VS2005 do not break the build very often. > > I have some experience with build automation using NAnt and I should > be able to script the build so that it will run entirely without > VS.NET <http://VS.NET>. Maybe it will be possible to install two > versions of the Win32 SDK on my machine, so that I can run the build > scripts against both versions before committing. That looks like too > much work without an obvious benefit at the moment though. Can we try > the commit-from-VS2005, update-inVS2003, fix-the-build and > commit-from-VS2003, update-inVS2005, fix-the-build approach for some > time and see if problems arise too often? I agree that an automated build system provides marginal benefit at this point. Your proposed solution sounds fine; I don't expect it to be much of a problem. -Matthias Miller |
From: Matthias M. <Blog@OutOfHanwell.com> - 2006-04-24 20:09:30
|
Forwarding this to the new mailing list. -------- Original Message -------- Subject: building the code under VS2003 and VS2005 Resent-Date: Mon, 24 Apr 2006 06:02:06 -0700 (PDT) Resent-From: iel...@li... Resent-To: iel...@li... Date: Sun, 23 Apr 2006 10:45:54 +0300 From: Hristo Deshev <hri...@gm...> To: iel...@li... Hi I have been playing with the Drip source for some time yesterday and I could not figure out how we can build and release the program. I noticed that the project and solution file are in VS2003 format and I have VS2005 on this machine. First I thought "no problem, I'll just convert the solution, slap a "_vs2005" suffix to the vcproj and sln file names and that will be it." Not so fast! The VS2005 CRT libraries have some changes and I got warnings and errors. The warnings were all about the _itow function -- I think VS2005 introduced a secure version of the CRT and issued a warning that one was supposed to use the _itow_s function (a safe variant that required that the wchar_t* buffer length being passed in order to avoid buffer overflows). I "fixed" that by defining a preprocessor constant (_CRT_SECURE_NO_DEPRECATE) that stopped the warnings from appearing. I first changed the two calls of _itow to _itow_s, but I wasn't sure if those functions were available in VS2003's version of the CRT. The errors are even trickier. VS2005 is supposed to be 64-bit ready and some of the hittest functions had their parameters declared as UINT's with VS doing silent conversions to LRESULT's behind the scenes: UINT CLeakDlg::OnNcHitTest(CPoint point) { UINT ht = CDialog::OnNcHitTest(point); m_resizeHelper.OnGripperNcHitTest(point, ht); return ht; } I think the error comes up because LRESULT are 32-bit wide and UINT's can be 64-bit or vice versa -- that's my best guess after a google search. Changing the code to: LRESULT CLeakDlg::OnNcHitTest(CPoint point) { LRESULT ht = CDialog::OnNcHitTest(point); m_resizeHelper.OnGripperNcHitTest(point, ht); return ht; } Fixed the build, but again, I am not sure if this will compile on VS2003. All this brings me to the question of how do we make changes to Drip using different versions of the IDE and the runtime libraries in the SDK? The simplest thing that I can come up with is just to add the VS2005 project and solution files to the SVN repo, and commit. I think official releases should be made by compiling against the same version of the runtime libraries, say the VS2003 ones. I hope checkins done by me under VS2005 do not break the build very often. I have some experience with build automation using NAnt and I should be able to script the build so that it will run entirely without VS.NET <http://VS.NET>. Maybe it will be possible to install two versions of the Win32 SDK on my machine, so that I can run the build scripts against both versions before committing. That looks like too much work without an obvious benefit at the moment though. Can we try the commit-from-VS2005, update-inVS2003, fix-the-build and commit-from-VS2003, update-inVS2005, fix-the-build approach for some time and see if problems arise too often? -- Hristo Deshev http://blogs.telerik.com/Blogs/twisted_asp_net |