09 Dec, 2009, Idealiad wrote in the 1st comment:
Votes: 0
I've done some searching on this issue and I'm not finding much advice (relevant to my particular situation), troubleshooting a CGI compiled from C.

I found a project on Google code that I want to test (a browser-based interactive fiction game player). It uses a server CGI compiled from C and an ajax-based client in the browser. The project is here: http://code.google.com/p/iffy/.

I followed the install instructions, but it seems like the CGI doesn't work (the server just isn't serving the game). I don't really know how to troubleshoot this as there's no error or log messages I can look at to see what may be going wrong. I'm pretty sure the CGI is executable by the webserver as I've chmod'ed permissions, and Zeno the site admin set up a cgi-bin to run the CGI from.

I can alter the CGI source, but I don't really know where to start. Is there any way to enable some kind of debugging on this thing? Any pointers?
09 Dec, 2009, quixadhal wrote in the 2nd comment:
Votes: 0
The only thing CGI does differently than a "normal" program is that it works like a daemon. That is, typically you can't rely on stdin, stdout, or stderr going anywhere (they may be logged, or they may go into a void). Also, your environment will be that of the web server, and your permissions may be more limited (can't malloc too much, can't fork, can't write the file filesystem).

If you're allowed to write to files and are not chroot'd, you could make an empty logfile in your directory and have it log things to that.
09 Dec, 2009, David Haley wrote in the 3rd comment:
Votes: 0
CGI doesn't necessarily work like a daemon; a standard perl/php setup for example will invoke the interpreter as a fresh process on each invocation.

The first thing I'd do is figure out if you're running as a daemon or invoked each time. Well, I suppose you need to figure out if the process is starting in the first place! You could add some kind of sleep-for-1000-seconds to the source, and then try to access it over CGI and see if it appears in the process list. If it's not even starting up, you know at least where to start.

Normally things should be in /var/log/httpd/error.log (or /var/log/apache2/error.log, or somewhere else, depending on your webserver and Linux distribution). Unfortunately for you, those are typically root-only, so you might need help from Zeno in seeing what's going on.

If you can, I would set up a VM at home that replicates Zeno's environment as closely as possible (Linux distro and web server) and see if you can get it working there. It'll be easier to debug if you have full access to logs etc.
09 Dec, 2009, Zeno wrote in the 4th comment:
Votes: 0
Can you try a CGI that you know works? Maybe I didn't config your cgi-bin alias right. :P
09 Dec, 2009, Idealiad wrote in the 5th comment:
Votes: 0
Thanks for the suggestions guys.

I've looked up a few cgi tutorials and tried getting a simple hello world going to see if I was able to run things from cgi-bin in the first place. However this isn't working – here's what I did.

1. Wrote a simple hello world:

#include <stdio.h>
int main(void) {
printf("Content-Type: text/plain;charset=us-ascii\n\n");
printf("Hello world\n\n");
return 0;
}


2. Uploaded it to the server, put it in cgi-bin, and ran:

gcc -o hello_cgi.cgi hello_cgi.c


3. Set permissions with chmod 755 hello_cgi.cgi, double checked these in WinSCP and this looked OK.

4. In the shell, did 'hello_cgi.cgi', and got the expected output:

matingball@zeno:~/public_html/cgi-bin$ hello_cgi.cgi
Content-Type: text/plain;charset=us-ascii

Hello world


5. But, when I went to the address in my browser, got a 403 Forbidden error.


Does this mean the cgi-bin permissions are wrong somehow? I checked cgi-bin and it's r+x by everyone.
09 Dec, 2009, David Haley wrote in the 6th comment:
Votes: 0
It could be that the webserver is only configured to deal with certain file types. This is a security feature, usually; it sets up *.pl with perl, *.php with php, etc., but won't allow random extensions to be executed as-is.
You'd have to see what Apache is telling you (which I think only Zeno can see).
09 Dec, 2009, Zeno wrote in the 7th comment:
Votes: 0
Hmm. If I enter a random filename like http://zeno.biyg.org/~matingball/blah.cg... it still gives a 403, even though it should be giving a 404.
09 Dec, 2009, Idealiad wrote in the 8th comment:
Votes: 0
Interesting, would that suggest the permissions are failing on the directory or server config level before even checking if the file exists?
09 Dec, 2009, David Haley wrote in the 9th comment:
Votes: 0
Right, I think that's typical of the CGI layer of the webserver saying "I'm not even going to try executing that because I don't know how".

For example, I have the following to enable my bzr webserve: AddHandler cgi-script .cgi
this tells Apache that .cgi files should be treated as cgi scripts.
09 Dec, 2009, Zeno wrote in the 10th comment:
Votes: 0
It's weird, I'm pretty sure someone else on the server asked for cgi-bin and I gave it to them.

I see this in my conf:
Quote
# XAMPP, since LAMPP 0.9.8:
AddHandler cgi-script .cgi .pl


I'll keep poking around.

[EDIT]
Quote
Options ExecCGI is off in this directory

Okay, should be an easy fix.
09 Dec, 2009, Zeno wrote in the 11th comment:
Votes: 0
Got it, the problem was that the <Directory> was in a VirtualHost and apparently that doesn't work with ExecCGI.
10 Dec, 2009, Idealiad wrote in the 12th comment:
Votes: 0
Excellent Zeno, thanks for hunting that down!

For anyone interested, here is what I'm testing:

http://zeno.biyg.org/~matingball/iffy/ex...

Currently there is no user account system, so new users will overwrite state of the previous.
10 Dec, 2009, Zeno wrote in the 13th comment:
Votes: 0
Does it work for you? Doesn't seem to for me.
10 Dec, 2009, David Haley wrote in the 14th comment:
Votes: 0
Works for me, although the "hints" links seem to run on top of each other.
10 Dec, 2009, Idealiad wrote in the 15th comment:
Votes: 0
It's dreadfully slow, so at the first screen you need wait a bit after you hit the space key.

eta: David, the hint links seem OK to me – do you mean the hint box overwrites itself without refreshing, or the hint box overwrites something else?
10 Dec, 2009, David Haley wrote in the 16th comment:
Votes: 0
("Eta"?)

The hint links are superimposed, at least as far as I can tell; it's kind of hard to tell as it's a jumble of characters. I'll try again tomorrow to see what happens, and post a screenshot if it happens again.
10 Dec, 2009, Idealiad wrote in the 17th comment:
Votes: 0
OK, yeah that's weird.

Just 'edited to add'. Just imagine how much time I save over the years not typing that all out. ;D
10 Dec, 2009, David Haley wrote in the 18th comment:
Votes: 0
Heh, I just write: "EDIT: …"
I was trying to figure out why you were talking about estimated time to arrival… :tongue:
11 Dec, 2009, Kline wrote in the 19th comment:
Votes: 0
It froze Chrome for me and just gave an error on IE7.
11 Dec, 2009, Zeno wrote in the 20th comment:
Votes: 0
I'm at work and it works for me in Chrome.
0.0/21