Error recompiling a package with some combination of nested functions

[L-VV]

A problem has been discovered with package RE-compiling with some combination of nested functions.

Firebird 4 amd64 current snaphost (on previous snapshots were the same),
Debian 5.10.28-1 (2021-04-09) x86_64 GNU/Linux.

I managed to make a simple example, which is reproduced in 100% of cases.
I attached an archive with scripts to test it in ISQL (the creation of objects in the database is not required).
package_recompile_error-test_en.zip

The first compilation of the package is successful, but on the second recompilation an error occurs, which leads to close connection to the database:

CREATING                  
========================= 
USR_PKG_TEST (1st try)... 


CREATING                  
========================= 
USR_PKG_TEST (2nd try)... 

Statement failed, SQLSTATE = 08006

Error reading data from the connection.
After line 1 in file USR_PKG_TEST.sql
Statement failed, SQLSTATE = 08006

Error writing data to the connection.
-send_packet/send
After line 15 in file USR_PKG_TEST.sql
Statement failed, SQLSTATE = 08006

Error writing data to the connection.
-send_packet/send
After line 15 in file 01_create_packages_test.sql
Statement failed, SQLSTATE = 08006

Error writing data to the connection.
-send_packet/send
After line 20 in file 01_create_packages_test.sql

00_isql_create_packages_test.sh: isql error: Failed to create packages

10.05.2021 10:27:52 Done

Cut from the Firebird server log:

blackbox	Mon May 10 10:27:52 2021
	/opt/firebird/bin/fbguard: /opt/firebird/bin/firebird terminated abnormally (-1)

blackbox	Mon May 10 10:27:52 2021
	/opt/firebird/bin/fbguard: guardian starting /opt/firebird/bin/firebird

blackbox	Mon May 10 10:27:52 2021
	REMOTE INTERFACE/gds__detach: Unsuccesful detach from database.
	Uncommitted work may have been lost.
	Error writing data to the connection.
	send_packet/send

blackbox	Mon May 10 10:27:52 2021
	setsockopt: error setting IPV6_V6ONLY to 0

Also in the discussion on the sql.ru forum, one of members wrote about problem, possible related to this issue:
"The connection is also can be broken in the package, if in the nested call procedure/function an exception occurs, and it processed in their 'WHEN DO ...' block.
But in that case the connection breakage occurs when the procedure/function is running, not at compile time.
In this situation, it is additional necessary to catch and handle this exception in the caller's procedure/function 'WHEN DO ...' block.
Not once came across this.
Perhaps these issues have some kind of common cause in Firebird, associated with calling the package's own procedures/functions."

[asfernandes]

Thanks for the test case.

I cannot reproduce it in v3, it has some different detail on how routines are released though I don't found exactly what. But core idea is the same as v4, so I think it's problematic as well.

In Routine::remove when FLAG_BEING_ALTERED is set it may call setId(0) while it's still present in cache.

Later checkCache may think the routine is not in cache anymore and delete it, while it's still has the wrong pointer in cache.

I propose to introduce another flag to be set and do not change the id. In places the id was being checked we now check the new flag. And also clear the flag in the places the id was checked.

Patch attached for review.

issue-6801-1.diff.txt

[L-VV]

Hi,
Is there any information when this error can be fixed in snapshots?
It is very annoying...

[L-VV]

Today I was updated to the last snapshot 5.0.0.63 and checked my test.

Perfectly, the bug is no longer reproduced :)

Thank you!