|FreeTDS User Guide: A Guide to Installing, Configuring, and Running FreeTDS|
|Prev||Chapter 8. Troubleshooting||Next|
Web browsers display this error when the underlying script didn't return any information. The error could be in any of several places, of which FreeTDS is one. To isolate the cause, turn on enough logs to see the query, and execute the query through SQSH. If that works, the problem lies further up the chain. If it doesn't, take a look at the known issues section.
FreeTDS under PHP executing within an Apache process may abort with a segmentation fault. The evidence of this is the words "Segmentation Fault" or "Bus Error" in the Apache error log, and a "Page contains no data" warning displayed by the web browser. The unexpected termination of the process causes the connection to the client to be closed before any buffered data is sent.
To diagnose this sort of problem, follow this procedure;
Compile PHP as a CGI binary.
This should have been a side-effect of your build of PHP, look for an executable called php in the PHP build tree. If you are using a packaged binary, look for a php-cgi package.
Make a reproducer.
Make a PHP script that reliably reproduces the segmentation fault via the web server, but with no arguments. This is so that you can execute it using the PHP binary, thus excluding the web server as the cause of the problem.
Reproduce on command line.
Reproduce the segmentation fault using PHP on the command line, by activating PHP with the script as first argument. For example;
% php file.php Segmentation fault %
If this doesn't reproduce the segmentation fault, then there is something about the environment that differs, so look for the differences and resolve them. Check environment variables, assumptions made by the script, the UID you are executing under, and the current working directory.
Reproduce using GDB.
Now reproduce the segmentation fault using the debugger, GDB. Instead of aborting to the command line, GDB will stop executing the PHP program at the point of failure. Use the bt command to determine the details and context. This is called a backtrace.
% gdb php gdb> run file.php gdb> bt
Analyze the backtrace.
Read the backtrace to determine what the cause of the problem is. Examine each line, assigning responsibility by component; some code is PHP, some is FreeTDS, and some may be glibc. You will need the source code for each component, and software engineering debugging skills.
If you cannot determine the cause yourself, send the backtrace to the mailing list, along with the PHP script. It helps to make the script as small as possible, but still fail. It also helps to report the version numbers of PHP, and FreeTDS.