* * *

Author Topic: CGI debugging  (Read 11044 times)

Gys

  • New member
  • *
  • Posts: 7
CGI debugging
« on: September 03, 2013, 04:29:00 am »
Hello

I am trying to debug a fcl-web CGI application with Windows 8.1 (preview) and Lazarus 1.0.10.

On http://wiki.lazarus.freepascal.org/CGI_Web_Programming is a unit shown that should enable debugging with dbg. So I created that unit and added it to the project. The resulting application is an .exe file that is called from Apache 2.2 as a CGI bin file. Without the cgidebug.pas unit my test application works fine. But when I add cgidebug then the application hangs (returns no data to the browser).

The source of cgidebug states: 'if the program to debug is running as a service (e.g. CGI application from Apache running as a service) , make sure the service is configured with "Interact with desktop" checked. Failing to do so, the debugger will be started without a console, break the program and hang waiting for input. Killing the debugger is your only option'.

Well killing the dbg process is indeed the only option. However, my app is not a service, so this should not apply ? And anyway, I have looked through all the project options, but I do not see a 'Interact with desktop' option ?

What did I miss ?!



ludob

  • Hero Member
  • *****
  • Posts: 1173
Re: CGI debugging
« Reply #1 on: September 03, 2013, 08:44:07 am »
The comment says "CGI application from Apache running as a service". The important part here is "Apache running as a service". Apache will spawn your cgi application but since there is no handle to the desktop it can't pass that handle to your application. So the "Interact with desktop" should be set for Apache, not for your application.

I don't have Win8 but in older versions you would find the "Interact with desktop" checkbox in the service configuration panel. From memory: Control Panel/Administrative Tools/Services , right click on the apache service and then properties. The "Interact with desktop" is considered as "legacy" starting from Vista because of the security implications.  So I'm not sure if it is still there in Win8.1 or if it is still as apparent as it was before. One more reason to stick to XP as a developer  ;)

Gys

  • New member
  • *
  • Posts: 7
Re: CGI debugging
« Reply #2 on: September 03, 2013, 03:47:17 pm »
The 'interact with desktop' option is still there. So one less reason to stick with the old stuff  ;)

However this did not solve the problem...

If I run the test project with CGIDebug included, then the browser receives no response and I have to kill the dbg process to break off the test project. So the CGIDebug unit does work in one way: it starts the dbg. But somehow the dbg still does not get through to the desktop ?

I assumed therefore something is wrong with the constructed commandline:
AProcess.CommandLine := format('cmd /C START "Debugging %s" /WAIT "%s" "%s" "%d"',[paramstr(0),debugger,paramstr(0),GetProcessID]);

I added some code to write the resulting commandline to a file and executed that manually from the system prompt. That gave an error that indicated dbg did not know what to do with the number (the process id). So I changed "%d" to --pid=%d:
AProcess.CommandLine := format('cmd /C START "Debugging %s" /WAIT "%s" "%s" --pid=%d',[paramstr(0),debugger,paramstr(0),GetProcessID]);

This are my latest findings:
Code: [Select]
C:\Users\Gijs>"C:\lazarus\mingw\bin\gdb.exe" "C:\Users\Gys\Documents\Projects_Lazarus\Test_fclweb\cgiproject1.exe" --pid=3676
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from C:\Users\Gys\Documents\Projects_Lazarus\Test_fclweb\cgiproject1.exe...Reading symbols from C:\Users\Gys\Documents\Projects_Lazarus\Test_fclweb\cgiproject1.dbg...done.
done.
Can't attach to process.
(gdb)

So I still have two problems:
1) The dbg seems unable to attach to the process.
2) This message comes from executing the command manually - there is still no terminal window visible.

What could be wrong ?

ludob

  • Hero Member
  • *****
  • Posts: 1173
Re: CGI debugging
« Reply #3 on: September 03, 2013, 06:59:08 pm »
When you start your app from explorer or command line,  the debugger should also open and break at the sleep instruction. Test this before trying it with Apache.

The process ID is the id of your application. So when you execute the commandline you saved in the file, the process is long gone.

Quote
If I run the test project with CGIDebug included, then the browser receives no response and I have to kill the dbg process to break off the test project. So the CGIDebug unit does work in one way: it starts the dbg. But somehow the dbg still does not get through to the desktop ?
That is probably the right conclusion.  There are definitely some changes in how the "interact with desktop" works. See for example here: http://technet.microsoft.com/en-us/library/cc756339(WS.10).aspx. Look at the event logs to see if Windows doesn't log the message referred to in that link when starting Apache.
This one http://social.technet.microsoft.com/Forums/windowsserver/en-US/f2f702c3-85fc-4b80-a302-3ea4f7ab1258/interactive-services suggests that the "interact with desktop" is there but just ignored.
Google for "However, the system is configured to not allow interactive services. This service may not function properly." and there are 53000 hits. You are in good company there, all regretting the old stuff  ;)

Gys

  • New member
  • *
  • Posts: 7
Re: CGI debugging
« Reply #4 on: September 03, 2013, 07:46:20 pm »
Thank you for the info.

I did realize the pid is only valid while running, so I kept the process running. But seems that was not enough, because...

Good remark about running from the commandline: indeed then the dbg is correctly shown in a separate window. And it connects correctly to the cgi app. Great !

Your other links gave a lot of less cheerful info:
Windows also has an overall 'interact with desktop' - setting:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683502(v=vs.85).aspx
In Win 8.x this option defaults to being off, so I set it on.
But now all applications running in 'session id 0' mode cannot not ever be interactive in any way. An improvement over the early days, according to Microsoft... (so much for running at the front of the Windows pack with 8.x....)
I checked (run 'tasklist' at dos prompt) and indeed apache, cgitest.exe and dbg.exe all run in session id 0 - mode :-( Meaning what I want is impossible.

So my conclusion, its not possible anymore to use dbg for this way of debugging for Windows cgi executables.

ludob

  • Hero Member
  • *****
  • Posts: 1173
Re: CGI debugging
« Reply #5 on: September 03, 2013, 08:17:08 pm »
Quote
I did realize the pid is only valid while running, so I kept the process running. But seems that was not enough, because...
Because you can have only one debugger attaching to a process. Remember, your process hung because it stopped at a breakpoint set by the debugger launched by itself.

Quote
So my conclusion, its not possible anymore to use dbg for this way of debugging for Windows cgi executables.
A clumsy alternative is that you write the full gdb command line to a log file like you did before. Then start a while fileexists(logfile) loop with a short sleep. From the command line, as soon as you see the file appear, run the command line stored in the log file to attach to the process. There is no hurry, the cgi app will wait as long as needed. When the debugger is attached, delete the logfile in explorer or another console, to get out of your cgi loop.

Gys

  • New member
  • *
  • Posts: 7
Re: CGI debugging
« Reply #6 on: September 04, 2013, 04:25:49 am »
That might be an option: I could even write a small app that waits for the file, reads it, starts the dbg with that commandline and then deletes the log file.

But I read that fcgi might be a better option. Its faster in production and in a some setups a fcgi app can be run from within Lazarus and therefore be debugged from there. Sounds as a good alternative:
mod_fcgi as described in http://forum.lazarus.freepascal.org/index.php/topic,13312.0.html

However, I could not yet get it to work... If that does not change I will have to post another question...

Graeme

  • Hero Member
  • *****
  • Posts: 1414
    • Graeme on the web
Re: CGI debugging
« Reply #7 on: September 26, 2013, 12:37:07 pm »
I am trying to debug a fcl-web CGI application with Windows 8.1 (preview) and Lazarus 1.0.10.

There are a few options...
1) Use the 'dbugintf' unit inside your CGI app. Then use the SendDebug() procedure to send debug information. Use the console (included with FPC) or GUI (included with Lazarus) Debug Server applications to listen to the debug messages.

2) Use tiOPF's tiLog unit. You can log to a file and monitor the output.

3) Do what the Delphi developers do. Debug within the IDE, using GDB. Create a infinite loop at the beginning of your CGI app as follows:
Code: [Select]
var
  lDebug: integer;
begin
  lDebug := 1;
  while lDebug = 1 do
  begin
    // do nothing
  end;
  lDebug := 0;

  // rest of your CGI app code here

Execute the CGI app via your web browser. Now use Lazarus (actually GDB) to attach to the process ID. This will automatically pause your CGI application. For some reason GDB switches to other threads if they exist. Make sure you are debugging Thread 1. Set a breakpoint on the 'while ... do' line. Run your app again via Lazarus IDE. Now modify the lDebug value to 0, or change the EIP register to jump over the while statement. Then continue to step your CGI application like any other GUI application.

Hope this helps.
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

apexcol

  • New member
  • *
  • Posts: 23
Re: CGI debugging
« Reply #8 on: June 23, 2017, 11:57:03 am »


I am trying to debug a fcl-web CGI application with Windows 8.1 (preview) and Lazarus 1.0.10.

There are a few options...
1) Use the 'dbugintf' unit inside your CGI app. Then use the SendDebug() procedure to send debug information. Use the console (included with FPC) or GUI (included with Lazarus) Debug Server applications to listen to the debug messages.

2) Use tiOPF's tiLog unit. You can log to a file and monitor the output.

3) Do what the Delphi developers do. Debug within the IDE, using GDB. Create a infinite loop at the beginning of your CGI app as follows:
Code: [Select]
var
  lDebug: integer;
begin
  lDebug := 1;
  while lDebug = 1 do
  begin
    // do nothing
  end;
  lDebug := 0;

  // rest of your CGI app code here

Execute the CGI app via your web browser. Now use Lazarus (actually GDB) to attach to the process ID. This will automatically pause your CGI application. For some reason GDB switches to other threads if they exist. Make sure you are debugging Thread 1. Set a breakpoint on the 'while ... do' line. Run your app again via Lazarus IDE. Now modify the lDebug value to 0, or change the EIP register to jump over the while statement. Then continue to step your CGI application like any other GUI application.

Hope this helps.
Great Job, on Linux the only detail is that you have to start Lazarus as root...

 

Recent

Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus