Forum > Networking and Web Programming
[SOLVED] how to debug a CGI from Lazarus
Martin_fr:
--- Quote from: nomorelogic on December 12, 2023, 01:27:17 pm ---
--- Quote from: Martin_fr on December 07, 2023, 11:29:31 pm ---That will work in a shell. But if the IDE (the debugger) starts the exe, then shell stuff doesn't happen.
--- End quote ---
question:
is it for the same reason that if I use the REQUEST_METHOD environment variable set to GET, the debugger works correctly
whereas if I set it to POST it crashes on the Run statement?
--- End quote ---
Not sure about your question.
First of all, what crashes, the debugger or your app in the debugger?
But anyway, about the differences between running outside or inside the IDE (or inside an http server)
If you give a shell the command-line
--- Code: Text [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---./myapp --data=~/data.txt >/tmp/log.txt
The shell will translate this. The shell will replace ~ with your home dir.
The shell will open the file /tmp/log.txt and set stdout to it.
Your app gets executed with the param "--data=/home/username/data.txt" and it gets a handle for stdout.
The http server also set stdout, and it does set additional environment.
---
The debugger does not translate "~".
And the debugger does not set stdout/stdin
The only thing the debugger currently does is set environment, if you specify it.
--- Quote ---follow example code
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---#!/usr/bin/instantfpcprogram TestCgi;
--- End quote ---
"instantfpc" doesn't matter to the debugger => you must have compiled the code, or set up the IDE to have it compiled before the debugger starts.
Another difference here.
A shell will look into the file, and recognize it starts with #!.
The shell will then call
/usr/bin/instantfpc the_file
The debugger will not do that. It expects an executable binary (with machine code in it).
Actually about stdin/stdout
Go to Tools > Options > Debugger > Backend
and choose "Gdb GNU debugger"
==> I think this should set up your stdin, if in "run parameters" you specify " <somefile "
What is planned....
* stdin/stdout
There is an open issue, and plans to implement stdin/stdout redirection to work with FpDebug.
That does not include piping between commands like "echo 123 | yourapp"
* ~ (and others)
Not planned (Though the ~ would be trivial)
* #!
Not planned
At least not from the debuggers perspective. If someone implements that on the IDE side, so it would be done before the debugger gets involved, .... But I have no knowledge that anyone is looking at it.
nomorelogic:
thank you for your attention and answers
really appreciated
regarding what I called "crash" above:
Lazarus debugging works fine with InstantFpc projects: it simply ignores the initial shebang and then treats the project like any pascal project.
However, when I set REQUEST_METHOD = POST (or PUT) in the environment variables and proceed with debugging, when execution is paused on the 'Run' instruction (line 75 of the code above) and I then proceed with 'Step Into' or 'Step Over', the debugger and the IDE freeze and control will not return until the debugger is stopped manually.
I get the idea that at that moment the debugger waits for input that will never arrive. Of course, I do not know if this impression is correct.
On the other hand, when I start the debugger with REQUEST_METHOD = GET, I don't encounter any problems: everything works perfectly.
As soon as possible I will try "Gdb GNU debugger" as suggested.
Thanks again.
MarkMLl:
--- Quote from: nomorelogic on December 13, 2023, 09:32:10 am ---As soon as possible I will try "Gdb GNU debugger" as suggested.
--- End quote ---
Note that Martin specifically suggested the *Remote* debugger. I've used this in the past for various things, but there's a bit of a question mark over it now that the IDE is moving to fpDebug.
Alternatively, have you tried starting your program as normal and then getting the IDE to attach the debugger to it?
What OS etc. are you running? To what extent does the web server require elevated privilege?
MarkMLl
Martin_fr:
--- Quote from: MarkMLl on December 13, 2023, 10:37:40 am ---
--- Quote from: nomorelogic on December 13, 2023, 09:32:10 am ---As soon as possible I will try "Gdb GNU debugger" as suggested.
--- End quote ---
Note that Martin specifically suggested the *Remote* debugger. I've used this in the past for various things, but there's a bit of a question mark over it now that the IDE is moving to fpDebug.
--- End quote ---
With regards to setting a redirected stdin => the normal gdb debugger should be enough. (at least with the gdb version I tested on Windows.
Martin_fr:
As MarkMLI asked: What OS are you using?
--- Quote from: nomorelogic on December 13, 2023, 09:32:10 am ---regarding what I called "crash" above:
Lazarus debugging works fine with InstantFpc projects: it simply ignores the initial shebang and then treats the project like any pascal project.
However, when I set REQUEST_METHOD = POST (or PUT) in the environment variables and proceed with debugging, when execution is paused on the 'Run' instruction (line 75 of the code above) and I then proceed with 'Step Into' or 'Step Over', the debugger and the IDE freeze and control will not return until the debugger is stopped manually.
I get the idea that at that moment the debugger waits for input that will never arrive. Of course, I do not know if this impression is correct.
--- End quote ---
To me "the IDE freeze" would mean that you can't even move the caret in the source editor anymore. You can't use any menus, and do nothing with the IDE?
Because I just tested your project, and my IDE kept working (then again, I am using the latest version 3.99 / but 3.0 RC should be the same)
As for the app, yes it waits forever. The CGI will want to read the STDIN until EOF. But its connected to the "View > Debug Windows > Console in/output", which delivers keystrokes from the keyboard (if focused). And which never gets to EOL.
Hence yes, your CGI app will wait forever.
But I also checked: Using "gdb" I could supply a command line ("run parameters"): </home/name/somefile.txt
And then your app would process it, and print some html.
Mind that I entered </home/name and not <~/somefile => because ~ will not work.
Navigation
[0] Message Index
[#] Next page
[*] Previous page