[Firebird-devel] [FB-Tracker] Created: (CORE-4819) Running "execute procedure sp_test(ce.x) returning_values(ce.y)", where 'ce' is CURSOR, leads to crash.
Running "execute procedure sp_test(ce.x) returning_values(ce.y)", where 'ce' is CURSOR, leads to crash. Key: CORE-4819 URL: http://tracker.firebirdsql.org/browse/CORE-4819 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0 Beta 2 Reporter: Pavel Zotov Original discussion (in russian) can be found here: http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1158905&msg=17704102 Test: create or alter procedure sp_test(a_x int) as begin end; recreate table test(id int primary key, x int, y int); insert into test values(1, 10, 11); commit; set term ^; create or alter procedure sp_test(a_x int) returns(o_y int) as begin o_y = 2 * a_x; suspend; end ^ commit ^ execute block returns(old_y int, new_y int) as begin for select x, y from test as cursor ce do begin old_y = ce.y; execute procedure sp_test(ce.x) returning_values(ce.y); new_y = ce.y; suspend; end end ^ rollback ^ Result in WI-T3.0.0.31845: message "internal Firebird consistency check (EVL_assign_to: invalid operation (229), file: evl.cpp line: 205)" appeares in firebird.log -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4818) Appverifier reports memory with active critical section freed when fbclient.dll is unloaded
Appverifier reports memory with active critical section freed when fbclient.dll
is unloaded
---
Key: CORE-4818
URL: http://tracker.firebirdsql.org/browse/CORE-4818
Project: Firebird Core
Issue Type: Bug
Components: API / Client Library
Affects Versions: 2.5.2
Environment: AMD64 machine, Windows 7, running Tableau desktop client
under appverifier
Reporter: Dave Heberer
Set up machine to run tableau 9.0
(http://www.tableau.com/products/desktop/download?os=windows) under
appverifier. Launch the application, and after it starts up close the
application. app crashes with the following stack:
-
APPLICATION_VERIFIER_LOCKS_LOCK_IN_FREED_VMEM (212)
Freeing virtual memory containing an active critical section.
This stop is generated if the current thread is calling VirtualFree on a
memory block that contains an active critical section. The application should
call
DeleteCriticalSection on this critical section before if frees this memory.
$ kb - to display the current stack trace, that is calling VirtualFree.
The probable culprit is the DLL that calls VirtualFree.
$ !cs -s parameter1 - dump information about this critical section.
$ dps parameter2 - to identify the code path for the initialization
of this critical section.
Arguments:
Arg1: 07ffbc80a8d0, Critical section address.
Arg2: , Critical section initialization stack trace.
Arg3: 07ffbc80, Memory block address.
Arg4: 0001, Memory block size.
FAULTING_IP:
vrfcore!VerifierStopMessageEx+6f4
07fe`e8d83a00 cc int 3
EXCEPTION_RECORD: -- (.exr 0x)
ExceptionAddress: 07fee8d83a00
(vrfcore!VerifierStopMessageEx+0x06f4)
ExceptionCode: 8003 (Break instruction exception)
ExceptionFlags:
NumberParameters: 1
Parameter[0]:
FAULTING_THREAD: 2298
DEFAULT_BUCKET_ID: STATUS_BREAKPOINT
PROCESS_NAME: tableau.exe
CRITICAL_SECTION: 07ffbc80a8d0 -- (!cs -s 07ffbc80a8d0)
ERROR_CODE: (NTSTATUS) 0x8003 - {EXCEPTION} Breakpoint A breakpoint has
been reached.
EXCEPTION_CODE: (HRESULT) 0x8003 (2147483651) - One or more arguments are
invalid
EXCEPTION_PARAMETER1:
NTGLOBALFLAG: 2000100
APPLICATION_VERIFIER_FLAGS: 80043007
APP: tableau.exe
PRIMARY_PROBLEM_CLASS: STATUS_BREAKPOINT
BUGCHECK_STR: APPLICATION_FAULT_STATUS_BREAKPOINT
LAST_CONTROL_TRANSFER: from 07fee446a31f to 07fee8d83a00
STACK_TEXT:
`002fef30 07fe`e446a31f : ` 07fe`e4469f36
07fe`e449fc20 07fe`e446963d : vrfcore!VerifierStopMessageEx+0x6f4
`002ff290 07fe`e4468688 : `0001 `0001
` `76edb2c9 : vfbasics!AVrfpFreeMemLockChecks+0xef
`002ff2f0 07fe`e4472b20 : 07ff`bc80 `
07ff`bc80 07fe`e8d87cee : vfbasics!AVrfpFreeMemNotify+0x38
`002ff320 07fe`e447250f : `002ff448 `
` `002ff440 : vfbasics!AVrfpFreeVirtualMemNotify+0x1f4
`002ff3c0 07fe`fcf465d0 : `8000 `
` ` : vfbasics!AVrfpNtFreeVirtualMemory+0xa3
`002ff410 07fe`e4473269 : ` 07ff`bc80
` `73f39178 : KERNELBASE!VirtualFree+0x30
`002ff440 `73a85d7e : `002ff508 `1000
07ff`bc80 ` : vfbasics!AVrfpVirtualFree+0xb1
`002ff480 `73a89aed : ` `
` 07fe`e446abb8 :
fbclient!Firebird::MemoryPool::external_free+0xce
`002ff4c0 `73a89d00 : ` `0001
0001`02629f20 0001`02629f00 :
fbclient!Firebird::MemoryPool::deletePool+0x10d
`002ff500 `73a95f8e : 0001`02629f20 `0001
` `cba2e8f8 :
fbclient!Firebird::MemoryPool::cleanup+0x10
`002ff530 `73cbb13f : 0001`02629f30 0001`02629f20
` ` : fbclient!`anonymous
namespace'::allClean+0x1e
`002ff570 `73cbb363 : `0001 `
` 07fe`e44736e6 : fbclient!_CRT_INIT+0xcf
`002ff5b0 07fe`e41d3eb8 : `03a96fb0 `
07fe`e4200df0 07fe`e446d5ca : fbclient!__DllMainCRTStartup+0xe3
`002ff5f0 07fe`e8d8bae5 : 0001`037acf90 07fe`
` `e15472d8 :
verifier!AVrfpStandardDllEntryPointRoutine+0xbc
`002ff670 07fe`e4466f62 : `8f2bafb0
[Firebird-devel] [FB-Tracker] Reopened: (CORE-4177) Problem with some boolean expressions not being allowed
[ http://tracker.firebirdsql.org/browse/CORE-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Zotov reopened CORE-4177: --- See issue dated 27/Mar/15 01:45 PM. > Problem with some boolean expressions not being allowed > --- > > Key: CORE-4177 > URL: http://tracker.firebirdsql.org/browse/CORE-4177 > Project: Firebird Core > Issue Type: Bug > Components: Engine >Affects Versions: 3.0 Alpha 1 >Reporter: Adriano dos Santos Fernandes >Assignee: Adriano dos Santos Fernandes > Fix For: 3.0 Alpha 2 > > > select 1 > from rdb$database > where true is true > Work is correct > select 1 > from rdb$database > where (1=1) and true > Work is correct > select 1 > from rdb$database > where (1=1) is true > Invalid token. > Dynamic SQL Error. > SQL error code = -104. > Token unknown - line 3, column 13. > is. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Moving Jaybird auto-commit implementation into Firebird
Thank you for the pull request! I haven't looked at it closely yet (will do that this weekend), but I think it's great. I have some concerns regarding the commit demarcation as compared to the requirements of jdbc, but I will come back at that in comments on the pull request. Mark - Reply message - Van: "Maxim Smyatkin" Aan: Onderwerp: [Firebird-devel] Moving Jaybird auto-commit implementation into Firebird Datum: vr, mei 29, 2015 16:10 Hello,Recently we've got an information from some company that they would like to use Firebird/Red Database with OpenCMS, but they couldn't afford it because of bad performance. We compared it with PostgreSQL and it was true - on some page views PG showed 4 seconds while for Firebird it was almost 27 seconds. Skimming through performance audit log explained us, that CMS executes lots (thousends) of small selects per page view. I agree that it seems like a horrible design, but anyway PG handled it much faster. The reasons were: 1. In auto-commit mode Jaybird wraps any statement into start/commit calls. So, it does two additional calls to DBMS per statement; 2. It doesn't really matter if the statement changes anything or not. It executes start/commit in both cases. Here is a pull request with changes to fix this behaviour using DBMS API's auto-commit flag: https://github.com/FirebirdSQL/jaybird/pull/1 Any further information about implementation or results is in comment to the pull request. It seems to work excellent with OpenCMS, but Jaybird's unit tests show several problems: 1. testBatch shows failure, because now every statement in the batch execution mode is commited separately. This behaviour is perfectly fine as JDBC specification states that you can't rely on batch mode + auto-commit mode. Maybe, Firebird has some clients who rely on this behaviour, I don't know. Anyway, you can wrap batch execution into freshly started non auto-commit transaction, if you wish. I decided to leave this decision up to you and didn't touch it. 2. Whole TestFBBlobStream family (6 tests) fails. The reason is bug in Firebird transaction engine. When transaction started in auto-commit mode actually commits (via commit_retaining) it doesn't free any resources. E.g., what happens in these tests is: - we create a procedure P using a table T. - the P states its interest in the T (while looking for P's dependencies); - transaction commits the changes with retaining flag and forgets to say that it isn't interested in the T anymore; - we try to drop the T, but we can't because it is marked as "in use"! I attached a patch (for 2.5 branch) to release resources on commit_retaining. But I believe the problem is rather in modify_procedure()'s code, because it should release rel_use_counts on its own. 3. TestDriverConnectionPoolDataSource.testPreparedStatement fails with an Error. I don't know why it happens and how to fix it. Looks like some kind of race conditions, but I'm not sure. If anyone could look into it, it would be awesome. Here is my commit for OpenCMS, so that it could effectively use modified Jaybird: https://github.com/Smyatkin-Maxim/opencms-core/commit/4b1901f4d339c4ec710ad84d316e70f694068dc8 I will issue pull request as soon as I verify that this Jaybird improvement is fine. -- Thank you! Smyatkin Maxim, Red Soft Corporation. https://www.linkedin.com/in/smyatkin-- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Moving Jaybird auto-commit implementation into Firebird
Hello, Recently we've got an information from some company that they would like to use Firebird/Red Database with OpenCMS, but they couldn't afford it because of bad performance. We compared it with PostgreSQL and it was true - on some page views PG showed 4 seconds while for Firebird it was almost 27 seconds. Skimming through performance audit log explained us, that CMS executes lots (thousends) of small selects per page view. I agree that it seems like a horrible design, but anyway PG handled it much faster. The reasons were: 1. In auto-commit mode Jaybird wraps any statement into start/commit calls. So, it does two additional calls to DBMS per statement; 2. It doesn't really matter if the statement changes anything or not. It executes start/commit in both cases. Here is a pull request with changes to fix this behaviour using DBMS API's auto-commit flag: https://github.com/FirebirdSQL/jaybird/pull/1 Any further information about implementation or results is in comment to the pull request. It seems to work excellent with OpenCMS, but Jaybird's unit tests show several problems: 1. testBatch shows failure, because now every statement in the batch execution mode is commited separately. This behaviour is perfectly fine as JDBC specification states that you can't rely on batch mode + auto-commit mode. Maybe, Firebird has some clients who rely on this behaviour, I don't know. Anyway, you can wrap batch execution into freshly started non auto-commit transaction, if you wish. I decided to leave this decision up to you and didn't touch it. 2. Whole TestFBBlobStream family (6 tests) fails. The reason is bug in Firebird transaction engine. When transaction started in auto-commit mode actually commits (via commit_retaining) it doesn't free any resources. E.g., what happens in these tests is: - we create a procedure P using a table T. - the P states its interest in the T (while looking for P's dependencies); - transaction commits the changes with retaining flag and forgets to say that it isn't interested in the T anymore; - we try to drop the T, but we can't because it is marked as "in use"! I attached a patch (for 2.5 branch) to release resources on commit_retaining. But I believe the problem is rather in modify_procedure()'s code, because it should release rel_use_counts on its own. 3. TestDriverConnectionPoolDataSource.testPreparedStatement fails with an Error. I don't know why it happens and how to fix it. Looks like some kind of race conditions, but I'm not sure. If anyone could look into it, it would be awesome. Here is my commit for OpenCMS, so that it could effectively use modified Jaybird: https://github.com/Smyatkin-Maxim/opencms-core/commit/4b1901f4d339c4ec710ad84d316e70f694068dc8 I will issue pull request as soon as I verify that this Jaybird improvement is fine. -- Thank you! Smyatkin Maxim, Red Soft Corporation. https://www.linkedin.com/in/smyatkin commit_retaining_release.patch Description: Binary data -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4817) ISQL doesn`t show number of affected rows for "MERGE ... WHEN MATCHING" in case when this number surely > 0
ISQL doesn`t show number of affected rows for "MERGE ... WHEN MATCHING" in case when this number surely > 0 --- Key: CORE-4817 URL: http://tracker.firebirdsql.org/browse/CORE-4817 Project: Firebird Core Issue Type: Bug Components: ISQL Affects Versions: 3.0 Beta 2, 2.5.5 Reporter: Pavel Zotov Tested on WI-T3.0.0.31844, result in WI-V2.5.5.26871 is similar (just change row_number() to create sequence + gen_id). SQL> recreate table s(id int, x int); SQL> commit; SQL> insert into s(id, x) select row_number()over(), 2 * row_number()over() from rdb$types rows 5; SQL> commit; SQL> select * from s; IDX 12 24 36 48 5 10 SQL> recreate table t(id int primary key, x int); SQL> commit; SQL> set count on; SQL> merge into t using s on s.id = t.id when not matched then insert values(s.id, s.x); Records affected: 5 SQL> select * from t; IDX 12 24 36 48 5 10 Records affected: 5 SQL> merge into t using s on s.id = t.id when matched then update set t.x = - 3 * s.x; Records affected: 0 -- <<< ??? -- Verify that last merge really changed target table: SQL> select * from t; IDX 1 -6 2 -12 3 -18 4 -24 5 -30 Records affected: 5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4816) Incorrect column in error message for "Unexpected end of command"
Incorrect column in error message for "Unexpected end of command" - Key: CORE-4816 URL: http://tracker.firebirdsql.org/browse/CORE-4816 Project: Firebird Core Issue Type: Bug Affects Versions: 2.5.4 Reporter: Maxim Kuzmin Priority: Minor Query: -- SELECT T.* FROM (SELECT '1' FROM RDB$DATABASE -- Comment -- Comment -- Comment -- Comment -- Prepare failed with message: Invalid token. Dynamic SQL Error. SQL error code = -104. Unexpected end of command - line 12, column 9. Column 9 is wrong, since it is in the middle of a comment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
