I change my Hard drive and so I made a fresh Eclipse Corrosion install but I kept my Rust projets. Problem is I get an error when I launch my prog in debug mode. It seems to work in run mode but I didn't test this that much.
Error is
An internal error occurred during: "Launching my_prog".
Cannot read the array length because "launchConfigEnv" is null
Important note : it seems to be link with the use of an input file (debug configuration/common/input file)
I try many things, many installs, new projects, many, many things but nothing works (and I cannot figure out what launchConfigEnv is).
Any help welcome...
Edit : I install 2019.12 Eclipse and it works fine. I will work a little with this version and try out more configuration to shrink the problem.
As a workaround, add a single environment variable to the launch configuration, as follows:
Once that is done, re-launch it and it should work.
Note that in order to get rust debugging working in Eclipse I installed MSYS2 and the following MSYS2 packages.
pacman -S mingw-w64-x86_64-gcc
pacman -S mingw-w64-x86_64-gdb
pacman -S man
I followed some instructions in the Rust Corrosion Trouble Shooting guide to get a working GDB.
Reference: https://github.com/eclipse/corrosion/blob/master/documentation/Troubleshooting.md#debugging-on-windows
The Rust debugger command needs to be changed to rust-dbg.cmd, as follows:
However, the PATH environment wasn't working for me, so in the rust-gdb.cmd script I added this near the top:
SET PATH=%PATH%;F:\msys64\mingw64\bin;F:\Data\.cargo\bin
(Adjust as-per your installation of MSYS2 and Cargo/Rustup)
After which Eclipse was able to start a debug session and stop at a breakpoint.
Related
I cannot load or run my tests, from within VS Code.
I'm a new user to Elixir, and to VS Code. I'm running Lubuntu 21.10 (Impish). I've downloaded Erlang/OTP 25 (.deb), and Elixir 1.14 (precompiled binary in /usr/share/elixir), and can get anything I need running in a Bash terminal. Again, in a standard QTerminal window,
erl, iex, mix, elixir, etc. all work fine.
In VS Code, however, I get some errors. I feel stupid, but I'm coming from Sublime Text, so please forgive me.
In the left pane of VS Code, ExUnit shows an error (red):
Clicking on this error gives me this, on the bottom right pane. The command line options, passed to mix test, seem to be the default configuration:
This result is bizarre to me, because I can open the integrated terminal, execute /bin/sh, and then run the exact mix test line that's displayed:
/usr/share/elixir/bin has been added to my PATH variable, in ~/.bashrc, ~/.profile, and /etc/environment.
However, I am further confused by all tests being excluded, and wonder if there's some connection to the core issue:
Note that I can run my tests just fine, using different command line options. I've tried adding tags, but that didn't fix the problem.
I tried Google'ing this, and played around with my settings. Here is what I have configured in the "User" settings.json, and I made sure nothing overrides this in "Workspace" settings:
Changing the useNativeTesting setting doesn't solve the problem.
On another (?) note, I get a "failed to run elixir" upon VS Code startup:
Again, I have no problem running commands from a Linux terminal, or from a terminal within VS Code.
Plot twist: If I remove the precompiled Elixir 1.14, and downgrade to an older version, via apt, the problem goes away. But Lubuntu 21.10 doesn't offer Elixir 1.14, and I'm really into using the new dbg() feature.
But for now, I cannot load or run my tests, from within VS Code, apparently because Mix cannot be found.
Thanks to Daniel Imms, from the VS Code team, for answering my question on Twitter:
"Try moving where ever you init mix and elixir (.bashrc?) into your .bash_profile and then logging out and in again or restarting. I'm guessing it's in your bashrc which doesn't run in non-interactive sessions like in tasks."
When debugging a c++ app, and hitting a breakpoint, gdb terminates the debug session when I click on a variable to expand its content in the Variables panel.
The displayed message is: <terminated, exit value: 0>gdb (10.1.90.20210103)
Printing the variable from the Debugger Console works correctly.
Debugging was working OK some weeks ago. The major changes that happen recently was a debian upgrade from 10 to 11 (bullseye), and an upgrade of the Eclipse version.
Activating gdb traces following where can I find GDB traces, I could see the commands sent to GDB, but no particular error before GDB stopped.
Any idea of what could cause this issue?
Eclipse Version: 2021-12 (4.22.0), Build id: 20211202-1639 running on linux debian bullseye.
I answer my own question.
After checking related answers, I suspect that the problem is linked to stl pretty printing in Eclipse (which was working fine before). I tried different version of Eclipse and gdb, and finally managed to fix the issue by using a previous version of gdb (8.3 instead of 10.1).
Here is the procedure that I followed (I'm not sure all steps are mandatory).
Reinstalled eclipse from scratch
Deleted the .metadata directory and recreated the eclipse workspace
Downloaded version 8.3 of gdb sources, and compiled it with python support ('./configure --with-python'). Note that libgmp-dev and python2.7-dev debian packages must be installed.
Copied gdb-8.3 somewhere under /usr/local/
Updated eclipse preference settings : C-C++/Debug/GDB and change GDB Debugger to the pach where gdb 8.3 executable was located under /usr/local/.
Checked in Debugger Console that the right gdb version is displayed. If this is not the case, you may have to set gdb using Debug As.../Debug Configurations/Debugger/GDB Debugger
I am trying to set up the PHPCS plugin, but so far I am only getting this error:
phpcs: Unknown error ocurred. Please verify that /home/[user]/Documents/offprojects/vet_direct/vetsdirectapp/vendor/bin/phpcs --report=json -q --encoding=UTF-8 --error-severity=5 --warning-severity=5 --stdin-path=/home/[user]/Documents/offprojects/vet_direct/vetsdirectapp/app/Http/Controllers/JobController.php - returns a valid json object.
I followed the installation guide from the plugin page and installed PHPCS both globally and in the project. Also, the command in terminal shows this error:
zsh: command not found: phpcs
Any idea what is wrong here?
This might not help you, but for me, the executable path wasn't correct and the version of PHPCS didn't support PHP 7, it was still using PHP 5.
I'm going to assume you're on Linux based OS.
Since you have already installed PHPCS globally, access the phpcs file. This should be somewhere like ~/.config/composer/vendor/squizlabs/php_codesniffer/bin if you're on Debian based Linux OS (like Ubuntu Focal Fossa 20.04LTS). But it might differ depending on versions.
If you use a text editor to peek the phpcs file inside it (this will be the same on your Executable Path), it might say PHP 5, that's how I found I needed to upgrade mine.
To upgrade your PHPCS do composer global require "squizlabs/php_codesniffer=*" this might fix your issue. After that, you might need to fix your Executable Path again, I had to do mine.
To edit the executable path on Visual Studio Code Command + , (or go to settings) then search for PHP CodeSniffer. Go down to Executable Path and make sure it's correct.
This might not work, but it's worth a try.
After trying a lof of different things, this is what worked for me. I'm on a Mac and using Zsh.
First, installed PHP Code Sniffer (phpcs) with Composer, as Hugo suggested on the answer above:
composer global require "squizlabs/php_codesniffer=*"
But then, I had to edit my .zshrc and added this line:
export PATH=/Users/YOURUSER/.composer/vendor/bin:$PATH
After that, close the Terminal and I was able to run phpcs -h
In my case an error was being thrown by various processes "Could not load xdebug because it is already loaded". This did not show in VSCode, but did if I ran php -v or php --ini.
This is what cleared the error for me:
Edit the /etc/php/8.0/apache2/conf.d/xdebug.ini file and comment out the line zend_extension=xdebug.so. Restart apache with sudo systemctl restart apache2, then try php -v. The "Could not load xdebug because it is already loaded" error should be gone. Restart VSCode and this phpcs error should stop showing.
I have VSCode configured to debug php and have the xdebug configuration settings in both the etc/php/php8.0/apache2/php.ini and etc/php/php/8.0/cli/php.ini files.
How I discovered this is I downloaded the source code and searched for where that error was being thrown. What I found was that ANY error in stderr outside of a very narrow range gets this error message. I had noticed this error showing in my terminal, and I researched how to clear it. When I did, the VSCode phpcs error went away!
On Windows:
Open the XAMPP Control Panel.
Apache -> Config -> php.ini
Search for zend_extension=xdebug.so or something the like and delete it.
Restart Apache.
Try again.
In my case, It was happening due to XDebug and resolved after disabling xdebug from Xampp.
Goto C:\xampp\php\php.ini
find and disable (add ;) before following lines
Change :
xdebug.mode=debug
xdebug.start_with_request=yes
zend_extension = "C:\xampp\php\ext\php_xdebug.dll"
to :
;xdebug.mode=debug
;xdebug.start_with_request=yes
;zend_extension = "C:\xampp\php\ext\php_xdebug.dll"
Restart Apache and then vscode. It should fix that.
I've seen some other stakoverflow question like this one:
CLion Installation: Cmake compilers not found, GDB not found
But it's not quite the same problem.
My problem is that only my gdb.exe is not found by Clion. I can compile and run programs without problem, but when i need to debug the program tell me that only the debbuger is incorrect.
The problem is that my gbd.exe is present in my cygwin/bin folder
and i have it also in my PATH (system variable)
What i've done so far:
delete, shutdown and reinstall cygwin from scratch.
Install Netbeans and try to run with cygwin config (and debugger) -> everthing is working and i can debug my program. I also try to select it manualy.
So the real question is why Clion think my gdb is not present?
An how can i make it work?
Thank you for your help
Try to install GDB version 7.10.1
My settings:
Short answer: check what versions of gcc, g++ and gdb you have installed. They should be of the same major version.
Long answer:
Try to launch gdb.exe from cygwin terminal. You will probably get something like this (I'm using mingw64 from msys2 so folder will be different):
$ gdb
C:/msys64/mingw64/bin/gdb.exe: error while loading shared libraries: libgcc_s_seh-1.dll:
cannot open shared object file: No such file or directory
But you have gcc installed so you will have this DLL inside C:/msys64/mingw64/bin (in your case folder is different). The problem is that your gdb and gcc are of different major versions. I got this problem when installed mingw-w64-x86_64-gcc-7.3.0-2 with mingw-w64-x86_64-gdb-8.2.1-1. That's why gdb was not able to launch and CLion was not able to check GDB version thus outputting "Not found" error.
If this is the case - remove gdb and install it again. Now with correct major version (same as gcc). Since you're using cygwin, launch cygwin setup again, search for gdb package (don't forget to change view to full) and change version to be the same as gcc. Or, alternatively, you can change gcc version to be the same as gdb (in my case this wasn't possible).
This problem has been brought up a few times and I tried every suggested solution, but nothing helped.
What I have is a native module in a VS code extension. This works very well on Linux + Mac, but I cannot get it to load on Windows 10. Every time the extension is activated and tries to load the native module I get this error. What makes this so strange is that the native module works beautifully in a node session (in a Win command line). I checked what NodeJS version Visual Studio Code uses and installed exactly this version (x86, as vscode is still 32bit). I did an npm install npm -g, ran npm rebuild as well as normal node-gyp rebuild in my extension folder (or node module folder for node-gyp). Every time the module is built fine and works in a node session. Still I cannot get it to work in vscode. So I believe it must be something that has to do with the vscode app on Windows, just don't know what it is. For compilation I tried both VS 2013 and VS 2015.
Interesting here is also how node-gyp compiles the native module on Windows. It appears as if it uses a number of hacks, e.g. the compiled module crashs hard when using std::throw_with_nested (a C++11 feature). Another problem is the win_delay_load_hook.cc file, which contains a hack to make some weird situation work (this init fails on Win 10, so I had to disable that, this is a general DLL init problem not related to the vscode init). So it could well be it's just node-gyp on Win10 which is causing all the trouble. Yet, as I wrote, the native module works nicely in a node session.
What else could I do to find out what exactly is the problem? Is there a log file that shows exactly why the registration is not right? Is there a problem with vscode in general, on Windows 10?