Trace session leads FB 4.0 to hang after 2nd launch of trivial .sql script. Neither attach to any database nor regular restart of FB service can be done. [CORE5330] #5606
Assignees
Comments
|
Commented by: @pavel-zotov One more issue: this bug present only on SuperServer. Classic & SuperClassic - work fine. |
|
Commented by: @hvlad How database should be named ? |
Modified by: @hvladassignee: Vlad Khorsun [ hvlad ] |
|
Commented by: @pavel-zotov I used alias ('e40') for connecting; but trace config has 1st line ("database = #((%[\\/](e40).fdb)|(e40)) ") which suggests that one may use any name or alias. isql /:e40 -i script.sql |
Modified by: @hvladstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 4.0 Alpha 1 [ 10731 ] |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: No test => Done successfully |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Closed [ 6 ] |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Submitted by: @pavel-zotov
Steps to reproduce:
1. Create config file for trace with following lines:
database = #((%[\\/](e40).fdb)|(e40))
{
enabled = true
log_sweep = true
log_errors = true
#################### A C H T U N G - 1 ##############
time_threshold = 0
exclude_filter = %(with recursive role_tree|select current_user)%
####################################################
log_connections = true
log_transactions = true
# log_context = true
log_statement_prepare = true
# log_statement_start = true
log_statement_finish = true
# log_statement_free = true
# log_trigger_start = true
# log_procedure_start = true
# log_procedure_finish = true
# log_function_finish = true
# log_trigger_finish = true
# print_plan = true
# explain_plan = true
# print_perf = true
max_sql_length = 16384
max_log_size = 5000000
}
database = %[\\/]security4.fdb
{
#################### A C H T U N G - 2 ##############
enabled = false
########################################################
}
services
{
# Do we trace services events or not
enabled = false
}
2. Create following .sql:
recreate table ttt(id int generated by default as identity, x int, y int);
commit;
set term ^;
execute block as
declare s varchar(200) = 'insert into ttt(x, y) values(?, ?)';
declare n int = 3;
begin
while (n>0) do
begin
execute statement (s) (:n, :n * 2);
n = n - 1;
end
end
^
set term ;^
commit;
select * from ttt;
3. Launch trace (using fbtrcmgr or fbsvcmgr - no matter).
4. Launch ISQL and run above mentioned script
5. REPEAT step 4.
At this point you will not be able to:
1) connect to current DB or any other;
2) stop FB service (though trace session WILL see signal about stopping and do that)
Detected only on 4.0 (current snapshot). No such problem on 3.0.
ISQL Version: WI-T4.0.0.327 Firebird 4.0 Unstable
Server version:
WI-T4.0.0.327 Firebird 4.0 Unstable
WI-T4.0.0.327 Firebird 4.0 Unstable/tcp (csprog)/P14
WI-T4.0.0.327 Firebird 4.0 Unstable/tcp (csprog)/P14
OS: Windows XP SP3.
PS. firebird.conf:
RemoteServicePort = 3400
Servermode = Super
IpcName = fb40ss
#BugcheckAbort = 1
#DefaultDbCachePages = 8192
LockHashSlots = 22111
TempCacheLimit = 2147483647
# actual only in Win, FW = OFF
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1
#ExternalFileAccess = Restrict C:\MIX\firebird
TempDirectories = c:\temp
MaxUserTraceLogSize = 99999
FileSystemCacheThreshold = 65536K
AuthServer = Legacy_Auth,Srp
AuthClient = Legacy_Auth,Srp,Win_Sspi
WireCrypt = Disabled
UserManager = Legacy_UserManager
DeadlockTimeout = 1
UdfAccess = Restrict UDF;C:\WINNT\system32
PPS. Nothing interesting in firebird.log:
CSPROG Sun Aug 14 15:13:25 2016
JProvider::shutdown:
Firebird shutdown is still in progress after the specified timeout
CSPROG Sun Aug 14 15:16:07 2016
INET/inet_error: read errno = 10054, client host = csprog, address = 192.168.43.154/1473, user = zotov
CSPROG Sun Aug 14 15:16:11 2016
setsockopt: error setting IPV6_V6ONLY to 0
... etc ...
Commits: 20e03be
The text was updated successfully, but these errors were encountered: