Skip to content

inspector: breakpoints and letter case in script path argument #19273

Closed
Closed
inspector: breakpoints and letter case in script path argument#19273
Labels
inspectorIssues and PRs related to the V8 inspector protocol.windowsIssues and PRs related to the Windows platform.

Description

@vsemozhetbyt
vsemozhetbyt
opened on Mar 10, 2018
  • Version: master (10)
  • Platform: Windows 7 x64
  • Subsystem: inspector

Trying to debug the #19250, I've found a confusing behavior in debugging with Google Chrome: breakpoints depend on the case of script path argument (in particular. drive letter case).

  1. Create test.js file:
'use strict';

console.log(1);

console.log(2);
  1. Run it the first time with the full path and lowercase drive letter:
j:\temp>node --inspect-brk j:/temp/test.js
  1. Run to completion in the inspector, open the file and add a breakpoint to the file, then close the file:

1

  1. Disconnect the inspector. Run it the second time with the full path and lowercase drive letter again:
j:\temp>node --inspect-brk j:/temp/test.js
  1. You can see a tab with the wrapped file. The breakpoint is listed in Breakpoints list, but not marked in the file:

2

  1. Run to completion in the inspector. No breakpoint is activated.

  2. Disconnect the inspector. Run it the third time with the full path and uppercase drive letter:

j:\temp>node --inspect-brk J:/temp/test.js
  1. First, you can see only the wrapped file with breakpoint mark, then after a second, it is automatically replaced by not-wrapped one with recalculated breakpoint:

3

  1. Run to completion in the inspector. Breakpoint is activated.

Also, compare info on the chrome://inspect/#devices page:

  • with lowercased drive letter: j:/temp/test.js file:///J:/_temp_test.js
  • with uppercased drive letter: J:/temp/test.js file:///J:/_temp_test.js

It seems Google Chrome inspector should compare paths case insensitively on OS like Windows. Otherwise, the behavior is confusing: only uppercased drive letter in the path can guarantee consistent behavior between debug calls. Or a user should resort to debugger; code to debug several script calls with a different case in the path.

cc @nodejs/v8-inspector ?

Activity

  1. vsemozhetbyt
    added
    windowsIssues and PRs related to the Windows platform.
    inspectorIssues and PRs related to the V8 inspector protocol.
    on Mar 10, 2018

  2. vsemozhetbyt commented on Mar 10, 2018

    @vsemozhetbyt
    vsemozhetbyt
    on Mar 10, 2018
    ContributorAuthor

    There is a more severe use case: the same issue makes breakpoints inactive in dependent files inside one debug session.

    1. Create two files:

    • test-script.js

      'use strict';

require('./test-lib.js');

console.log(3);

console.log(4);

    • test-lib.js

      'use strict';

console.log(1);

console.log(2);
    1. Run the test-script.js with lowercase drive letter:
    node --inspect-brk j:/temp/test-script.js

    1. Add a breakpoint in the dependent test-lib.js, run to completion. The breakpoint is not activated. Remove the breakpoint.

    2. Run the test-script.js with uppercase drive letter:

    node --inspect-brk J:/temp/test-script.js
    1. Add a breakpoint in the dependent test-lib.js, run to completion. The breakpoint is activated.

  3. vsemozhetbyt commented on Mar 10, 2018

    @vsemozhetbyt
    vsemozhetbyt
    on Mar 10, 2018
    ContributorAuthor

    Upstream issue: https://bugs.chromium.org/p/chromium/issues/detail?id=820728

  4. vsemozhetbyt
    changed the title [-]inspector: breakponts and case of script path argument[/-] [+]inspector: breakpoints and case of script path argument[/+] on Mar 10, 2018
  5. vsemozhetbyt
    changed the title [-]inspector: breakpoints and case of script path argument[/-] [+]inspector: breakpoints and letter case in script path argument[/+] on Mar 10, 2018

  6. hashseed commented on Mar 15, 2018

    @hashseed
    hashseed
    on Mar 15, 2018
    Member

    One way to fix this is to convert file names passed as script name to all lowercase for case insensitive file systems.

  7. jasnell commented on Jun 19, 2020

    @jasnell
    jasnell
    on Jun 19, 2020
    Member

    @nodejs/inspector ... is there anything actionable here?

  8. jasnell commented on Jun 25, 2020

    @jasnell
    jasnell
    on Jun 25, 2020
    Member

    Closing due to lack of activity. Can reopen if there's new information or someone wants to pick it up.

  9. jasnell
    closed this as completedon Jun 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    inspectorIssues and PRs related to the V8 inspector protocol.windowsIssues and PRs related to the Windows platform.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions