Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 370973

Summary: [debug view] Copying a thread in the 'Debug' view no longer copies the stack trace like 3.7.x
Product: [Eclipse Project] Platform Reporter: Remy Suen <remy.suen>
Component: DebugAssignee: Pawel Piech <pawel.1.piech>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: pawel.1.piech
Version: 3.8   
Target Milestone: 3.8 M6   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description Remy Suen CLA 2012-02-08 11:23:57 EST 
I20120125-1800 (3.8M5)

This is a regression against 3.7.1.

1. Launch a 'Debug' session.
2. Select a thread.

> Thread [main] (Suspended (breakpoint at line 14 in Test))

3. Hit Ctrl+C.
4. Try to paste this somewhere, you only get one single line.

> Thread [main] (Suspended (breakpoint at line 14 in Test))	

5. In 3.7.1, I get the whole trace.

> Thread [main] (Suspended (breakpoint at line 14 in Test))	
> 	Test.w() line: 14	
> 	Test.v() line: 9	
> 	Test.main(String[]) line: 4
Comment 1 Pawel Piech CLA 2012-02-08 14:14:59 EST 
The change in behaviour was not intentional.  The workaround would be to multi-select the thread and the frames to copy.
Comment 2 Pawel Piech CLA 2012-02-22 19:39:01 EST 
I pushed out the fix: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=34308a56094410da5a071c1736f8a0019e00c9d5

After making an initial fix I found a problem while testing: the copy operation didn't complete when copying a tree that was actively changing (e.g. TestManyThreads example).  After a few hours of debugging, I arrived at a refined implementation.  

The Copy Stack operation will copy a sub-tree of selected elements, but only if they are expanded.  It will not copy un-expanded elements.  3.7.x had the same limitation.
Comment 3 Pawel Piech CLA 2012-03-13 23:22:16 EDT 
Verified with  I20120313-0610