Issue Details (XML | Word | Printable)

Key: CORE-6054
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: ERCAN P.
Votes: 0
Watchers: 4

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

Random crash 64bit fb_inet_server. Possible collation issue

Created: 26/Apr/19 01:41 PM   Updated: 06/May/19 08:04 AM
Component/s: Charsets/Collation
Affects Version/s: 2.5.8
Fix Version/s: 2.5.9

File Attachments: None
Image Attachments:

1. DbgX.Shell_2019-04-26_16-41-47.png
(102 kB)
Firebird SuperClassic Server 64Bit 2.5.8
WindowsServer 2012 R2 64Bit

QA Status: Done successfully

 Description  « Hide
Hello. We are facing crash issue for about 10 days. Server has about 20 DB and is under load in working hours. Event Viewer shows unexpected terminations of server process. I have windbg dump file and it has sensitive information.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
ERCAN P. added a comment - 26/Apr/19 01:43 PM
I am trying to attach screenshot.

ERCAN P. added a comment - 26/Apr/19 01:44 PM - edited
WinDgb output sceentshot added.. I can send zipped dump file to a developer.

Vlad Khorsun added a comment - 02/May/19 10:30 AM
Provide us with download link, please

ERCAN P. added a comment - 02/May/19 12:10 PM
You can download from this link.

Vlad Khorsun added a comment - 02/May/19 12:18 PM
Send pwd to, please

Vlad Khorsun added a comment - 02/May/19 01:32 PM
seems i found the reason.

Is it reproducible ? I want to verify patch.

Vlad Khorsun added a comment - 02/May/19 01:35 PM
Call stack of crashing thread

 # Call Site
00 fb_inet_server!lookup_symbol+0xb [e:\fb25_git\r2_5_8\gen\x64\dsql\metd.cpp @ 3181]
01 fb_inet_server!METD_get_collation+0xec [e:\fb25_git\r2_5_8\gen\x64\dsql\metd.cpp @ 635]
02 fb_inet_server!pass1_constant+0x1d0 [e:\fb25_git\r2_5_8\src\dsql\pass1.cpp @ 3969]
03 fb_inet_server!PASS1_node+0xacc [e:\fb25_git\r2_5_8\src\dsql\pass1.cpp @ 817]
04 fb_inet_server!PASS1_node+0xd6 [e:\fb25_git\r2_5_8\src\dsql\pass1.cpp @ 580]
05 fb_inet_server!PASS1_node+0x176b [e:\fb25_git\r2_5_8\src\dsql\pass1.cpp @ 1117]
06 fb_inet_server!PASS1_node+0x176b [e:\fb25_git\r2_5_8\src\dsql\pass1.cpp @ 1117]
07 fb_inet_server!pass1_node_psql+0x36 [e:\fb25_git\r2_5_8\src\dsql\pass1.cpp @ 7403]
08 fb_inet_server!pass1_rse_impl+0x576 [e:\fb25_git\r2_5_8\src\dsql\pass1.cpp @ 8155]
09 fb_inet_server!pass1_rse+0x67 [e:\fb25_git\r2_5_8\src\dsql\pass1.cpp @ 8031]
0a fb_inet_server!pass1_rse_impl+0xd1 [e:\fb25_git\r2_5_8\src\dsql\pass1.cpp @ 8081]
0b fb_inet_server!pass1_rse+0x67 [e:\fb25_git\r2_5_8\src\dsql\pass1.cpp @ 8031]
0c fb_inet_server!PASS1_rse+0x28 [e:\fb25_git\r2_5_8\src\dsql\pass1.cpp @ 1237]
0d fb_inet_server!PASS1_statement+0x13a8 [e:\fb25_git\r2_5_8\src\dsql\pass1.cpp @ 1871]
0e fb_inet_server!prepare+0x80b [e:\fb25_git\r2_5_8\src\dsql\dsql.cpp @ 2644]
0f fb_inet_server!DSQL_prepare+0x2d8 [e:\fb25_git\r2_5_8\src\dsql\dsql.cpp @ 732]
10 fb_inet_server!jrd8_prepare+0x397 [e:\fb25_git\r2_5_8\src\jrd\jrd.cpp @ 4258]
11 fb_inet_server!isc_dsql_prepare_m+0x2f8 [e:\fb25_git\r2_5_8\src\jrd\why.cpp @ 3644]
12 fb_inet_server!rem_port::prepare_statement+0x3c9 [e:\fb25_git\r2_5_8\src\remote\server.cpp @ 3253]
13 fb_inet_server!process_packet+0x53f [e:\fb25_git\r2_5_8\src\remote\server.cpp @ 3556]
14 fb_inet_server!loopThread+0x1a1 [e:\fb25_git\r2_5_8\src\remote\server.cpp @ 5269]

Looks like global_temp_collation_name (see frame 02) contains garbage left from previous failed attempt to parse some query.

ERCAN P. added a comment - 02/May/19 01:48 PM
Hello, We solved crash temporarily yesterday by removing php service directory. Same service implemented as mvc (the time crash begin). We checked network logs and saw some search engines access the old php directory. We removed the complete directory for try and problem gone. We investigated running sql and there was an sql query which try to select recently removed column. It is reproducible (by activating php page)

ERCAN P. added a comment - 02/May/19 02:52 PM
Hello Mr. Sean. Why did you flag this report as "Wont Fix" ? We (three senior developers) spent nearly 2 weeks to solve this problem. If Mr. Vlad send us a patch we will be happy to try and send the result.

Sean Leyne added a comment - 02/May/19 02:55 PM

Sorry, you posted that the problem was caused by external function (php service directory), as such there was no Firebird change required.

Separately, there was no mention that Vlad had provided a patch.

ERCAN P. added a comment - 02/May/19 03:08 PM
Thank you Mr Sean. Yes we solved problem temporarily. But it is not a real solution. Other developers may suffer from same problem in the future.

Vlad Khorsun added a comment - 02/May/19 04:48 PM
The minimal reproducible sample:

1. prepare table

SQL> create table c (id int, f1 varchar(32) character set win1251 collate win1251);

2. run bad query with COLLATE clause

SQL> select * from c where f2 collate win1251_ua = 'x';
Statement failed, SQLSTATE = 42S22
Dynamic SQL Error
-SQL error code = -206
-Column unknown
-At line 1, column 26

3. run query with string constant and charset introducer

SQL> select * from c where f1 = _utf8 'x';
Statement failed, SQLSTATE = HY004
Dynamic SQL Error
-SQL error code = -204
-Data type unknown
-COLLATION for CHARACTER SET UTF8 is not defined

Here we see wrong error message with empty collation name.
In more complex cases there could be crash.
Expected - no error message.

Vlad Khorsun added a comment - 02/May/19 05:08 PM
Fix is committed, please try next snapshot build

ERCAN P. added a comment - 03/May/19 03:04 PM
Thank you Mr. Vlad. I think php service produced "column unknown" error and new service run query with _utf8 keyword (query built by .net provider). Same time we got a lot of "COLLATION for CHARACTER SET UTF8 is not defined" error feedback from our users before closing php service.