Community
Participate
Working Groups
Created attachment 158069 [details] DSF threads patch If I set a breakpoint before the second thread is created and then break into the second thread, it will only show one thread in the debug session unless I press the refresh button. So, it looks like Apple's GDB doesn't notify about the new thread and it shows up when refresh is pressed because -thread-list-ids is sent. The problem is that -thread-list-ids is cached so it always returns the same result unless the cache is flushed. So, the patch adds a listener for suspend events and flushes the cache.
This bug is a DSF-GDB specific instance of bug 269838
Created attachment 158253 [details] Improved fix First let me say that I'm very impressed with Marc-Andre's patch. Isolating the problem with the cache was quite an achievement as the caching stuff of DSF is not obvious at all. I've modified the patch a little with things that are important when using DSF but that are not obvious. Also, this patch will require a change in DSF, which I will open a bug for soon. The changes are about: 1- every service has a base method getServicesTracker(), but you need to have super.initialize be called to get the tracker ready. That is why it's better to use an initialize method instead of using the constructor 2- It is good to register() a new version of a service to add it's name as a way to find it using the DsfServicesTracker. This is not essential and I realize we haven't done this for the other new MacOS services. Doing so allows you to call tracker.getService(MacOSGDBProcesses.class) if you need to call a method that is only defined in that class. 3- when calling addServiceEventListener() in a service, you should also call removeServiceEventListener() when shutting down the service. You do this in an overridden shutdown() method. 4- whenever you create a new DsfServicesTracker, you must dispose() it eventually. 5- using flushCache(null) will flush the entire cache. This is more consistent with the clearing of the cache that we do in GDBProcesses.java. Also, it is probably the right thing to clear the entire cache because an ISuspendedEvent could occur for a single thread (not on Mac though), and that should clear the cache for the container not just the specific thread (they are both execution contexts) 6- eventDispatched() is marked as @nooverride which is an API tooling tag (for some reason, I didn't get a warning though...). So, after debating about it, I feel it is more future-proof to have the MacOS eventDispatched() method not override the base one (by simply changing its name) and letting the base one be called automatically by DsfSession. I believe this would allow everything to keep working even if we decided to remove eventDispatched() from the base class. Finally, you should add -ea (which I often forget) to the VM arguments when doing your Eclipse launch. This will allow for more checks to be done by DSF code. In fact, if you try it with this patch, things will break :-) That is why I need to change something in DSF. Marc-Andre, can you confirm that this patch fixes your problem? (don't use -ea) Thanks
I've opened Bug 301913 about the DSF assertion problem.
Thanks for the explanations :) I can confirm that the patch fixes the problem. I also tried the patch from Bug 301913 and used -ea and it worked too.
(In reply to comment #4) > Thanks for the explanations :) I'm trying keep you involved :-) You're doing a great job. > I can confirm that the patch fixes the problem. Committed to HEAD. Pawel can you review?
Makes sense to me.
