Community
Participate
Working Groups
Re: Eclipse Article on SWT : http://www.eclipse.org/articles/index.html The program presented there will detect memory leaks in SWT code. I think it should be integrated into Eclipse by having Eclipse enable it when it creates its Disply object and providing a view for its output. Addendum: I would be happy to write the view but would need someone else to integrate it into Eclipse itself.
It is already easily integrated. Take a look at http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt- home/dev.html#tools for the plugin and installation instructions.
What I meant is that it should be included in the default platform, including the setting of the options.
Actually I am completely refactoring the plugin as we speak. In fact "re- engineering" would be a more appopriate term given the massive changes Im doing. So I suppose you could assign it to me. =) I will let you know when I am done.
Can you just assign this to me ? I would like to contribute it when Im done (and I am about 70% done.) =)
Plugin is almost done.
Re-added the releng mailing list to the CC.
Created attachment 14758 [details] The S-Leak Plugin and core, revamped for Eclipse 3.0 Well I rewrote S-Leak massively. =) In fact, I think it is quite spiffy as it is now. I will be attaching the plugin to this bug as of now. I would appreciate any feedback; indeed I am eagerly awaiting it. I merely need to do some user documentation and we can call the chicken cooked. I am donating the plugin back to the eclipse project. In fact there are two plugins. One is S-Leak itself and the other is a plugin I made that has some tools for manipulating and editing rgular expressions in the Eclipse IDE. To use the plugin, follow these simple steps: 1) Unzip it into your eclipse directory (the .options file should be in the eclipse main directory while the plugins are in the plugins directory) 2) Run eclipse with the command line flag -debug After you have done these you can open the view S-Leak view and you can look at the preference page for SLeak. For those of you who dont know about S-Leak, it’s a dangling resource tracker for SWT based applications. In SWT when we allocate resources such as fonts or images, we have to make sure to dispose them later. However, sometimes we miss them and this guy helps you find the ones you missed. It provides a stack trace of when the resource was created as well as a preview of the resource (if possible). It uses A LOT of Eclipse functionality to accomplish this. =) -- Robert
Addendum: You can also cause the S-Leak to run in your runtime workbench by simply adding -debug to the command line arguments. I wish there was an easier way to do the stuff in the options file though.
Comments on propsed SLeak changes 1) The current SLeak tool intentionally does not create system resources because this causes the tool to interfere with the results it is monitoring. The images in the tree and toolbar need to be removed. It would also be better if the view used a pre-allocated image in the tab and preference menu. 2) I do not understand what functionality the S-Leak preference page is providing. Perhaps it is not working correctly. I believe it has something to do with filtering the stack trace but I do not know what Dotall Mode means or what the flags "eicDmfu" mean. I have tried changing the values and have seen no effect on the stack trace. It is also unclear which pattern currently applies (or do all?). I think the flags should not be exposed to the user - they seem to be an implementation detail that makes the UI confusing. The pattern options could be presented more clearly. 3) The tree in the S-Leak Summary view allows multiple selection but I see no way in which this is used. In fact, if I select multiple items and then click "Remove selected from cache", only the last selected item is actually removed which is confusing. 4) In the current SLeak, the summary at the bottom of the view is quite useful and needs to be brought back (i.e. 59 Colors, 25 Images etc). 5) I like the use of a TabFolder versus the Checkbox to flip between StackTrace and Preview. 6) I like the use of a tree to show the results sorted by resource type - however, having entries in the tree when no resources of that type exist makes the tree quickly become too long and makes it harder to focus on the problem. 7) I prefer the snap/start/stop operation names versus the snap/diff operation names. 8) Currently, I can not think of a use case where I would want to keep old diffs or snapshots around, however, this could be useful.
Thanks for the feedback Steve, here are my replies. 1) I think the critical thing is to not LEAK resources. Allocating them is largely irrelevant so long as they are properly disposed. SLeak would be used more in Monitor/Stop monitor mode. This mode takes a snapshot and then compares that snapshot with the end mode snapshot to get the delta. This lets you start the monitor, do an action such as opening and closing a dialog and then stop the monitor to see the delta. If all goes well the delta will be nothing and the resources will all be cleaned up. If not then there will eb resources leaked and the tool will capture them. One example use case is to start the monitor, open the preference dialog and then close it and then stop the monitor. 2) The preference page provides the ability to filter the stack trace based upon regular expressions. That way if you are only interested in elements for your plugin, you can filter out all the elements of the other plugins. The preference page uses a field editior that is a general purpose field editor to edit regular expressions as described in the java.util.regex package. The field editor and associated classes are in the RegexTools plugin and could be used for any number of things. These classes coudl be absorbed into the org.eclipse.ui package or just stay where they are. Either way works. They would be available to anyone using regular expressions. As for dotall mode, that is documented in java.util.regex.Pattern. 3) Multiple select should not be enabled, that is easily fixed. 4) The summary could be added. That shouldnt be that big of a deal. Perhaps it would be best just to put the count on each category of resource. Remember you can have any number of caches saved so counting all of them that are being tracked seems a tad useless. This is a 2 minute change to the decorator. 5) =) Glad you do. Seemed more natural. What Id really like to know is why the whole background color changes when viewing some images (such as the eclipse logo) 6) The monitor is a fancy diff that creates a cache based upon the difference between two snapshots (the start one and the stop one). 7) It might be. I can think of it if you were tracking resources in large project and over a long period of time. However, you can always remove a cache or all caches if you so desire. Its a pretty cheap extra feature that took little work so why not. =) Also Steve, dont forget that the SLeak core could be used outside of Eclipse and the RCP. So it should probably be ultimately in a second jar that peopel can pilfer or maybe even make it part of SWT itself *shrug* Just throwing out ideas here. The core is completely independent of the view.
By the way, I am working on documenteation but I thougth Id get feedback before I got too far into it.
The png image tested has a 2 colours, black and transparent. When creating the image using the non-native PNG loader, the image is stored as a bitmap with a specified transparent pixel colour. When loading the image using the native code, GDI+ creates a 32 bit image and uses an alpha channel. This alpha channel is ignored when creating the disabled image, causing this bug.
sorry, wrong bug
*** Bug 168050 has been marked as a duplicate of this bug. ***
See also bug 213024.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
Done for some time already.
