Running Studio with Debugger

[nathanm]

This is not something new that has been happening but whenever I run the Visual Studio debugger with SageTV.exe as an attached process and I have the studio window open I get foul debug break points..

Here is the call stack..

> ntdll.dll!_DbgBreakPoint@0()
ntdll.dll!_RtlpBreakPointHeap@4() + 0x28 bytes
ntdll.dll!_RtlAllocateHeapSlowly@12() + 0x2ec0d bytes
ntdll.dll!_RtlDebugAllocateHeap@12() + 0xaf bytes
ntdll.dll!_RtlAllocateHeapSlowly@12() + 0x2ea6c bytes
ntdll.dll!_RtlAllocateHeap@12() + 0xacc4 bytes
msvcrt.dll!__heap_alloc() + 0xe0 bytes
msvcrt.dll!__nh_malloc() + 0x13 bytes
msvcrt.dll!_malloc() + 0x27 bytes
fontmanager.dll!6d26ab0c()
[Frames below may be incorrect and/or missing, no symbols loaded for fontmanager.dll]
fontmanager.dll!6d26add8()
fontmanager.dll!6d26b4bd()
jvm.dll!6d79b172()
ntdll.dll!_RtlAllocateHeapSlowly@12() + 0x3da bytes
jvm.dll!6d6fa293()
jvm.dll!6d7017f1()
jvm.dll!6d75bd89()

Has anybody else encountered these problems while trying to do this?

[GKusnick]

I don't often have a reason to attach the VS debugger to SageTV, but when I tried it just now I didn't see any such behavior in a few minutes of testing.

From the call stack it doesn't look like a SageTV or Java issue, since the breakpoint happens deep in the C++ runtime. Are you by any chance running with debug versions of the runtime DLLs, or a checked build of the OS?

[nathanm]

Does anybody know where I could find the symbols for the jvm.dll? Or how I can debug what is happening here?

Is there a way to run sagetv using java.exe and then attach the jdb to it or something of the like?

[GKusnick]

Googling RtlpBreakPointHeap turned up this:

http://blogs.msdn.com/greggm/archive...16/114893.aspx

which seems to indicate that there's a memory clobbering bug somewhere. The JVM is one place this bug could be, and you could perhaps test that theory by trying different versions of Java.

However I'm guessing that the reason you're attaching a VS debugger in the first place is because you're writing a .Net plugin for Sage using the Java JNI. In that case, it seems more likely that the bug is in your JNI code rather than in the JVM.

In either case, the Pageheap tool mentioned in the linked blog should help pin it down.

[nathanm]

With version 6 of SageTV and Java update 6 I get a debug break right out of the gate as soon as sagetv process loads. I don't get the SageTV logo picture, it just breaks. This sucks.

[nathanm]

Oh and this time there is no debug information or call stack information. It just breaks in the disassembly..

[GKusnick]

I'm still not clear on exactly what it is you're trying to do. Does Sage V6 + Java 6 work for you normally, with no plugins or addons and no debugger? If not, that would be an issue for Sage tech support.

If Sage works normally, then what is the configuration in which it doesn't work? If you're trying to start Sage from within the Visual Studio debugger, and that's not working, then can't you start Sage normally and attach the debugger later? Come to that, why are you trying to attach a Visual Studio debugger at all? Again, I'm guessing it has something to do with a .Net plugin you're trying to develop, but you haven't been very clear about that so far.

[nathanm]

Even though this top says "Running Studio with Debugger", I the new problem I get without even having to run Studio.

I am writing plugin for SageTV using C with JNI. I am not using .NET or managed code. The debugger breaks even before my plugin is loaded. It just breaks somewhere in the SageTV executable. If I delete all of my plugin files, it still breaks.

Running SageTV without attaching a debugger works fine.

But.. if you use Windows Debug Tools and not Visual Studio you still get a debug break point.

Specifically..

Microsoft (R) Windows Debugger Version 6.6.0007.5
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: "C:\Program Files\Frey Technologies\SageTV\SageTV.exe"
Symbol search path is: SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols

Executable search path is:
ModLoad: 00400000 004fb000 image00400000
ModLoad: 7c900000 7c9b0000 ntdll.dll
ModLoad: 7c800000 7c8f4000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 77d40000 77dd0000 C:\WINDOWS\system32\USER32.dll
ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
(2568.3198): Break instruction exception - code 80000003 (first chance)
eax=00241eb4 ebx=7ffd4000 ecx=00000007 edx=00000080 esi=00241f48 edi=00241eb4
eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!DbgBreakPoint:
7c901230 cc int 3

Having to attach the debugger manually each time I wanted to test the plugin would be crazy.