|
Bugzilla – Full Text Bug Listing |
| Summary: | Windows Softdebugger implementation consumes 100% CPU | ||
|---|---|---|---|
| Product: | [Mono] Mono: Runtime | Reporter: | andreas flucke <andreas.flucke> |
| Component: | debug | Assignee: | Jonathan Chambers <joncham> |
| Status: | RESOLVED FIXED | QA Contact: | Mono Bugs <mono-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | forgotten_vxPDddArjq, joncham, taktaktaktaktaktaktaktaktaktak |
| Version: | 2.6.x | ||
| Target Milestone: | --- | ||
| Hardware: | x86 | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | |||
| Bug Blocks: | 594193 | ||
| Attachments: |
test program, run using gtest.exe <app to debug>
New stripped gtest GTest with ReadLine :-) |
||
|
Description
andreas flucke
2010-03-11 13:12:37 UTC
Are you using mono 2.6.2 ? If so, there were a large amount of fixes to the soft debugger which will be in the upcoming mono 2.6.3. I'm now using 2.6.1 with monocharge-20100303. So i guess this isn't solved yet. (Is there a way of getting a 2.6.2 release for win without compiling ?) Unfortunately, we don't have daily builds of the windows installer. Could you try with the newly released mono 2.6.3 ? http://www.go-mono.com/mono-downloads/download.html Already done - result without change. So I tested this on windows using 2.6.3 with a command line test program, and it runs fine. Could you create a test case which reproduces the problem ? Thanks for investigating this. Surely i cannot claim to have a perfect implementation. The reason for posting this was that the same program/implementation runs without this problem under OpenSuse Linux. I cannot post my implementation here because it's to complex (and it's surely not your task to find somebody elses bugs :-) But if you would be able to send me your implementation i can see what's the difference and maybe work out the point which causese this behavior. Created attachment 352330 [details]
test program, run using gtest.exe <app to debug>
Created attachment 352351 [details]
New stripped gtest
Seems i've leaded you in the wrong direction.
Waiting in GetNextEvent isn't the point.
The problem occurs when the vm is suspended.
In the modified testcase i've inserted a stupid Console.ReadLine(), which normally doesn't cost CPU usage, but in this case.
That testcase doesn't contain a Console.ReadLine (). Also, what is the app which needs to be debugged for the problem to occur ? Created attachment 352378 [details]
GTest with ReadLine :-)
Sorry, i picked the wrong one.
I can reproduce this now. It looks the debuggee is spinning, not the debugger process. Jonathan, could you look at this ? I can't debug anything under windows. Basically, when running the testcase in the last attachment, like this: mono test.exe hello.exe the debuggee starts to spin when it is suspended, consuming 100% cpu and/or crashes. I'll take a look at it. It seems to be spinning here:
#ifdef HOST_WIN32
if (WAIT_TIMEOUT == WaitForSingleObject(suspend_cond, 0))
{
mono_mutex_unlock (&suspend_mutex);
Sleep(0);
mono_mutex_lock (&suspend_mutex);
}
else
{
}
Looking at this. Windows Softdebugger doesn't work any more with 2.6.4 :-) After loading the assemblies there's an unspecified NullReferenceException. Should i file a bug or is this a temporarily side effect ? What i meant was :-( No idea, the debugger is not really tested under windows. Also, its possible that that NullReferenceException is thrown by your code, not the debugger code. No. Just use the testcase to reproduce this. I can reproduce the NRE in 2.6.4. It appears to be in the runtime. If I copy the 2.6.3 mono.dll on top of my 2.6.4 install, the issue goes away. Fixed in HEAD and backported to 2-6 in r156908. NullReferenceException fixed in 2.6 branch at r156975. While the NRE seems to be fixed in 2.6.7, the CPU usage remains 100% :-( So this should be reopen. Still exists in HEAD. Code in question is used because mono_cond_wait is not implemented correctly for Windows. Google shows a few ways to implement condition variables for Windows. Section 3.4 seems to be the recommended approach. http://www.cs.wustl.edu/~schmidt/win32-cv-1.html At Vista, MS added support for condition variables to Win32 API. http://msdn.microsoft.com/en-us/library/ms682052(VS.85).aspx Should we use Win32 ones on Vista+, and another implementation on XP and before? The problem with using the vista functions is that it would require us to compile different binaries for vista. I'm seeing the high cpu usage as well, when the runtime is suspended during a debugging session on windows. (Windows 7 64bit, in my case) Changing that line to Sleep(1) or Sleep(2) would help mitigate the issue. Can we not dynamically check for those functions at runtime, and fallback to the current implementation (also with nonzero sleep)? Fixed in HEAD/2.10/2.6 branches by using a Sleep(1) instead of Sleep(0). |