Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Couldn't make executionWrapper to work #361

Closed
5 tasks done
are-scenic opened this issue Sep 23, 2022 · 9 comments
Closed
5 tasks done

Couldn't make executionWrapper to work #361

are-scenic opened this issue Sep 23, 2022 · 9 comments
Labels
question Further information is requested

Comments

@are-scenic
Copy link

are-scenic commented Sep 23, 2022

Checklist

  • The issue is about this extension and NOT about a fork.
  • Check the known issues list.
  • The latest version of the extension was used.
  • It is not related to remote-vscode or I checked the following issue
  • Imagine yourself into my position and think how hard to debug the issue without insufficient information.
    I understand that you have privacy concerns and I expect you to understand that this extension is developed for free.
    Thanks.

Describe the bug

I test the code that is supposed to run under the root privileges. Moreover, I do use remote to debug, but this is not the failure I see in the ticket #201 that is mentioned above. The problem is that the executionWrapper doesn't work for me. The configuration is as follows:

    "testMate.cpp.test.advancedExecutables": [ 
        {
            "name" : "gtest",
            "pattern": "**/gtest",
            "executionWrapper": {
                "path": "sudo",
                "args": [ "${argsFlat}", "-d", "5" ]
            },
        }
    ],

My gtest executable was added to NOPASSWD list in the sudoers files for my account. I've tested the command by manually running it from the command line and it worked. It ran without asking for the password. Moreover, the Test-Explorer shows the list of the tests correctly. But when I request to run a test, in the output window I see that it shows that sudo wasn't called and even other argument specified about (i.e. "-d", "5") do not appear:

$12│ ❌ Executable run is finished with error.$12│ "~/github/project/tests/googletest/gtest"" "--gtest_color=no"" "--gtest_filter=<here is a long list of the selected group of tests"" "--gtest_also_run_disabled_tests""$12│ ❗️ Test has ended unexpectedly: Signal received: SIGSEGV

As you can see neiter sudo nor extra arguments appear there. I also tried to replace in the settings the line "args": [ "${argsFlat}", "-d", "5" ] with "args": [ "${cmd}", "${argsFlat}", "-d", "5" ], which made it only worse. In the latter configuration even Test Explorer shows nothing.

To Reproduce

To reproduce the failure I believe you need the following:

  1. Create a VM with Ubuntu (I am using 20.04)
  2. Set the configurations to allow SSH connection to the VM from the Windows machine
  3. Create a directory on a drive of this VM and place there a simple c++ hello world with google tests and dummy tests
  4. From a Windows Machine open VSCode
  5. Install Remote Development extension pack
  6. Use Command Palette to invoke "Remote-SSH: Connect to Host ..."
  7. Install "C++ TestMate" and configure the setting as specified above.
  8. Compile the program with the tests and try to issue the unit-tests

Desktop

  • Extension Version: v4.3.0
  • VS Code Version: 1.71.2
  • Google Test: Unfortunately, I don't know; I only know that it came after 2017 at least (if not later)
  • OS Type and Version: Windows 11
  • Using remote-ssh/docker/wsl?: Remote-SSH to a server running Ubuntu Server 20.04

Regression bug?

I tried even with C++ TestMate Legacy. There results even worse, I have no idea how to get the logs of the failure.

  • Last extension version in which the feature were working: Never seen it working

Log (optional but recommended)

I have the only log that I mentioned above.

Thank you,
Arseniy

@matepek
Copy link
Owner

matepek commented Sep 25, 2022

output window I see that it shows that sudo wasn't called and even other argument specified about (i.e. "-d", "5") do not appear

that line is not a precise error text. It doesn't mean that sudo won't be used.

Please attach logs in the way described by support page

@matepek
Copy link
Owner

matepek commented Sep 25, 2022

btw, wouldn't be chown a better approach? (you would need to re-set after every compilation though)

@matepek matepek added the question Further information is requested label Sep 25, 2022
@are-scenic
Copy link
Author

output window I see that it shows that sudo wasn't called and even other argument specified about (i.e. "-d", "5") do not appear

that line is not a precise error text. It doesn't mean that sudo won't be used.

Please attach logs in the way described by support page

@matepek , thank you so much for your response. I'll do my best to prepare the logs.

And it goes without saying, THANK YOU so much for this amazing extension. I really hope I will make it work for my case. 🙏

@are-scenic
Copy link
Author

btw, wouldn't be chown a better approach? (you would need to re-set after every compilation though)

@matepek, I am not sure I fully understand your advise here. Do you mean to chown the compiled binary?
Actually, it's a great idea.
I'll see how I can seamlessly weave it into the process. The problem is in as you said a need to chown it after each compilation.

@matepek
Copy link
Owner

matepek commented Sep 26, 2022

I meant SUID.

A way it could be that

  • there is a helper script like set_chown_for_tests.sh which script can run as root also (because it is mchown) and
  • that script could run chown on the binary if you make it part of the build process.

This way, you just have to do 1 chown for the script when you init your repo locally and after it should work. (in theory)

This ulimit might interesting too.

@are-scenic
Copy link
Author

Owner

Thank you for the advise. Regarding chown-ing the script, as far as I know, SUID is ignored for script files as it was discovered as a security breach some time ago. But, still it's a great idea, since I can create a small executable that does the same.

Regarding the idea of ulimit, please don't think of me as of stupid or something, but I didn't understand how I can use it. Perhaps, my knowledge of this command is quite poor.

@are-scenic
Copy link
Author

are-scenic commented Sep 26, 2022

Here is the log cpp_mate_log.txt.
I've isolated a single attempt of running a single test. I hope it helps.

@are-scenic
Copy link
Author

Hi @matepek, I've tried your idea with SETUID and it works great. Thank you. Now I finally can run and debug conveniently the code, without using sudo as an execution-wrapper.

However, I have encountered another issue. Some tests in our test-suite are running on HW, and as such cannot run simultaneously. Following the guidelines of the documentation I added the following settings to my settings.json to ensure no parallelism and infinite time of execution:

    "testMate.cpp.test.parallelExecutionLimit": 1,
    "testMate.cpp.test.parallelExecutionOfExecutableLimit": 1,
    "testMate.cpp.test.runtimeLimit": 0,

When I run the tests from the command line manually, the tests are passing without an issue.
When I run it from the VSCODE each test-suite independently, the tests of each test-suite pass perfectly.
However, if I request to run them all, the tests start colliding and start failing.
Is there something in the settings that I should configure more? Am I missing something?

Thank you,
Arseniy

@matepek
Copy link
Owner

matepek commented Sep 28, 2022

Happy to hear that the main problem is solved.

Regarding to the parallelism.
I'm afraid you did set the settings right...

One possible explanation could be that your tests depending on each other in an ordered way.
The extension has its own ordering an it will run the tests in that order. Try to run your executable a couple of times from command lines with shuffling. If it fails that would mean that the issue is probably in your code not in the extension.
If succeeds fine like 10 times then it likely the extensions fault.

In that case please open a new issue with log attached and I will look into it. (or you can try to read it too, not too complicated)

@matepek matepek closed this as completed Sep 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants