Bugzilla – Full Text Bug Listing
| Summary: | LaunchConfiguration not thread-safe for #doSave from multiple working copies | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | James Blackburn <jamesblackburn+eclipse> | ||||
| Component: | Debug | Assignee: | Platform-Debug-Inbox <platform-debug-inbox> | ||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | darin.eclipse, nobody | ||||
| Version: | 3.6 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux-GTK | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 170181 [details]
back trace showing two threads in save()
Actually having this break noisily was useful to identify an issue in CDT CDI - bug 314738. Perhaps this is WONT FIX? The working copy model is intended to be linear... i.e. one config, get a working copy, make changes, save. If you get two working copies and make different changes, one will overwrite the other since they initialize from the original with just those attributes. A working copy is not intended to be modified concurrently by different threads, nor are two working copies from the same original configuration inteneded to be saved after making different edits (well, this can be done, but clients must understand the consequences). Marking WONT FIX. I am running into what seems to be a related problem. In our case, we happen to have two unrelated plugins that are modifying the same launch configuration independently and asynchronously (i.e., different working copies), without any knowledge of each other. The problem for us is that an added setting from one working copy does not end up in the resulting configuration. The theory is that it has been overwritten by the other working copy. We thought to move each of the launch configuration updates to a WorkspaceRunnable to provide some synchronization, but then I noticed the workspace synchronizing code that's already in LaunchConfigurationWorkingCopy.doSave(). Unfortunately, it turns out that the synchronization is done only selectively, and what's worse not for .launches in the workspace, which is our customer's primary use model. I did modify the code to always use WorkspaceRunnable and found that sure enough my problem went away. I went into the history of LaunchConfigurationWorkingCopy.java and found that the synchronization was turned off because of a specific deadlock. See version 1.35 and bug 46811. Perhaps a different solution for 46811 should be considered, and the WorkspaceRunnable restored? I take it back. It seems that I am again reproducing my threading problem even with the workspace synchronization. I just have one last request: add a comment to ILaunchConfiguration.getWorkingCopy() about this limitation. |
Using a CDT CDI type debug session with multiple registered targets, I can easily stimulate a SAXParseException on tear-down. Some of the CDI managers save attributes in the launch configuration, in this case they do: ILaunchConfiguration config = getDebugTarget().getLaunch().getLaunchConfiguration(); ILaunchConfigurationWorkingCopy wc = config.getWorkingCopy(); wc.setAttribute( ICDTLaunchConfigurationConstants.ATTR_DEBUGGER_MEMORY_BLOCKS, getMemento() ); wc.doSave(); && ILaunchConfiguration config = getDebugTarget().getLaunch().getLaunchConfiguration(); try { ILaunchConfigurationWorkingCopy wc = config.getWorkingCopy(); wc.setAttribute( ICDTLaunchConfigurationConstants.ATTR_DEBUGGER_FORMAT, getMemento() ); wc.doSave(); } What's interesting is that the ILaunchConfiguration in both cases is the same, however the working copies are different. I guess it's unlikely that both contributed attributes persist, however the implementation of doSave should be safe.