-
-
Notifications
You must be signed in to change notification settings - Fork 217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add manual delete for tra_dbcreators_list #8207
Add manual delete for tra_dbcreators_list #8207
Conversation
If we don't delete it manually assert will be thrown if SEC$DB_CREATORS returns a lot of records
Maybe it would be better to wrap |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also backport this fix to old branches
I will backport it. |
@@ -198,6 +198,7 @@ class jrd_tra : public pool_alloc<type_tra> | |||
tra_user_management(NULL), | |||
tra_sec_db_context(NULL), | |||
tra_mapping_list(NULL), | |||
tra_dbcreators_list(nullptr), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not required as every class inherited from pool_alloc
has its instance zero-initialized at creation. But I prefer us being more explicit in this regard, so this is a good thing for master.
* Delete tra_dbcreators_list in ~jrd_tra If we don't delete it manually assert will be thrown if SEC$DB_CREATORS returns a lot of records * Add missing default initialization for tra_dbcreators_list --------- Co-authored-by: Artyom Ivanov <artyom.ivanov@red-soft.ru>
* Delete tra_dbcreators_list in ~jrd_tra If we don't delete it manually assert will be thrown if SEC$DB_CREATORS returns a lot of records * Add missing default initialization for tra_dbcreators_list --------- Co-authored-by: Artyom Ivanov <artyom.ivanov@red-soft.ru>
I found that if we try to write a lot of records to
RecordBuffer
(>MIN_TEMP_BLOCK_SIZE) we start increasingm_tempCacheUsage
. When we don't needRecordBuffer
anymore, it will be destroyed in~SnapshotData()
, which will call~TempSpace()
forFirebird::AutoPtr<TempSpace> space
, and in~TempSpace()
we will decreasem_tempCacheUsage
.But this doesn't apply to
tra_dbcreators_list
because we delete it by dropping the transaction pool, so destructor doesn't kick in and we don't decreasem_tempCacheUsage
. All of this will causefb_assert(m_tempCacheUsage == 0)
to be thrown, but I don't know what this might lead to in release build (nothing good, I suppose).This is also true for Firebird 5.0.