VirtualBox

Ticket #9659 (closed defect: fixed)

Opened 3 years ago

Last modified 7 weeks ago

MultiThreaded C# solution crashes Visual Studio 2010 debugger with corrupted memory => Fixed in SVN

Reported by: mbursill Owned by:
Priority: major Component: other
Version: VirtualBox 4.1.2 Keywords: Memory Corruption
Cc: Guest type: Windows
Host type: Windows

Description (last modified by ramshankar) (diff)

I use Virtual Box 4.1.2 with a Windows 7 x64 Guest. On my guest is Visual Studio 2010 Pro.

I'm developing a C# project which makes heavy use of threads. When stepping through the code on my guest the Visual Studio debugger throws the exception:

"Attempted to read or write protected memory. This is often an indication that other memory is corrupt"

Using Visual Studio 2010 on the host, the debugger never throws this exception. I tested multiple hardware and rebuilt guest images with the same result. I believe that Virtual Box is corrupting the memory of the Visual Studio debugger.

Attached is the C# project demonstrating the issue.

Attachments

MemoryLeakTest.rar Download (29.7 KB) - added by mbursill 3 years ago.
MultiThreaded C# project showing Visual Studio Debugger memory corruption
VBox.log Download (89.2 KB) - added by mbursill 3 years ago.
Log
Program.cs Download (692 bytes) - added by mhanor 12 months ago.

Change History

Changed 3 years ago by mbursill

MultiThreaded C# project showing Visual Studio Debugger memory corruption

Changed 3 years ago by mbursill

Log

comment:1 Changed 2 years ago by sommardahl

I'm trying to fix this problem on my dev box as well. In absence of responses to my exact problem, I've been looking for possibly related issues. I found this question on SO that might be helpful.  http://stackoverflow.com/questions/5187367/caching-application-block-crashing-iis

comment:2 Changed 2 years ago by mbursill

I made a clean install image of Win 7 32bit, tossed on VS 2010 and still ran into the problem. It's not a corrupted framework. Until the issue gets resolved I've switched to using VMWare Player which doesn't exhibit the problem.

comment:3 in reply to: ↑ description Changed 2 years ago by joe42

Replying to mbursill:

I use Virtual Box 4.1.2 with a Windows 7 x64 Guest. On my guest is Visual Studio 2010 Pro.

We see the same on 4.0.12 with WinXP x86 guests. We see this with Visual Studio 2005 as well.

The guests are dual processor - we will try to see if switching to single processor will do anything.

The problem happens several times a day for the developers.

comment:4 follow-up: ↓ 5 Changed 2 years ago by mbursill

I attempted many different VBox configurations and found that running under a single processor caused the exception to throw less frequently. Not much less, but noticeable.

comment:5 in reply to: ↑ 4 Changed 2 years ago by joe42

Replying to mbursill:

I attempted many different VBox configurations and found that running under a single processor caused the exception to throw less frequently. Not much less, but noticeable.

We still see this on 4.1.8r75467

comment:6 Changed 20 months ago by TimBailey

Ubuntu 64bit host 4 cpu 8gb RAM, Win2008Svr guest 2 cpu 4gb RAM, VS2010SP1 Pro Virtualbox 4.1.20, with guest additions installed

"System.AccessViolationException was unhandled Message: Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

When debugging by attaching to w3wp.exe (IIS) I "often" get a similar message as above and the debugging session terminates.

I've disabled nested paging as suggested in this post  http://altamodatech.com/blogs/?p=62 but still having the issue.

I can pretty easily repro, not sure what would be usefull as far as dumps. I can dump vs or w3p or something else. I've saved a "Minidump with Heap" from within VS, but its 120mb compressed. I can send if that would be useful.

Would like to help get this fixed as it is really hurting my debugging....

Thanks Tim Bailey

comment:7 Changed 13 months ago by Willie

I've seen this issue too. But also when I run VS on the host. It looks like it's a VS bug but for me it manifests more often in a virtual machine.

comment:8 Changed 12 months ago by Petr Vones

Same issue with Visual Studio 2012 Update 2, VirtualBox 4.2.12, Core i5 2540M, VT-x enabled. Windows 7 x64 host, Windows Server 2008 R2 guest.

Disabling Nested Paging in configuration did not help.
Using a single processor in configuration did not help.
Setting x86 platform in Visual Studio debug configuration did not help.

The issue is very annoying and probably forces me to use VMWare which I don't like because it is way too much complex and consumes more system resources.

I can always reproduce it in 10 seconds with the attached sample project. I also tried that in VMware and it works there. Please fix it, I don't believe it is a VS bug.

Last edited 12 months ago by Petr Vones (previous) (diff)

comment:9 Changed 12 months ago by Petr Vones

The occurence of the AccessViolationException in the example code (x86 platform) decreases when "Native code debugging" is enabled but still happens. If so, it is always in the same place:

_ZwWaitForSingleObject@12:
7738F89C  mov         eax,1  
7738F8A1  mov         ecx,0Dh  
7738F8A6  lea         edx,[esp+4]  
7738F8AA  call        dword ptr fs:[0C0h]  
7738F8B1  add         esp,4  <---------------- here 
7738F8B4  ret         0Ch  
7738F8B7  nop

It looks like a corrupted stack.

comment:10 Changed 12 months ago by Petr Vones

Microsoft Visual Studio Debugger QA staff resolution  https://connect.microsoft.com/VisualStudio/feedback/details/785380/please-reopen-bug-662764 is "It sounds like this is an issue with Virtual Box. We are not aware of how to fix this on our side so we would recommend reaching out to Oracle with the feedback that their product breaks Visual Studio in a particular way."

There is 100% reproducible test case attached. Detailed steps to reproduce it:

  1. download attached MemoryLeakTest.rar
  2. extract (better to delete 'bin' and 'obj' directories) and open the solution in Visual Studio 2012 or 2010
  3. open NumberCounter.cs in code editor
  4. goto line 79, put breakpoint there
  5. press F5 (Run)
  6. press 'Start' button on the form
  7. when the debugger stops at the breakpoint, press and hold F10 key

The debugged application will crash with AccessViolationException after approx 10 seconds. If you enable "Native code debugging" in the example project it will take more time to crash and the AV address is still the same, see the ticket comment 9 for details. Note that it never happens in non-virtualized environment or using VMware.

System information: Visual Studio 2012 Update 2 or 2010 SP1, VirtualBox 4.2.12, Core i5 2540M, VT-x enabled, Nested Paging disabled, 2 virtual CPU configured, Windows 7 x64 host, Windows Server 2008 R2 x64 guest.

Could you please indicate whether you will try to fix it or not ?

Last edited 12 months ago by Petr Vones (previous) (diff)

comment:11 Changed 12 months ago by Petr Vones

Similar issue reported here  https://forums.virtualbox.org/viewtopic.php?f=6&t=30841 for Visual Studio 2008 and version 3.1.6. The issue went away by downgrading to version 3.1.2. Any clue ?

comment:12 Changed 12 months ago by f456

100% reprod. indeed.

It appears this issue occurs when 32 bit application is debugged on a x64 machine. Looks to me that somehow the calling into or returning from the "heavesn gate", ie the 'connection' between x64 and x86 mode, corrupts a stack.

This does not appear to be a VS bug, and should really be investigated, as the root cause may be much deeper.

comment:13 Changed 12 months ago by Petr Vones

Even more complicated, I can reproduce it by all combinations. 32 bit application on x64 virtual machine, 64 bit application on x64 virtual machine and 32 bit application on x86 virtual machine. All these environments produces the same error under Visual Studio debugger when stopping on a breakpoint. Note that VMware nor Virtual PC does not have the issue on the same hardware.

Last edited 12 months ago by Petr Vones (previous) (diff)

comment:14 Changed 12 months ago by mhanor

Can you reproduce the crash if you comment out the accessors for the Count property?
I can reproduce an access violation using a simpler C# application. But not if I use a field, instead of a property.

Changed 12 months ago by mhanor

comment:15 Changed 12 months ago by Petr Vones

Actually the issue does not have anything with deugging multithreaded code. I have much more simpe test case that is always 100% reproducible as well:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;

namespace ConsoleApplication1
{
  class Program
  {
    static void Main(string[] args)
    {
      for (int i = 0; i < 100000; i++)
      {
        Thread.Sleep(0); // <---- put breakpoint here, press and hold F10 to step over and wait few seconds to crash
      }
    }

  }
}

That is really odd. I have tried additional virtualization settings available via VBoxManage.exe only, namely '--hwvirtexeexcl on', '--vtxvpid off' and '--largepages off' but nothing helped.

comment:16 Changed 12 months ago by Petr Vones

mhanor: Yes, can reproduce it as well with the property but not as a field.

comment:17 Changed 12 months ago by mhanor

In your example, the function, inside the loop, can be any function. It will crash with anything that exercises the call stack.

comment:18 Changed 12 months ago by Petr Vones

Yes, but this one throws SEHException instead of AccessViolationException

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
  class Program
  {
    static void Main(string[] args)
    {
      for (int i = 0; i < 1000; i++)
      {
        M1(i); // <- put breakpoint here, press and hold F5 key
      }
    }

    private static void M1(int i)
    {
    }
  }
}

Still don't know whether we can get attention to start investigate the bug. I have already asked it in vbox-dev forum https://www.virtualbox.org/pipermail/vbox-dev/2013-April/011417.html without any response yet.

Version 0, edited 12 months ago by Petr Vones (next)

comment:19 follow-up: ↓ 21 Changed 12 months ago by f456

affects the occurence of the bug.

how? less frequently, after a longer period of time? This is one wired bug.

In native c++ i cannot reproduce the bug on x86-x86. Yet. I ll install c# later on to check your examples.

comment:20 Changed 12 months ago by MarkCranness

I also get occasional "Attempted to read or write protected memory. This is often an indication that other memory is corrupt" messages when stepping thru C# code in VS 2010.

Another debugging problem I have, which I'm hoping is related is: Sometimes F10 or F11 Step does not step, but instead acts as F5 Run.

I often have to set breakpoints to make sure that F10 or F11 does not run away too far ahead of where I need to debug.

comment:21 in reply to: ↑ 19 Changed 12 months ago by Petr Vones

how? less frequently, after a longer period of time?

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.

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.

Does all of you run VirtualBox on Windows host ? Any chance to check the issue on different one ?

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.

Last edited 12 months ago by Petr Vones (previous) (diff)

comment:22 Changed 12 months ago by mhanor

I can reproduce it on an Ubuntu 13.04 x86 host, running Windows 7 x86 as guest.

Last edited 12 months ago by mhanor (previous) (diff)

comment:23 Changed 12 months ago by jeff.deseret.tech

Getting the same results here with Linux 3.8.x on ArchLinux and OS X Mountain Lion 10.8.2 and 10.8.3. Occurs much more frequently on OS X. Tolerably rare on ArchLinux.

On the OS X host, guest also occasionally throws an "illegal operation" in IIS Express while debugging.

Just attempted to disable nested paging and will see if it improves the frequency on Mountain Lion.

Guest:

  • Windows 7 Professional x64 SP1
  • Visual Studio 2012 Update 2
  • Debugging ASP.NET MVC and WPF projects

Hosts:

  • ArchLinux 3.8.x; Core i7-3770K; 32GB RAM
  • Mountain Lion 10.8.3; Retina MBP mid-2012; 8GB RAM

This has happened across several recent versions of Virtual 4.2.

VT-X is enabled, with nested paging and some other stuff. Guest has 4 CPUs. As above, just disabled nested paging and will see if that improves things. Will also attempt to set CPU affinity on the debugged process.

I wonder if something has made this bug more severe in recent editions, since it went mostly unnoticed for nearly a year and a half, and now has a lot of activity.

comment:24 follow-up: ↓ 26 Changed 12 months ago by AltGr

I also experience this problem for a very long time now.

Host Win 7 x64 - Core i7 2600K, Guests Win 7/2008R2 x64

I have some additional info: I can prevent this bug from happening by assigning only one cpu to the guest AND restricting the VirtualBox.exe process to only one cpu on the host (TaskManager -> Set Affinity). So the bug occurs when the VirtualBox Process is switching cpu on the host.

And, as mbursill already stated, VMware does not have this problem: The same VM that exhibits the problem in VirtualBox, when converted to VMDK runs without a problem in VMware Player.

@jeff.deseret.tech: One cause for this bug staying unnoticed for so long might be that many people (me included) never thought this to be a bug in VirtualBox but blamed Visual Studio.

comment:25 Changed 12 months ago by Petr Vones

@AltGr: VMware (Workstation and ESX) nor Virtual PC have the issue. I've been using Visual Studio 2005, 2008, 2010 without a single occurence of it for many years. As you have experienced, the same virtual machine have the issue in VirtualBox only so it is hard to blame Visual Studio debugger.

I'll try your workaround to set affinity of the host process (I'd have never thought it could help). Unfortunately I do a lot of multithread code and I'd like to test it in more real environment than a single-CPU one. After all, supporting multiple cores was one of reasons to move from Virtual PC to VirtualBox. Sad.

Good news is that I've just got a reply in vbox-dev mailing list that confirms the issue https://www.virtualbox.org/pipermail/vbox-dev/2013-May/011456.html

Does anyone have a chance to check the issue on AMD CPU based system ?

Last edited 12 months ago by Petr Vones (previous) (diff)

comment:26 in reply to: ↑ 24 Changed 12 months ago by Petr Vones

Replying to AltGr:

I have some additional info: I can prevent this bug from happening by assigning only one cpu to the guest AND restricting the VirtualBox.exe process to only one cpu on the host (TaskManager -> Set Affinity). So the bug occurs when the VirtualBox Process is switching cpu on the host.

Yes, I can confirm it helps a bit but the issue is still present anyway.

comment:27 Changed 11 months ago by pgates

Over the last few versions of VirtualBox, this issue occurs more frequently on my VB VMs, too. It has become somewhat of a hindrance. Seems to show up consistently when debugging C# apps.

Host: OSX 10.8.3, i7-2820QM

Guest: Win 7 Enterprise x64, VS2012 Update 2, VS2012 SP1

comment:28 Changed 11 months ago by mhanor

It can also be reproduced by enabling the option "when breakpoint is hit", by selecting "continue execution", even when delaying each execution by one second, using a script.

My 2-CPU guest crashes if I set the CPU affinity to one CPU (STOP 0x101), but doing that for a single-CPU guest, I haven't observed any improvements.

comment:29 follow-ups: ↓ 30 ↓ 31 Changed 11 months ago by ramshankar

  • Description modified (diff)

So I finally got some time today to setup a Windows 7 VM, Visual Studio 2012 and debug the C# console application testcase provided in comment 18. I can confirm that it's indeed broken with VirtualBox 4.2.x and even with single VCPU VMs and is a VirtualBox bug.

The new VT-x code in trunk doesn't have this problem. I didn't have time to investigate even deeper. Unfortunately, identifying and backporting the exact fix to the 4.2.x branch will not be trivial and will require more investigation effort and time. All I can say now is, it should be fixed in the next major release, not in 4.2.x.

Maybe later we could provide you with a test build here for you to try that the fix works. Thank you for the report.

Last edited 11 months ago by ramshankar (previous) (diff)

comment:30 in reply to: ↑ 29 Changed 11 months ago by pgates

Replying to ramshankar:

...I can confirm that it's indeed broken with VirtualBox 4.2.x and even with single VCPU VMs and is a VirtualBox bug.

The new VT-x code in trunk doesn't have this problem. I didn't have time to investigate even deeper. Unfortunately, identifying and backporting the exact fix to the 4.2.x branch will not be trivial and will require more investigation effort and time. All I can say now is, it should be fixed in the next major release, not in 4.2.x.

Maybe later we could provide you with a test build here for you to try that the fix works. Thank you for the report.

Ram, thanks so much for taking some time to look into this issue. I, for one, would find such a test build useful if the next major version is expected to be a ways off.

comment:31 in reply to: ↑ 29 Changed 11 months ago by Petr Vones

Replying to ramshankar:

The new VT-x code in trunk doesn't have this problem.

Ram, this is good news the issue is going to be fixed. I understand that it is not easy to propagate it to the older 4.2.x branch. Is there any time frame when the 4.3 will be released (this summer, end of the year, next year etc.) ? Thanks again.

comment:32 follow-ups: ↓ 33 ↓ 34 ↓ 46 Changed 11 months ago by frank

We cannot provide any ETA but I can say that it's a matter of months, not years. Sorry for not being more specific.

 Here is a Windows test build.  Here is a Mac OS X test build.  Here is a 64-bit Linux .run package.  Here is the corresponding extension pack.

Please be aware that these test builds are bleeding edged builds!

Last edited 11 months ago by frank (previous) (diff)

comment:33 in reply to: ↑ 32 Changed 11 months ago by pgates

Replying to frank:

We cannot provide any ETA but I can say that it's a matter of months, not years. Sorry for not being more specific.

 Here is a Windows test build.  Here is a Mac OS X test build.  Here is a 64-bit Linux .run package.  Here is the corresponding extension pack.

Please be aware that these test builds are bleeding edged builds!

frank - Awesome, thanks. Using the basic C# code above, I cannot repro the issue with the OS X test build. Will update if anything else goes off the rails. Thanks again.

comment:34 in reply to: ↑ 32 Changed 11 months ago by AltGr

Replying to frank:

 Here is a Windows test build.

I too can confirm that the bug seems to be solved with this build! I tried debugging the sample code from comment 18 for several hundred loops -> No memory exception!

And, also very important for me, the "other" debugging bug causing the debugger to "Run" instead of "Step Into/Step Over" never occured with this build either, even after minutes of running throught the code with F10 or F11.

Thanks to the developers. I'm looking forward to the next major release containing the fix.

Last edited 11 months ago by AltGr (previous) (diff)

comment:35 Changed 11 months ago by frank

  • Summary changed from MultiThreaded C# solution crashes Visual Studio 2010 debugger with corrupted memory to MultiThreaded C# solution crashes Visual Studio 2010 debugger with corrupted memory => Fixed in SVN

comment:36 Changed 11 months ago by ximbal

Links on the files are Broken, I've been experiencing the same issues as described, can you fix the Links?

comment:37 Changed 10 months ago by frank

 Here is another test build and  here the corresponding extension pack. These links expire after a 21 days. Treat them as bleeding-edge builds.

comment:38 Changed 10 months ago by ximbal

Thanks for the Build, appreciated, however, I am using Linux, could you build that one?

comment:39 follow-up: ↓ 44 Changed 10 months ago by frank

 Here is a .run package for Linux 64-bit. Tell me if you need a package for a specific distribution.

comment:40 Changed 10 months ago by ximbal

I have been using Virtualbox in Linux Mint 14, I updated to Linux Mint 15, a fresh copy, just installed the package you submitted, created a new instance of Windows 7 virtual machine, using the last working copy of virtual drive, and I am getting this error message while attempting to run it.

http://imecas.com/images/Screenshot%20from%202013-06-07%2012:08:21.png

I'll be working trying to find a way to solve this, however the Bleeding edge package you've submitted before ( http://www.virtualbox.org/download/testcase/VirtualBox-4.2.51-85607-Linux_amd64.run), worked like a charm :(

Appreciate deeply the help.

comment:41 follow-up: ↓ 42 Changed 10 months ago by sunlover

ximbal, this error message can happen if the corresponding extpack was not installed.

Did you install the extpack?

 http://www.virtualbox.org/download/testcase/Oracle_VM_VirtualBox_Extension_Pack-4.2.51-86228.vbox-extpack

comment:42 in reply to: ↑ 41 Changed 10 months ago by willit1

Replying to sunlover:

ximbal, this error message can happen if the corresponding extpack was not installed.

Did you install the extpack?

 http://www.virtualbox.org/download/testcase/Oracle_VM_VirtualBox_Extension_Pack-4.2.51-86228.vbox-extpack

Hi there,

I have tried the link in comment 39 and also installed the above extension pack, but ehen trying to start up my older VM's from a previous install I still get the virtualbox error as in comment 40. I noticed that the build version to the extension pack and the link to the Linux amd 64 .run script was different, could this cause a problem also?

Is there something else I can do or try, and if not how do uninstal that version I have just installed?

Thank you very much for all of this info so far. :-)

Last edited 10 months ago by willit1 (previous) (diff)

comment:43 Changed 10 months ago by ximbal

Yes i made sure I have installed the extpack before attempting any new instances and runs, I decided to create a fresh new instance of virtual machine to avoid any backwards compatibility bugs/issues, bottom line, I did everything according to my common sense, I honestly belive it has to do with this extpack, I haven't find any solutions so far, I'll keep diggin in. Look forward to hear from you, in the mean time, gracias amigos!.

comment:44 in reply to: ↑ 39 Changed 10 months ago by quickbooks

Replying to frank:

 http://www.virtualbox.org/download/testcase/VirtualBox-4.2.13-86272-Linux_amd64.run Here is a .run package for Linux 64-bit. Tell me if you need a package for a specific distribution.

That is 4.2.13?

Don't you want to post the trunk build here (4.2.51)?

comment:45 Changed 10 months ago by Petr Vones

With Visual Studio 2013 Preview running in VirtualBox 4.2.14 the issue has become even more irritating and frequent. It kills both the debugged application and VS itself.

Has anyone tried the VS 2013 Preview in the VirtualBox beta 4.2.51 build and confirm the new SVN code still fixes the issue ?

Last edited 10 months ago by Petr Vones (previous) (diff)

comment:46 in reply to: ↑ 32 Changed 9 months ago by Eth0s

Replying to frank:

We cannot provide any ETA but I can say that it's a matter of months, not years. Sorry for not being more specific.

 Here is a Windows test build.  Here is a Mac OS X test build.  Here is a 64-bit Linux .run package.  Here is the corresponding extension pack.

Please be aware that these test builds are bleeding edged builds!

Hi ! I have the same problem... "Windows test build" link is broken .... Can you fix it ? (+ ext pack ?) Any correction planned in the next official release ? Thanks a lot!

Last edited 9 months ago by Eth0s (previous) (diff)

comment:47 Changed 8 months ago by jeff.deseret.tech

Hello all.

I develop in Visual Studio on VirtualBox all the day long, and there are serious problems with its debugger and <= VirtualBox 4.2.x. Not only does the corrupted memory exception occur frequently, but the debugger shows other strange behaviors, like exiting loops early. One may say it is almost useless through the current production builds of VirtualBox. The problem seems worse on OS X hosts than Linux hosts.

This is indeed rectified by SVN builds of VirtualBox on an ArchLinux host, although it can be quite hairy to build. I will probably upload a PKGBUILD to the AUR to facilitate the build process soon.

If one *was* to attempt to bisect the repository in order to find the patch or patches that resolved this bug, what would be a good starting point? There are a lot of commits to traverse, so the more it can be narrowed down in both timeframe and affected files, the easier such a traversal would be.

comment:48 Changed 8 months ago by ramshankar

Not to sound too pessimistic, but personally, I don't think it is worth the effort in trying to fix the debugging problems in 4.2.x when the next major release is around the corner.

I'm almost certain it's not a single changeset that "broke" it or fixed it. I don't think the debugging was working reliably in the first place to begin with. With trunk (which the next major release will be based on) has rewritten VT-x, AMD-V code that replaced the existing code. The existing code wasn't changed.

In other words, the chances of this being a one change regression is pretty slim and therefore bisect-regression analysis is unlikely to find anything. At best, you may find one changeset that magically works but that changeset might be a flip of the switch to the new VT-x/AMD-V code that spans thousands of lines.

Last edited 8 months ago by ramshankar (previous) (diff)

comment:49 Changed 8 months ago by jeff.deseret.tech

Ah, I see. I didn't understand that a full rewrite of the VT-x code had occurred. It does indeed sound like a bisection would not be useful.

Do we have an ETA for VirtualBox 4.3? This is a fairly egregious bug that makes .NET development with VirtualBox much more difficult than necessary. I'd love to see the fix placed in the production release cycle soon.

comment:50 Changed 8 months ago by Petr Vones

I understand that it does not make sense to fix that in 4.2 version.

Unfortunately it makes .NET development impossible because if you are hunting a bug for half an hour and then the debugger crashes due this issue ... your productivity is zero.

What makes me worry is that nobody knows what exactly causes it and what fixed it in upcoming 4.3 version. In case there will appear another issue related to VS debugging in 4.3 version, there is probably no hope to get it fixed soon.

Last edited 8 months ago by Petr Vones (previous) (diff)

comment:51 Changed 8 months ago by ramshankar

It is not that nobody knows what is causing it. We don't have the time right now to investigate this issue especially when there is no significant customer demand and thus is not feasible.

If anyone in the open source community feels like investigating 4.2.x to see why it breaks VS debugging, feel free to send us patches. We're more than willing to review and integrate them if it works and is completely safe to backport.

Last edited 8 months ago by ramshankar (previous) (diff)

comment:52 follow-up: ↓ 53 Changed 8 months ago by Eth0s

Thanks for replies. I understand the difficulty to investigate but temporary patch posted before seemed to work is'nt it ? Even if it is not posible to include this in futures release this solution would be useful right now :) Is it possible to have active links again please ?

Last edited 8 months ago by Eth0s (previous) (diff)

comment:53 in reply to: ↑ 52 ; follow-up: ↓ 54 Changed 8 months ago by ramshankar

Replying to Eth0s:

I understand the difficulty to investigate but temporary patch posted before seemed to work is'nt it ? Even if it is not posible to include this in futures release this solution would be useful right now :) Is it possible to have active links again please ?

We've put out a 4.3 beta which includes this fix. Since the beta is out the next major release will (if all things go well) follow soon.

comment:54 in reply to: ↑ 53 Changed 6 months ago by Eth0s

Replying to ramshankar:

Replying to Eth0s:

I understand the difficulty to investigate but temporary patch posted before seemed to work is'nt it ? Even if it is not posible to include this in futures release this solution would be useful right now :) Is it possible to have active links again please ?

We've put out a 4.3 beta which includes this fix. Since the beta is out the next major release will (if all things go well) follow soon.

Thanks a lot! It seems to works like a charm.

comment:55 Changed 6 months ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

VBox 4.3 is out.

comment:56 follow-up: ↓ 57 Changed 7 weeks ago by MarkCranness

One of the problems fixed by this has come back (or perhaps never left?)

With Windows 7 x64 host and Windows Server 2008R2 (x64) guest, Visual Studio debugging does this:

F10 step-over will not step over, but will Run, and will run to completion, ignoring any breakpoints set.

This is happening with less frequency than the previous problem of F10 running away (which previously stopped on breakpoints), but is more painful because it does not stop at breakpoints.

Restarting the debugged program and the breakpoints are active again.

comment:57 in reply to: ↑ 56 ; follow-up: ↓ 58 Changed 7 weeks ago by Petr Vones

Replying to MarkCranness:

One of the problems fixed by this has come back (or perhaps never left?)

I guess this is different issue. The original issue was that the debugged process almost always crashed with access violation or SEH exception on breakpoint calling a method.

What Visual Studio version dou you have ? I have exactly same setup, W7 x64 host and W2008R2 guest. VS 2013 Update 1.

Also check
 https://connect.microsoft.com/VisualStudio/feedback/details/556756/debugger-randomly-treats-step-into-and-step-over-as-run-to-completion
 https://connect.microsoft.com/VisualStudio/feedback/details/634349/debugging-the-code-using-f10-or-f11-is-not-working-step-over-and-step-in-not-working-as-expected

Last edited 7 weeks ago by Petr Vones (previous) (diff)

comment:58 in reply to: ↑ 57 Changed 7 weeks ago by MarkCranness

Replying to Petr Vones:

I guess this is different issue.

Yes, it may be different.

I have assumed the F10 Step issue is related to the original issue, but I could be wrong (I and AltGr - ticket:9659#comment:34 - mentioned the F10 issue) and VirtualBox 4.3 seemed to fix my F10 Step issue.

I have Microsoft Visual Studio 2010 Version 10.0.40219.1 SP1Rel

After reading your MS connect links (thanks), my problem may be VS 2010 related rather than VirtualBox : one of the thru links mentioned that debugger property eval timeouts could cause problems, and I do get those for some of my properties that have long-running once-only initialisation.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use