Debugging in VS Code breaks with 'Unable to open <frozen importlib._bootstrap>' error

[DonJayamanne]

When debugging using the latest version of PTVSD I'm getting the following error:

Unable to open '<frozen importlib._bootstrap>': File not found (file:///Users/donjayamanne/Desktop/Development/PythonStuff/IssueRepos/debuggerTests/

Tested with yesterdays with a snapshot of yesterdays repo (around lunchtime) and it works.

Commenting out the following line of code fixes the issue :

            self.proc.pydevd_notify(
                pydevd_comm.CMD_ADD_EXCEPTION_BREAK, msg)

Possibly specific to Macs only, as this is required for VS.

[karthiknadig]

Previous version probably worked because it was not setting exception breakpoints at all.

[DonJayamanne]

@karthiknadig
I've tested the same changes in VS and I believe it doesn't work.
Here's what I've found

• Default behavior is for all exceptions raised to be handled and debugger to break into them
  https://github.com/Microsoft/ptvsd/blob/master/ptvsd/wrapper.py#L481

{
                    'filter': 'raised',
                    'label': 'Raised Exceptions',
                    'default': 'true'
                },

• VS Code uses the above setting

• If i turn off the above setting, the the issue reported here goes away. So the problem is with Raised Exceptions

• Now, i checked VS, and it doesn't seem to be using the above at all

• Upon intercepting the breakpoint settings passed by VS, i can see that value for notify_always is always 0
  I.e. the following line of code
  notify_always = 3 if break_raised else 0 always evaluates to 0.

• I then modified the code (PTVSD), to force notify_always = 3

• Now VS code fails to launch the debugger, it just hangs at the terminal. I believe the problem is an exception has been raised and its not able to handle it.

I.e. this same/similar behavior exists in VS, if the above flag is set.
I believe no one has encountered this because VS is ignoring this default value.

We're planning on removing this setting completely from release 1 of VS Code debugger as it completely breaks it.

[karthiknadig]

VS does not use Filters. VS uses Exception options to work with exceptions. There is a separate window by the name Exception Settings where we can set these options. Actually setting them to default false should be ok.

Actually removing the defaults should be fine as well.

exceptionBreakpointFilters=[
                {
                    'filter': 'raised',
                    'label': 'Raised Exceptions'
                },
                {
                    'filter': 'uncaught',
                    'label': 'Uncaught Exceptions'
                },

[DonJayamanne]

Actually removing the defaults should be fine as well.

Yes, as a temporary solution.

VS does not use Filters. VS uses Exception options to work with exceptions.

Either way, shouldn't VS respect the defaults provided by PTVSD?
Anyways, I'm not too concerned about VS. Just curious. Cuz I don't see the point in making them default to true if they aren't used.

At the end of the day, if VS uses the exception options, I believe this problem we're experiencing in VS code should also appear in VS. Do you agree?

[karthiknadig]

Either way, shouldn't VS respect the defaults provided by PTVSD?

I had set them to true as a way to allow catching and reporting exceptions VS before exception options feature in ptvsd was enabled. There isno UI in VS to work with filters. So setting the default was a way to force exception in VS. The defaults were only needed until exception options feature was enabled in ptvsd. Their impact on VSC was unknown at this point.

At the end of the day, if VS uses the exception options, I believe this problem we're experiencing in VS code should also appear in VS. Do you agree?

No, I have not seen this repro with exceptions settings. We can try this on the VM tomorrow.

[karthiknadig]

I think the problem might be that pydev is trying to hook every exception and it is causing the issue:
self.exceptions_mgr.add_exception_break('BaseException', break_raised, break_uncaught)
Since we use ignore_library=0, it is trying to hook exception in imported library modules. We should try setting that to 1 for VSC. VS, probably, does not run into this problem, because exception settings are for set for specific exceptions (say ValueError, KeyError) individually, unlike VSC where it is blanket set using BaseException.

[DonJayamanne]

VS, probably, does not run into this problem, because exception settings are for set for specific exceptions (say ValueError, KeyError

VSC to supports this, however it's done through the config. Should look into that.

[DonJayamanne]

Summary: This is the expected behavior. As a solution to prevent breaking into exceptions when program starts, the default value for the filter Raised Exceptions will be set to false

[Maransatto]

Hi, I still didn't get the idea of how to set this value of Raised Exeptions to false.
How can I do it?
I couldn't find it on VS Code settings nor launcher.

It all start to happen when I started to use modules from sibling folders using sys.path.insert(0,'../sibling-foler'')

Now I can even run my code but I can't debug due this error.

[The-any-Key]

I still getting this error when using breakpoints (works fine when no breakpoints is used):

  File "E:\Program Files\Reallusion\iClone 7\Bin64\lib\site-packages\ptvsd\_vendored\pydevd\_pydevd_bundle\pydevd_process_net_command.py", line 687, in process_net_command
    f = open(path, 'r')
FileNotFoundError: [Errno 2] No such file or directory: 'e:\\program files\\reallusion\\iclone 7\\<frozen importlib._bootstrap>'

[karthiknadig]

@The-any-Key This was caused by #1077 The fix is in master, but not released yet.

[The-any-Key]

Ok. Found why the bug happen to me. My environment was in:
E:\Program Files\Reallusion\iClone 7\Bin64
And I tried to debug scripts in:
E:\Program Files\Reallusion\iClone 7\Bin64\OpenPlugin
And this made the error come.

I just moved the scripts outside the environment to:
E:\Program Files\Reallusion\iClone 7
And the breakpoints works, and no errors :-)