Issue Details (XML | Word | Printable)

Key: CORE-3208
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: Dmitry Yemanov
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.
Firebird Core

Significant memory leaks with recursive queries

Created: 01/Nov/10 07:12 AM   Updated: 19/Jul/15 01:42 PM
Component/s: Engine
Affects Version/s: 2.5.0
Fix Version/s: 2.1.4, 2.5.1, 3.0 Alpha 1

QA Status: Not enough information
Test Details:
Could not reproduce on 2.5.0 with trivial AI trigger which uses recursive query as source to insert statement.
Any hint about how test can be done will be appreciated.

 Description  « Hide
Recursive queries may leak some amount of memory from the request pool. This may be a big problem if the request is a trigger or a procedure, as this memory never gets deallocated until disconnection (or trigger/procedure recompile). In the test I have at hands (cannot be shared, unfortunately) every insert leaks about 20MB because of this issue (WITH RECURSIVE in the AFTER INSERT trigger).

All the leaked memory chunks are allocated in VIO_record():
record = rpb->rpb_record = FB_NEW_RPT(*pool, format->fmt_length) Record(*pool);
and lost after this code in RSBRecurse::get():
// Don't overwrite record contents at next level of recursion.
// RSE_open and company will allocate new record if needed
rpb->rpb_record = NULL;

I have tried the following solution in RSBRecurse::close():

char* tmp = irsb->irsb_stack;
memcpy(irsb, tmp, inner_size);

+ char* p = tmp + inner_size;
+ for (int i = 0; i < streams; i++)
+ {
+ record_param* rpb = (record_param*) p;
+ delete rpb->rpb_record;
+ p += sizeof(record_param);
+ }

delete[] tmp;

and it seems to help (leaks disappear). Maybe a better solution could be suggested instead.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
There are no comments yet on this issue.