September to December 2022
LI-V3.0.11.33618: bugcheck "Too many savepoints (287), file: tra.cpp line: 1443" on REPLICA.
QA fbtest. WI-V3.0.11.33621, SS: hangs when test for CORE-2940 executed.
Execution of test for CORE-4653 causes FB 5.x crashes. Windows only (since 16.08.2022).
Problem relates to insufficient stack size (4Mb on Windows vs 16Mb on Linux).
QA fbtest. Name of security DB on Windows became in uppercase (since 5.0.0.706). One need to change some tests.
Test for CORE-5970 sporadically issued unexpected gdscode (335544344, io_error) instead of 335545230.
Linux, FB 3.x ... 5.x, Classic. Again problem with client detach before its process crashed. Collected all such cases, sent letter to FB team.
WI-V3.0.11.33616 Classic, experimental build: can not establish connection when some process runs query with
'UPDATE OR INSERT' in NOWAIT transaction.
FB 5.0.0.720: hanged on attempt to create DB in embedded mode, both on Linux and Windows.
FB 5.x, test for core-5685: new line in STDERR: 'port detached'.
Batch that creates FB snapshot: re-implemented code that uploads file to FTP server because of prohibition to specify wildcard characters in any FTP-commands (even in 'dir') - RFC3659 (actual after migration from Win Server 2008).
FB 3.x and 4.x: Classic is FASTER than Super when lot of connections operate with the same data. Lot of measures (requested by Alexey Kovyazin). Sent report to FB team.
WI-3.0.11.33616, Classic, experimental build: four crashes for one minute.
Gathered full history of outcomes of test CORE-5034 (requested by Alex).
Attempt to run sweep on read-only databasesilently fails (no errors / warnings in the log or trace).
NEW QA. Class Action, def trace(): minor correction required when argument 'config' is NOT None.
MAPPING can be ignored (real user name will be shown instead of mapped) if 'CREATE MAPPING' clause contains plugin ('Srp')
and this plugin is not specified in the FIRST position of AuthCLient list.
NEW QA: commit() of con.main_transaction does not lead to the same for all other transactions of this connection, and they silently are rolled back.
NEW QA. Problems with re-implementing test for CORE-4582: database can not be returned to online state.
Windows, 5.0.0.736, SuperServer: crash on executing test for GH-6947.
NEW QA. Got error 'multiple maps found' when created self-security DB and mapping in it with name and attributes that exactly match other mapping in the default security.db.
Attribute "shut single" (or "shut multi") is lost during backup-restore (in all FB since at least 2.5).
NEW QA. Maximal length of DB that is passed to gbak is limited by 255 MINUS length of protocol prefix (e.g. 'localhost/3052:' or 'xnet://' etc). This is not so for gfix and gstat - they dor not take in account this prefix and can operate with files which length is 255 characters.
NEW QA. ISQL command 'show database': its output can not be fully checked because name of database is always stripped out.
Weird result of SQL query during concatenation of attributes from mon$database for issuing string that is shown in the DB header tail by 'gstat -h' command: ten spaces are inserted between 'backup lock' and 'read-write' phrases. Need apply TRIM() to mon$read_only (and *only* to this column).
NEW QA. Questions about reproducing problem described in GH-5995. Parameter KeyHolderPlugin is per-database (but this is not noted in its description).
NEW QA. 4.0.3.2849, WIndows, Classic: hanged when execute test "functional.tabloid.max-path-length".
NEW QA. Re-implementing test for core-4337. Log of 'gfix -sweep' can remain empty for every ~10 run in FB 4.0.1 Classic.
Trace will not contain error messages with gds = 335544856 and 335545130 (connection shutdown / killed by database admin).
NEW QA. Problems with re-implementing test for CORE-6309 (limbo transactions). Utility GFIX issues totally different (very detailed) output comparing to the same test in FBT. Utility fbsvcmgr fails. One need to use exactly the same "host/port:db_name" in order to reproduce problem on some other host.
QA fbtest. FB 5.0.0.745: STDERR content of test for CORE-3064 became differ.
WI-3.0.11.33622, SS, experimental build: crash on replica.
LI-T5.0.0.758: lot of crashes, both on SS and CS.
LI-T5.0.0.760, SS: crashes on test for CORE=3362 ('cursor stability').
NEW QA: adapted 37 tests for running under pytest + firebird-qa plugin. Implemented / refactored /adjusted tests from FBT suite: core-6444, core-3064 ; functional/*misc* (2 tests)
Re-implemented aux batch for build FB 2.5.x (experimental builds) on Windows test server, problems with VS80COMNTOOLS
QA fbtest. Implemented / refactored /adjusted .fbt for 39 tests.
Test for core-4731 became failed after fix for gh-7186 (statement 'delete from rdb$backup_history' is now allowed).
FBT_RUN: crash of 3.0.11.33632 CS, Linux, when executing test for core-3064.
3.0.11.33632, Windows: mon$statement.mon$state remains 2 even if we execute 'DELETE FROM MON$STATEMENTS' (this occurs when cursor fetches lot of records one-by-one: only *current* operation will be killed, i.e. fetch of some record).
QA fbtest. Test "replication/test_shutdown_during_applying_segments_leads_to_crash": crash of LI-T5.0.0.763 SS on Linux (CentOS).
Weird result of set time zone '-02:00' : duplicate with value '11:33:33 America/Sao_Paulo' on Linux with icu version '2018e'.
NEW QA. Re-implementing tests for core-0959: gstat does not allow to use connection string startring with 'inet://', 'xnet://', 'wnet://' (unlike gfix and gbak - they have no problem with that).
Fixed missed 'ORDER BY' in the test for core-5892
NEW QA: pytest hangs at final point when check FB 4.0.1 and 4.0.2 (both Release), Classic mode, Linux only. Started long investigation, dicsussed with pcisar since 09.10.2022 19:29. Found two tests (core_5441_test.py and core_5470_test.py) which must be executed one-by-one for 100% reproducing of that.
Continued investigation of hanging pytest when running tests core_5441 and core_5470. Sent report to FB team.
NEW QA: continued investigation of problem with tests core_5441 and core_5470. Found that problem somehow relates to the INCLUDE_FILTER regexp; pytest can hang when this regexp contain PIPE between two or three tokens.
NEW QA: encountered with broken TX isolation when running test CORE-2216 on 4.0.1.2692 (Release), Linux, Classic only: transaction that is started by NBACKUP connection does not see changes in the rdb$backup_history.
QA fbtest: some tests need to be changed after recent commits related to optimizer (core-2078, core-5236, optimizer/opt_inner_join_05, opt_left_join_07).
Adjusted test core-2650 because of new clause in explained plan: 'FILTER (PRELIMINARY)'. Related to old ticket GH-1708.
Simplified test CORE-6095 (COMMIT_RETAINING, "New number <NNN>"): trace parsing must be much simpler than it was initially made. No sens to take in account exact IDs of started transactions. Transaction that is started by Garbage Collector can appear in the trace log at any moment - no matter of starting 1st user transaction. Found since 5.0.0.733.
Fixed missed 'git reset --hard' in the batch scenario that makes FB snapshots on Linux. Added sending to email info about every stage of building process, including final outcome (success or fail).
QA fbtest. FBT_RUN: lot of crashes when running tests on Windows, build 5.0.0.797 (gbak-related, messages: "action cancelled by trigger (3)", "cannot deactivate index used by a PRIMARY/UNIQUE constraint" etc).
Regression in 5.0.0.807, raised on test for CORE-2477. Related wrong handling of dataset which has WHERE-filtering and is originated from derived table which, in turn, has OUTER JOIN.
LI-V3.0.11.33618 (SS), experimental build: crash FB was idle (no users activity).
November 2022
December 2022
NEW QA. Continued re-implementation of batch scenario for running tests. Investigated to apply pytest-xdist package (FAILED). Can not use 'trivial' method when each major FB is checked separately (on Windows): fbguard allows to be launched only once.
Adjusted functional/isql/isql_02 to the output on recent FB version.
WI-T5.0.0.863 SS crached during run tests for core-0185.
Replication has trouble on experimental FB 3.x and 4.x if UPDATE statement changes PK-column which was declared as text based on UTF-8 charset *with* COLLATE clause (i.e. COLLATE UNICODE_CI or UNICODE_CI_AI): record with previous value of PK remain in replica DB together with new.
LI-V3.0.11.33618, SS, experimental build: crash at night (when almost zero activity). Again related to transactions pool (as explained by Alex).
QA-run can not be parallelized on Windows through several launches on diff major FB instances: fbguard requires to be run only once.Implementation of this task has to be deferred because of that.
Started full re-implementation of QA-run scenario for Linux. Lot of changes in .sh and .sql scripts have been done.
All replication-related tests again failed on Windows. The only way to 'solve' this problem is still host restart. Actual reason remains unknown.
Message "gbak: ERROR:message length error (encountered 32, expected 65568)" can raise for table which record size is much less than 64K (Issue #7438)
NEW QA. Weird message "invalid statement handle" raises and is written to STDERR, although is considered as Python WARNING. Looks like related to non-releases resources that have been taken during creation of prepared statements. Found strange workaround: one need to make DB-connection at the same function as prepared statements (look very weird but 100% reproduced).
Permanent URLs to FB 4.x and 5.x on github can be obtained only if "/tag" substring will be replaced with "/expanded_assets"
(because page is loaded by AJAX; thanks to Adriano for suggestion)
Several runs of new QA script on Linux. Got crashes, check that dump and stack trace avaliable for download when see QA site on http server.
NEW QA. Warning "invalid statement handle" (after Python make-all-reports script) can not be avoided and still raises after test finish.
Decided to ignore it and continue work of script.
Made test for quick estimation of time that is spent on PREPARE (requested by Alexey Kovyazin). Ratio is about 23 / 13 (prepare on each iter vs prepare only once; checked for 10'000; 100'000 and 1'000'000 rows)
OLTP-EMUL, LI-V3.0.11.33648: crash during working phase (before run 'gfix -shut full- force 0 ...').
WI-V3.0.11.33639 SS, experimental build: crash related to ICryptKey::setSymmetricMade test for benchmark of filtering 'main' table by its join with GTT ( instead of "IN(...)" ) vs join to MON$CONTEXT_VARIABLES (Alexey Kovyazin request). Results *strongly* depend on PLAN of execution.