Matt Allen wrote:

> "document contains no data" does mean that PHP has basically crapped itself, and
> yes, it does do it at funny times.
> 
> What you can do is run Apache from withing gdb and have a look at the backtrace,
> they are pretty helpful.
> 
> If you need a hand, let me know.

There will only be a backtrace if there is coredump (or at least a
segfault), right? There is neither. PHP is silently exiting with
success!

Just for the record, I did try running Apache under gdb. There was no
segfault, but the zero length document was returned. The
apache/access.log entry looks like this:

127.0.0.1 - - [21/Jul/2000:11:44:05 +1000] "GET / HTTP/1.0" 200 0

There is nothing in apache/error.log.

Graeme Merrall wrote:

> have a look at the apache error log as well. Segfaults will show up in
> there.

See above.

> There's been some slippage in the PHP 4 and more segfaults are
> creeping in then there should be.

Eek. The SourceForge code is built for (and I am using) PHP3.

> As Matt pointed out, having a look at
> the core or doing a backtrace can help nail things down.
> 'gdb httpd'
> 'run -X'
> load the page and wait for the segfault
> 'bt'

This procedure is pretty much what's in the FAQ. Sadly, lacking a
segfault, it doesn't apply here.

> Sometimes also compiling up a CGI versiob and running the script through
> there can reveal problems as well.

I hadn't realised that this option was available. Building PHP from
source wasn't high on the list of things that I wanted to do in order to
get this working, but lacking other options, I'll give it a go.

Thanks to both of you.

- Raz


--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Reply via email to