Problems debugging mserver5 - monetdb

I have recently started debugging the mserver5 application using vscode and a very comfy plugin for cmake called CMake Tools. Moreover, I am using gcc 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) as a compiler together with the following launch.json debug configuration for mserver5 in vscode:
{
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) mserver5 triangleDB",
"type": "cppdbg",
"request": "launch",
// Resolved by CMake Tools:
"program": "${command:cmake.launchTargetPath}",
"args": ["--dbpath=/home/mledl/dbfarm/triangleDB", "--set", "mapi_port=0"],
"stopAtEntry": false,
"cwd": "${workspaceFolder}/build",
"environment": [
{
// add the directory where our target was built to the PATHs
// it gets resolved by CMake Tools:
"name": "PATH",
"value": "$PATH:${command:cmake.launchTargetDirectory}"
},
],
"externalConsole": true,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
},
{ "description":"In this mode GDB will be attached to both processes after a call to fork() or vfork().",
"text": "-gdb-set detach-on-fork off",
"ignoreFailures": true
},
{ "description": "The new process is debugged after a fork. The parent process runs unimpeded.",
"text": "-gdb-set follow-fork-mode child",
"ignoreFailures": true
}
]
}
]
}
The database I am connecting to (here triangleDB) has been created within a dbfarm using the monetdb application and I am going to connect to it using the mclient application with the default username and password combination monetdb. I can successfully connect to and query my triangleDB when starting it using the monetdb application withing a running dbfarm.
When starting up the mserver5 for debugging from vscode using the above launch.json file and connecting to it using mclient and the monetdb user I cannot authenticate somehow and get the following error printed to the mserver5 logs:
client1: createExceptionInternal: !ERROR: InvalidCredentialsException:checkCredentials:invalid credentials for user 'monetdb'
Does anybody know why mserver5 cannot retrieve the default user? Does it rely on the deamon monetdbd to retrieve the user data from? Can someone tell me what I am missing or how I can efficiently debug the mserver5?
Another point is that I need to set mapi_port=0 in order to make mserver5 bind to available ports since it is opening two mapi connections somehow when debugging with vscode and CLion. The application crashes when using a specific port since the second binding attempt will be on an already use address. The following section shows that two connections are opened when debugging:
# MonetDB 5 server v11.40.0
# This is an unreleased version
# Serving database 'triangleDB', using 24 threads
# Compiled for x86_64-pc-linux-gnu/64bit with 128bit integers
# Found 31.349 GiB available main-memory of which we use 25.549 GiB
# Copyright (c) 1993 - July 2008 CWI.
# Copyright (c) August 2008 - 2021 MonetDB B.V., all rights reserved
# Visit https://www.monetdb.org/ for further information
# Listening for connection requests on mapi:monetdb://localhost:46093/
# Listening for connection requests on mapi:monetdb://localhost:40387/
Thanks in advance for everybody that can help me out on this one. Looking forward to hearing from you and sty safe everyone.

If your database was created using monetdb and you want to start it directly using mserver5, you need to tell mserver5 where the .vaultkey is.
In you dbfarm, do a grep monet_vault_key merovingian.log, copy the whole --set monet_vault_key=/<path-to>/dbfarm/demo/.vaultkey and add this option to the start-up command of your mserver5.

I am giving an additional answer here, because I want to make clear what I had to do in order to debug the mserver5 using vscode and interact with it using the mclient application.
While trying to figure out why certain modules/libraries could not be loaded, I noticed that the GDK kernel is missing an environment variable called monet_mod_path which can be set using the --set monet_mod_path=/usr/local/lib/monetdb5 option for mserver5. The missing monet_mod_path has also been the reason why mserver5 listened on two addresses for a mapi connection.
I am now using the following command to start mserver5 for debugging:
mserver5 --dbpath=/home/mledl/dbfarm/triangleDB --set monet_vault_key=/home/mledl/dbfarm/triangleDB/.vaultkey --set monet_mod_path=/usr/local/lib/monetdb5 --set gdk_nr_threads=24 --set max_clients=64 --set sql_optimizer=default_pipe
A minimal working configuration would be the following one:
mserver5 --dbpath=/path/to/your/db --set monet_vault_key=/path/to/your/db/.vaultkey --set monet_mod_path=/usr/local/lib/monetdb5
Note: I installed the application into default installation directory. If you choose a custom one the monet module path has the following pattern:
monet_mod_path=/path/to/install/lib/monetdb5
I hope this answer will help someone in the future and saves all the investigation time I had to put in.

Related

VSCode Go compilation blocked by antivirus

I am trying to work in VSCode 1.76.0-insiders on Windows 10 and what happens is that GO v1.20 compiler for some reason compile the application to temporary (?) folder - this action blocked by antivirus.
Could you suggest what settings I need to set in launch.json to compile into the same folder where source code is ?
Here is output of 'Debug console'
Starting: C:\Users\user01\go\bin\dlv.exe dap --only-same-user=false --listen=127.0.0.1:56552 from C:\projects\go.tfs-exporter
DAP server listening at: 127.0.0.1:56552
Build Error: go build -o C:\projects\go.app\__debug_bin.exe -gcflags all=-N -l .
tfs-exporter: go build go.app: open C:\Temp\go-build2738799206\b001\exe\a.out.exe: Access is denied. (exit status 1)
you see this strange folder: C:\Temp\go-build2738799206\b001\exe\a.out.exe ?? This is automatically blocked - no questions asked
here is my launch.json file:
{
"version": "0.2.0",
"configurations": [
{
"name": "Launch Package",
"type": "go",
"request": "launch",
"mode": "auto",
"program": "${workspaceFolder}",
"dlvFlags": [
"--only-same-user=false"
]
}
]
}
or any other suggestion on how to configure GO compiler with Antivirus in corporate environment ?
https://community.bitdefender.com/en/discussion/84185/false-positive-when-running-go-lang-program-edited-in-visual-studio-code
As advised here https://forum.golangbridge.org/t/bitdefender-detects-output-as-a-virus/22152/8 a "good" solution would be to add the environment variable GOTMPDIR with any path of your choice, where the builds are going to be stored. (Maybe reboot after this)
Then just go to BitDefender Protection -> Antivirus -> Settings -> Manage Exceptions and add your path as an exception.

User specified 'dlvLoadConfig' setting will be ignored by debug adapter 'dlv-dap'

When I launch in VSCode dlv debug, I get this message:
User specified 'dlvLoadConfig' setting will be ignored by debug
adapter 'dlv-dap'.
Source is Go Nightly extension.
have dlvLoadConfig config section already become unavailable (obsolete)?
launch.json :
"configurations": [
{
"name": "Application Server",
"type": "go",
"request": "launch",
"mode": "auto",
"program": "${workspaceFolder}/cmd/main.go",
"args": ["--config", "${workspaceFolder}/configuration/application.toml"],
"env": {
"CC":"/usr/bin/gcc",
"GOOS":"linux",
"GOARCH":"amd64",
"CGO_ENABLED":1
},
"dlvLoadConfig": {
"followPointers": true,
"maxVariableRecurse": 1,
"maxStringLen": 1024,
"maxArrayValues": 64,
"maxStructFields": -1
},
"trace": "log"
// "buildFlags": "-tags dev -ldflags '-X main.BuildDate=2021-04-28T19:38:16+03:00'"
}
]
You might need to update your configuration as mentioned here:
https://github.com/golang/vscode-go/blob/master/docs/debugging.md#switching-to-legacy-debug-adapter
https://github.com/golang/vscode-go/blob/master/docs/debugging.md
(from :https://github.com/golang/vscode-go/blob/master/docs/dlv-dap.md )
"go.delveConfig": {
"debugAdapter": "legacy",
}
On a side note, installing the latest didn't seem to copy the binary as dlv-dap (which seems to be expected by vscode) I just created a sym link to dlv (mac-osx), and it works in dlv-dap mode
ln -s dlv dlv-dap
Adding "debugAdapter" works for me too.
"debugAdapter": "legacy",
https://github.com/golang/vscode-go/blob/master/docs/debugging.md#settings
The new dlv-dap takes a completely different approach in loading data, so dlvLoadConfig is no longer necessary.
For string values, it uses 512 or 4K depending on the context as of Aug 2021. (512 for display in the VARIABLES section, 1K for function call results, 4K if you query the variables from the DEBUG CONSOLE or use COPY VALUE)
I noticed you were using maxStringLen: 1024 in your settings. We are currently considering to increase the limit of how much we show in the VARIABLES section. We are increasing this slowly and conservatively because it causes loading a lot of data for all variables automatically and it can slow down the debugging performance. If inspecting long string variables from DEBUG CONSOLE (on demand) is not sufficient, please open a new issue in the github.com/golang/vscode-go repo.

Starting a cmake-built application with administrative priviliges from Visual Studio 2019 on a remote Linux machine

Running IDE-Machine Windows 10 with Visual Studio 2019.
Target-System for debugging is a Ubuntu 18.04.
Using CMake available in Visual Stdio addons.
Test software is the same lib, with the simple_test program, which already leads to the issue (https://github.com/OpenEtherCATsociety/SOEM).
After passing the eth-interface to the built program, it stops with cause it can't get root.
Already tried to pass sudo in the launch.vs.json and also pipe sudo the program.
Tried to change the access to the security permission for the eth-device.
"configurations": [
{
"type": "cppdbg",
"name": "simple_test (test\\linux\\simple_test\\simple_test)",
"project": "CMakeLists.txt",
"projectTarget": "simple_test (test\\linux\\simple_test\\simple_test)",
... // standard setup
"args": [
"enp3s0" //the eth dev I want to use
],
... // standard setup
]
}
The result of the program without root is:
>SOEM (Simple Open EtherCAT Master)
>Simple test
>Starting simple test
>No socket connection on enp3s0
>Execute as root
expecting something like:
>>sudo ~/SOEM/test/linux/simple_test/simple_test enp3s0
>SOEM (Simple Open EtherCAT Master)
>Simple test
>Starting simple test
>ec_init on enp3s0 succeeded.
>2 slaves found and configured.
>Slaves mapped, state to SAFE_OP.
>segments : 1 : 2 0 0 0
>Request operational state for all slaves
>Calculated workcounter 3
>Operational state reached for all slaves.
>^Cocessdata cycle 320, WKC 3 , O: 00 I: 00 T:0
Suggestions about this would be helpful.
Thanks
Okay solved my problem.
You have to pass sudo to the debugger by adding sudo to "debuggerPath": "/usr/bin/gdb" like this:
"debuggerPath": "sudo /usr/bin/gdb"
Resolved for me.

Qt Release application with PSQL database - error on loading driver

With QtCreator (for version 57) I created simple application that connects to DB and waits for notifications. There isn't realy much code for it and all of it works on LINUX:
MyDataBase = new QSqlDatabase(QSqlDatabase::addDatabase("QPSQL", "Main"));
Unfortunetly after transitioning from Linux to Windows (on which app will by mainy used) I encounteredd some issues. As usuall, missign dlls, but those were quick fast (copy-paste given .dll). Now I can't run this still on Windows, because it refuses to connect to db. With system's variable I managed to find more. Now even when I see error I can't even grasp what else could I do to make it work:
Found metadata in lib C:/_Qt/5.7/mingw53_32/plugins/sqldrivers/qsqlpsqld.dll, metadata=
{
"IID": "org.qt-project.Qt.QSqlDriverFactoryInterface",
"MetaData": {
"Keys": [
"QPSQL7",
"QPSQL"
]
},
"className": "QPSQLDriverPlugin",
"debug": true,
"version": 329472
}
"The plugin 'C:/_Qt/5.7/mingw53_32/plugins/sqldrivers/qsqlpsqld.dll' uses incompatible Qt library. (Cannot mix debug and release libraries.)"
not a plugin
QFactoryLoader::QFactoryLoader() checking directory path "D:/QT_Notifi/build-Notifier-Desktop_Qt_5_7_0_MinGW_32bit-Release/release/sqldrivers" ...
loaded library "C:/_Qt/5.7/mingw53_32/plugins/sqldrivers/qsqlpsql.dll"
QLibraryPrivate::loadPlugin failed on "C:/_Qt/5.7/mingw53_32/plugins/sqldrivers/qsqlpsql.dll" : "Cannot load library C:\\_Qt\\5.7\\mingw53_32\\plugins\\sqldrivers\\qsqlpsql.dll: %1 is not correct application of Win32."
QSqlDatabase: QPSQL driver not loaded
QSqlDatabase: available drivers: QSQLITE QMYSQL QMYSQL3 QODBC QODBC3 QPSQL QPSQL7

How to debug OpenERP / Odoo properly?

I am using pdb.set_trace() as a breakpoint in my python function during Odoo development and I keep getting the log messages.
pdb.set_trace()
-> if s['confirm_state'] in ['draft','confirmed']:
(Pdb) 2015-04-05 05:40:12,794 9981 INFO vvm_odoo_new werkzeug: 127.0.0.1 - - [05/Apr/2015 05:40:12] "POST /longpolling/poll HTTP/1.1" 200 -
2015-04-05 05:40:47,769 9981 INFO vvm_odoo_new werkzeug: 127.0.0.1 - - [05/Apr/2015 05:40:47] "POST /longpolling/poll HTTP/1.1" 200 -
I first thought that it was because of the instant messaging feature and so I un-installed it. But I still keep getting this message.
This does not stop me from using the pdb stack trace but the problem here is that this terminal message keeps showing up in between the typing in the pdb trace point.
You can add the --logfile=<logfile> to the parameters when you launch Odoo - which will send standard Odoo log messages to that file, with the debugger log left nice and clean.
i.e. I have a bash script in /usr/local/bin which calls:
python /path/to/odoo/odoo.py --addons-path=/path/to/addons,/path/to/custom/addons "$#"
The $# tells the script to accept any additional params on the end, so when I call:
odoo --logfile=~/odoospam.log
I can debug nice and tidy.
Then if you want to check the log just tail -f ~/odoospam.log.
Still trying to figure out the best way to debug with pdb inside a docker container, will update this when I find a suitable way of doing it.
EDIT:
Found how to do so in docker (Kudos to https://stackoverflow.com/users/941605/jamey): Docker-compose and pdb
docker-compose run --service-ports odoo
I recommend you to install the Visual Studio Code to debug Odoo:
Visual Studio Code is a source code editor developed by Microsoft for Windows, Linux and macOS. It includes support for debugging, embedded Git control, syntax highlighting, intelligent code completion, snippets, and code refactoring. It is free and open-source, although the official download is under a proprietary license.
First, you need to install the Python Extension within VSCode. Then, if you want to start debugging you just need to click on the Debug button and click on the wheel on the top of the sidebar. The file launch.json will open and you just need to add this element to the bottom.
{
"name": "Python: Odoo",
"type": "python",
"request": "launch",
"stopOnEntry": false,
"pythonPath": "${config:python.pythonPath}",
"console": "externalTerminal",
"program": "/odoo_path/odoo.py",
"args": [
"--config=/odoo_config_path/.odoo_8.conf",
],
"cwd": "${workspaceRoot}",
"env": {},
"envFile": "${workspaceRoot}/.env",
"debugOptions": [
"WaitOnAbnormalExit",
"WaitOnNormalExit",
"RedirectOutput"
]
}
Once it is added you already can run Odoo under VSCode. For more information about the launch configurations click here
Now you can create breakpoint as usual. You can use the debugger console as well. And if you use the property: "console": "externalTerminal" as I did, you can show the log in an external console at the same time

Resources