Issue Details (XML | Word | Printable)

Key: CORE-3554
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: Gregori Arjona
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.
Firebird Core

Server crashes during prepare or throws incorrect parsing error if the remotely passed SQL query is empty

Created: 13/Jul/11 08:26 AM   Updated: 27/May/15 04:38 PM
Component/s: Engine
Affects Version/s: 2.1.0, 2.0.4, 2.1.1, 2.0.5, 2.1.2, 2.1.3, 1.5.6, 3.0 Initial, 2.0.6, 2.5.0, 2.1.4
Fix Version/s: 2.5.1, 2.1.5, 3.0 Alpha 1

File Attachments: 1. Text File drwtsn32.log (169 kB)

Windows 2003 standard edition 4gb RAM
Runing on VMware Esxi server
Firebird win32
Firebird odbc

QA Status: Done successfully
Test Details: Test was made only for 3.0 because 2.5 allows to pass in ES much longer string than 32K.

 Description  « Hide
In several of our servers we detected regular crashes of firebird, 1 or 2 times a day, we have set to record drwatson memory dumps and found that every time an error occurs is in the same line of code during the GDS_DSQL_PREPARE.


line 1373

if (!length) {
length = strlen(string); <----- firebird crashes here.

Whe can attach "user.dmp" and "drwtsn32.log"

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 13/Jul/11 09:14 AM
What was the fbclient.dll version used to connect the server? Was a connection local or remote (TCP)?

Gregori Arjona added a comment - 13/Jul/11 09:29 AM
- fbclient.dll version
- Remote TCP conection to the server.

I'm trying to upload a memory dump on an external server, because the file is too large.

Here is:

Dmitry Yemanov added a comment - 13/Jul/11 09:34 AM
Also, SuperServer or Classic?

Gregori Arjona added a comment - 13/Jul/11 09:49 AM
Sorry, SuperServer version.

Dmitry Yemanov added a comment - 13/Jul/11 10:20 AM
I confirm the problem.

Dmitry Yemanov added a comment - 13/Jul/11 11:24 AM
Well, we can surely fix the server to not crash. But I'm not sure it will magically resolve your issues, as the actual problem lies on the client side. Your application either passes the empty SQL text to prepare, or passes a "too long" SQL text (64KB or 128KB etc) so its length becomes zero as a result of conversion into USHORT (unsigned 16-bit integer) which represents the supported SQL text length.

Gregori Arjona added a comment - 13/Jul/11 12:34 PM
Ok, do you think the problem may be related to the ODBC drivers?, because I am sure that my application does not send empty or too big, SQL queries.

If so, then i ask for help to the developer of the ODBC drivers.

Thank you very much, Dmitry.

Dmitry Yemanov added a comment - 13/Jul/11 12:49 PM
Honestly, I don't know. You could start with the call tracing enabled (in the ODBC settings) and find out the last statements before the server crashes. It might give some ideas for further searching. Or you might try the next (tomorrow's) snapshot build of v2.1.5 which would have the crash supposedly fixed and test it in the field. If I'm right, you'll get the proper error reported and this could be enough to have the reason debugged on your side by adding the error logging into the application.

Gregori Arjona added a comment - 15/Jul/11 12:14 PM
Hello Dmitry.

Now i'm testing the snapshot build of v2.1.5 and the server does not crash, but on another server i have a diferent problem, the server crashes in a diferent way, i post the link to the server memory dump, can you have a look ? or i need to create a new issue.

Thank you very much

Dmitry Yemanov added a comment - 15/Jul/11 12:17 PM
What is the FB version/build on that another server? or some snapshot build?

Gregori Arjona added a comment - 15/Jul/11 12:25 PM
It's Firebird

This server also suffers from the same problem of errors during prepare, but this new error occurs more times a day.

Dmitry Yemanov added a comment - 15/Jul/11 12:44 PM
It's a known issue, already reported as CORE-3409. It is going to be fixed in a few days.