1

Closed

Attaching Python debugger causes exception

description

Configuration:
  • VS2013 Pro + Update2
  • Python 3.4.1
  • PTVS 20618.00 - beta2 candidate
Repro:
  • Create a Bottle Web Project. Complete to install the virtual environment
  • No F5 (it also repro's if you have F5'ed)
  • Publish the project - successfully
  • In the Server Explorer, attach the Python debugger
Result:
  • Failed to attach to Azure Web Site: Invalid pointer (0x80004005)
Output window:
A first chance exception of type 'System.NullReferenceException' occurred in System.dll
A first chance exception of type 'System.NullReferenceException' occurred in System.dll
A first chance exception of type 'System.NullReferenceException' occurred in mscorlib.dll
A first chance exception of type 'System.NullReferenceException' occurred in Microsoft.PythonTools.dll
The thread 0xbf8 has exited with code 259 (0x103).

CallStack:
mscorlib.dll!System.Threading.WaitHandle.WaitAny(System.Threading.WaitHandle[] waitHandles, int millisecondsTimeout, bool exitContext)  Unknown
    Microsoft.PythonTools.VSInterpreters.dll!Microsoft.PythonTools.RegistryWatcher.Worker(object param) Line 266    C#
    mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state)    Unknown
    mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx)   Unknown
    mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx)   Unknown
    mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) Unknown
    mscorlib.dll!System.Threading.ThreadHelper.ThreadStart(object obj)  Unknown
Closed Jun 19 at 3:57 PM by Zooba

comments

Zooba wrote Jun 19 at 3:56 PM

This is an error deep inside the CLR - none of our code nor the .NET part of WaitHandle.WaitAny will throw NullReferenceException, so our only options are to silently handle all exceptions (this code has no way to report to the user) or let the corrupt state bring down the process. The latter is preferable here, especially since we'll get error reports and the CLR team may be able to figure out what's going wrong.