httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Conner <>
Subject Re: [users@httpd] Mysterious \"Premature end of script headers\" error
Date Tue, 05 Dec 2006 07:38:57 GMT
It was thus said that the Great Boyle Owen once stated:
> > 
> > On Friday 01 December 2006 14:05, uxwrstre wrote:
> > > ...
> > > shows the following: [Fri Dec  1 13:33:43 2006] [error] [client
> > >] Premature end of script headers:
> > > /home/web/archive/docs/bin/http-goto
> > 
> > Hello everybody,
> > 
> > I found out the problem!
> > The problem was that the CGI-BIN C program worked perfectly 
> > in the console but 
> > did a segmentation fault while called by apache. It seems that this 
> > segmentation fault appears only if apache calls this process. 
> > I suppose that 
> > the cgi-bin program is buggy.
> > It would be good to integreate in apache in the error 
> > logfiles on cgi-bin 
> > program failure an output in the log files like Signal 11 
> > SIGSEGV received or 
> > something like that.

  One trick I've done under Unix, debugging CGI programs in C is to add the
following to the CGI program:

volatile int global_debug = 1;

int main(int argc,char *argv[])
  while (global_debug)

  /* rest of code */

Compile the program (I'm assuming GCC here, change according to platform)
with debugging information (for gcc, that's the "-g" option, turn off
optimizations).  Now, in a browser, cause Apache to launch the CGI program. 
The program will start, then sit there (in a tight CPU loop).  Then, from
the command line, do:

RootPrompt# ps aux	# find process id of CGI program
RootPrompt# gdb cgiprogram processid
	gdb blah blah blah blah

At the gdb prompt:

gdb> set global_debug = 0
gdb> c

When it segfaults, type 'where' at the gdb prompt and you'll get the
location of the fault (although it may be some library routine, you'll get a
stack trace and can probably figure out where the fault actually is).

  Now, onto the Apache portion of our program.

> If only it were so easy... It's not the apache process that runs the
> program - apache forks a new process to run the program. So it's the
> forked prog that gets the signal, not apache. Apache is just listening
> for output from the program and produces the canonical error message if
> it doesn't get a recognisable CGI header.

  But since Apache spawned the program, it must, at some point, to a wait()
or waitpid() on the child process to get the return code (else you end up
with a zombie process).  Something like:

	result = wait(childpid);
	if (WIFEXITED(result) == 0)	/* abnormal termination of child */
	  if (WIFSIGNALED(result))	/* we exited on uncaught signal */
	    sig = WTERMSIG(result);	/* get signal that wasn't caught */
	    /* log signal ... */

  -spc (Can you tell I've done this one too many times?)

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message