Bug #18271 Updated: Page load hangs accessing certain MSSQL data

ID: 18271 Updated by: Brendan@callaghans.com.au -Summary: Page load hangs in apparently normal circumstances Reported By: Brendan@callaghans.com.au Status: Open -Bug Type: IIS related +Bug Type: MSSQL related Operating System: Win2000 Server PHP Version: 4.2.1 New Comment: Using a process of elimination (commenting out blocks of code), I tracked down what was causing the hang. As it happens, it is all because of a certain query on the page. If PHP tries to run this query, it hangs, and the page doesn't return anything at all. A bit of experimentation with the query revealed that the issue is directly related to one particular table in my database, odometer_log. Some attempts to query this table cause the hang, do not pass GO do not collect 200 dollars. No error is reported or logged by either PHP or SQL Server. There's nothing very interesting about the table that should cause PHP to drop the bundle. Here's the table definition: CREATE TABLE odometer_log ( id int not null identity(1,1) primary key, car int not null references motor_vehicle(id), kilometres real not null, date datetime not null, type int not null references odometer_log_type(id) ) As you can see, it's all pretty standard. No exotic binary data types or the like. I am able to open (and query) the table in SQL Server Enterprise Manager without any hassles, and likewise using Linked Tables in MS Access. So the problem seems not to be within the data table itself, or ODBC, and rather something to do with how the php_mssql extension accesses it. Results of various query tests on the table (through PHP)are as follows: SELECT * FROM odometer_log: Hangs SELECT COUNT(*) FROM odometer_log: Succeeds SELECT * FROM odometer_log WHERE car=63: Succeeds SELECT * FROM odometer_log WHERE car=88: Hangs So you might think that the error was being caused by certain car IDs, right? Well, not quite, since there's no significant difference between the data for car 63 and car 88. But to prove the point, see this next series of results: SELECT * FROM odometer_log WHERE car < 10: Succeeds SELECT * FROM odometer_log WHERE car < 10 ORDER BY car: Hangs SELECT * FROM odometer_log WHERE car = 3: Succeeds SELECT * FROM odometer_log WHERE car > 2 and car < 4: Hangs SELECT * FROM odometer_log WHERE car = 9: Hangs SELECT * FROM odometer_log WHERE car > 8 and car < 10: Hangs SELECT * FROM odometer_log WHERE car > 2 and car < 10: Hangs Try as I might, I can't think of a single rational explanation for this behaviour, nor can I think of a distinguishing factor between the queries which work and those which fail. Please help before I have an aneurism! Previous Comments: ------------------------------------------------------------------------ [2002-07-12 01:39:30] Brendan@callaghans.com.au Have confirmed that the error occurs using Mozilla 0.9.4 and Netscape Communicator 4.78 under Mandrake Linux. These are older browsers, but it is clear that the error isn't IE6 specific. ------------------------------------------------------------------------ [2002-07-11 05:06:45] Brendan@callaghans.com.au Upgraded to 4.2.1, no change. Did some more searching of the bugs database, found 15324 and 14937 seemed to be similar problems to mine, but didn't find any solutions. It's becoming evident that the request is being passed to php.exe, but that PHP immediately fails to process the script, and instead of responding with an error, it just hangs. IIS reacts to this non-response by dropping out a 502 error code and a "CGI Timeout" message. Might try ADP next. ------------------------------------------------------------------------ [2002-07-11 03:24:30] Brendan@callaghans.com.au I have been examining various log files, and have identified the following: When this event occurs, the Windows Event Viewer records an error from the W3CSVC service, stating that the request was not fulfilled within the allowed timeout, and so the request was deleted. The IIS error logs record the request as having failed with a 502 HTTP code. A 502 is defined as "Bad Gateway", so not very helpful. I tried switching on the config directive "display_startup_errors", but this had no effect. The data being sent in the POST are one small integer (three digits max) and one four-character string. And the hang is only triggered for very particular combinations of the two variables. What has got me tearing my hair out is that the script is failing before it has a chance to even try operating on the data. So how could the contents of the data be making a reproducible difference? How could "169" and "2002" work perfectly, but "170" and "2002" cause the script to hang? It just doesn't follow. ------------------------------------------------------------------------ [2002-07-10 22:57:23] Brendan@callaghans.com.au Haven't been able to try that - the site is intranet only, with a standardised operating environment on the workstations. There's no other browser installed and I'd have to get permission from the SA to install one. But I'll have a chat to him and see if I can arrange a test. ------------------------------------------------------------------------ [2002-07-10 22:51:01] sniper@php.net Does this happen with other browsers? Like NS or Mozilla? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18271 -- Edit this bug report at http://bugs.php.net/?id=18271&edit=1