Changes between Version 1 and Version 2 of Ticket #9659, comment 21
- Timestamp:
- Apr 30, 2013 9:10:50 AM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #9659, comment 21
v1 v2 3 3 Yes, after a bit longer period of time, more step over the breakpoint line iterations. But it is still there in 100% cases anyway. I also can not reproduce it with a native C++ project but that's completely different platform and debugger. 4 4 5 I have also tried to insert System.Diagnostics.Debugger.Break() before the M1() method call instead of setting a breakpoint in Visual Studio and it worked fine. It seems to be as a thread synchronization (CPU cache coherence ?) issue between the debug er process (Visual Studio) and debugged one. Still, it is weird that only debugged process is affected and there are no similar issues with multithreaded code in general. Maybe there is something in VirtualBox that handles processes with 'debugger attached flag' in a different way.5 I have also tried to insert System.Diagnostics.Debugger.Break() before the M1() method call instead of setting a breakpoint in Visual Studio and it worked fine. It seems to be as a thread synchronization (CPU cache coherence ?) issue between the debugger process (Visual Studio) and debugged one. Still, it is weird that only debugged process is affected and there are no similar issues with multithreaded code in general. Maybe there is something in VirtualBox that handles processes with 'debugger attached flag' in a different way. 6 6 7 7 I think there isn't anything else to try. We have to wait if the issue gets attention and will be investigated. If not, the only solution is probably to move to different vitualization software because such serious bug makes software development almost impossible.
