How to debug OpenERP / Odoo properly? - debugging

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

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.

Problems debugging mserver5

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.

How to use the OpenEdge debugger (OpenEdge Debugger 11.6)

I'm working with OpenEdge Progress-4GL AppBuilder and Procedure Editor, and now I'd like to start working with the OpenEdge Debugger, release 11.6.
As found on quite some places on the internet, I've taken following actions to enable debugging of my Progress application:
Using Proenv, I've launched following command:
prodebugenable -enable-all
I get following response:
OpenEdge Release 11.6 as of Fri Oct 16 19:01:51 EDT 2015
==============================================================================
PROGRESS Debug Enabler
==============================================================================
Debugging is enabled for the Progress 4GL installed in
C:\PROGRE~1\OpenEdge.
For your information, some information on environment variables:
proenv>set DLC
DLC=C:\PROGRE~1\OpenEdge
proenv>set WRK
WRKDIR=C:\OPENED~1\WRK
proenv>set ENABLE_OPENEDGE_DEBUGGER
Environment variable ENABLE_OPENEDGE_DEBUGGER not defined
As far as my application is concerned, the application is based on a shortcut, which looks as follows:
C:\Progressx86\OpenEdge\bin\prowin32.exe
-basekey "INI"
-ininame c:\progress\our_application\progress.ini
-pf c:\progress\our_application\misc\run_our_application.pf
-p our_application.r
-rr
The file "run_our_application.pf" contains a list of entries, like the following:
-db our_DB
-H DC1
-N tcp
-S 6543
To the mentioned shortcut, I've added -debugReady 5001 in order to enable debugging, based on TCP portnumber 5001. When I launch the application, I get a warning message about this, and netstat -aon gives me following entry:
TCP 0.0.0.0:5001 0.0.0.0:0 LISTENING 11344
Where 11344 is confirmed as the prowin32 application.
In OpenEdge debugger, I've following entries in menu item "Edit", "Preferences", "Attachable":
C:\progress\our_application
Z:\Progress\our_application\PRG
C:\Progressx86\OpenEdge
For your information: The Z:-drive is an external server drive, Z:\Progress\our_application\PRG is the directory where files (*.w and *.p) get compiled into *.r files, the file our_application.r can be found there.
Nevertheless, when I open a *.w file and I go to the menu "Debug", the "Attach to Process" menu item stays disabled.
What can I do in order to debug my application/*.w file?
There are several ways of debugging. Start simple. You should be able to use any of the following:
from the procedure editor
Instead of selecting [ Compile / Run ], select [ Compile / Debug ]. The AVM will start executing the current file and the debugger will suspend execution on the first line.
from any alert-box
Add -debugalert to your startup parameters and every alert-box will display an additional 'Help' button. Clicking on it will show the stack-trace and a 'Debug' button. Clicking on that will start the debugger, execution is suspended at the line of the alert-box, this can be your own alert-box or an error.
stand-alone debugger
Start the debugger application (the Windows shortcut starts proDebugger.bat) and select [ Debug / Attach To Process... ] you can then either enter a PID or select a local running session (AVM).
remote attachable debugger
This is what you seem to be trying to setup - this allows you to attach the stand alone debugger (see option 3) to a process running on another machine, this can be useful when you have an AppServer or WebSpeed agent that you want to debug.
PDSOE debugger
Not relevant for you since you are not using Progress Developer Studio for OpenEdge, but just mentioning it for completeness. This allows adding break points in your source code by double clicking in the left margin and stepping through your source code instead stepping through a debug-listing.

Unable to start debugging on bash on Windows within Visual Studio Code

I have installed WSL(Ubuntu on Windows) and gcc/gdb, and open a directory in Visual Studio Code, then click Debug Menu | add configuration, select C/C++:(gdb) Bash on
Windows launch, press F5,get the message:
Unable to start debugging, Unable to establish a connection to GDB, ...
output in debug console:
Starting: "C:\Windows\sysnative\bash.exe" "/usr/bin/gdb --interpreter=mi"
"C:\Windows\sysnative\bash.exe" exited with code -1 (0xFFFFFFFF).
I don't have enough points to leave a comment, but could you paste your
configuration in launch.json? One issue I have seen is that "/usr/bin/gdb --interpreter=mi" gets treated as single string instead of calling gdb with an extra flag. Updating my configuration with the following flag in pipeArgs fixed the error for me.
"configurations": [
...,
"pipeTransport": {
"debuggerPath": "/usr/bin/gdb",
...
"pipeArgs"; ["-c"],
}
]

Resources