Multi threaded apps are now seeing a Stacktrace for each thread when stopping occurs

[pieandcakes]

Issue Type: Bug

Multithreaded app is now seeing a stacktrace request for each thread when a stopping event occurs, even when thread is not expanded in the callstack window. For a multithreaded app, this can be very expensive. This is a change in behavior from 1.30.2.

VS Code version: Code 1.31.0 (7c66f58, 2019-02-05T22:35:56.624Z)
OS version: Windows_NT x64 10.0.17763

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (8 x 3408)
GPU Status	2d_canvas: enabled checker_imaging: disabled_off flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: disabled_software rasterization: enabled surface_synchronization: enabled_on video_decode: enabled webgl: enabled webgl2: enabled
Memory (System)	31.92GB (10.88GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions (6)

Extension	Author (truncated)	Version
azure-account	ms-	0.8.0
cpptools	ms-	0.22.0-insiders
csharp	ms-	1.17.1
vscode-docker	Pet	0.5.2
azure-iot-edge	vsc	1.9.0
azure-iot-toolkit	vsc	2.2.0

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Multi threading debug in python (#67842)

[pieandcakes]

testapp.zip

• Compile app
• Add app args '-fThreading'
• Set a breakpoint on Threading.cpp:29
• Launch

Expected to stop at bp and only receive a stacktrace for the stopping thread. Actually getting a stack trace for all threads.

[pieandcakes]

Customer's scenario has 250 threads and has seen a spike in time it takes when debugging hits a breakpoint.

[pieandcakes]

@vscodebot that is not the same issue. Thanks

[isidorn]

@pieandcakes thanks for reporting this issue. However please note that I am pretty clueless when it comes to c++, so the following step "Compile app" is giving me issues.
I am trying to compile with g++ threading.cpp and I get a bunch of errors

Can you please give me nice steps so I can follow them step by step and get into this situation. Please note that I am on the mac.

Also can you reproduce with latest vscode insiders since I could not reproduce this issue if I emulated it using node debugging?

In file included from threading.cpp:1:
./threading.h:24:28: warning: in-class initialization of non-static data member is a C++11 extension [-Wc++11-extensions]
    int runningThreadCount = 0;
                           ^
threading.cpp:55:12: error: no matching constructor for initialization of 'std::__1::thread'
    thread A(ThreadLoop, this, 3, "A-Blue");
           ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/thread:408:9: note: candidate constructor template not viable: requires single argument '__f', but 4 arguments were provided
thread::thread(_Fp __f)
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/thread:289:5: note: candidate constructor not viable: requires 1 argument, but 4 were provided
    thread(const thread&);
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/thread:296:5: note: candidate constructor not viable: requires 0 arguments, but 4 were provided
    thread() _NOEXCEPT : __t_(_LIBCPP_NULL_THREAD) {}
    ^
threading.cpp:56:12: error: no matching constructor for initialization of 'std::__1::thread'
    thread B(ThreadLoop, this, 2, "B-Green");
           ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/thread:408:9: note: candidate constructor template not viable: requires single argument '__f', but 4 arguments were provided
thread::thread(_Fp __f)
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/thread:289:5: note: candidate constructor not viable: requires 1 argument, but 4 were provided
    thread(const thread&);
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/thread:296:5: note: candidate constructor not viable: requires 0 arguments, but 4 were provided
    thread() _NOEXCEPT : __t_(_LIBCPP_NULL_THREAD) {}
    ^
threading.cpp:57:12: error: no matching constructor for initialization of 'std::__1::thread'
    thread C(ThreadLoop, this, 0, "C-Orange");
           ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/thread:408:9: note: candidate constructor template not viable: requires single argument '__f', but 4 arguments were provided
thread::thread(_Fp __f)
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/thread:289:5: note: candidate constructor not viable: requires 1 argument, but 4 were provided
    thread(const thread&);
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/thread:296:5: note: candidate constructor not viable: requires 0 arguments, but 4 were provided
    thread() _NOEXCEPT : __t_(_LIBCPP_NULL_THREAD) {}
    ^
threading.cpp:58:12: error: no matching constructor for initialization of 'std::__1::thread'
    thread D(ThreadLoop, this, 1, "D-Red");
           ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/thread:408:9: note: candidate constructor template not viable: requires single argument '__f', but 4 arguments were provided
thread::thread(_Fp __f)
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/thread:289:5: note: candidate constructor not viable: requires 1 argument, but 4 were provided
    thread(const thread&);
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/thread:296:5: note: candidate constructor not viable: requires 0 arguments, but 4 were provided

[isidorn]

Thanks to @joaomoreno and @weinand I could compile
For future reference clang++ -g -std=c++11 *.cpp -o sink.out and "MIMode": "lldb" in launch.json

The issue here is that the Tree is calling getChildren on elements which are collapsed when refreshing the whole tree. Thus assigning this issue also to @joaomoreno

@pieandcakes please confirm that the actual issue here is that the collapsed threads are sending a stackTrace request. Collapsed threads should not send out any request. And that is the actual regression.

[pieandcakes]

@isidorn That is correct. We are getting a stackTrace request for all threads, including the collapsed ones, which seems to be a regression.

[joaomoreno]

The issue here is that the Tree is calling getChildren on elements which are collapsed when refreshing the whole tree. Thus assigning this issue also to @joaomoreno

@isidorn If you place the breakpoint here you'll notice that the call stack data source only gets asked to getChildren for the debug model and the active thread. The tree doesn't ask about the other, collapsed, threads.

[joaomoreno]

I was wrong. It is in the tree. I failed to press Continue once and notice all the stack traces expanded. Sorry @isidorn!

[isidorn]

I confirm this is behaving better with the fix.
However there is still this case which we will not cover in the endgame #69526
So bascially if a user manually collapses something we would still fetch children for that element.