Issue Details (XML | Word | Printable)

Key: CORE-1575
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Critical Critical
Assignee: Dmitry Yemanov
Reporter: Daniel Bauten
Votes: 1
Watchers: 4
Operations

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

serious memory bug on multiple update a table in a single transaction

Created: 08/Nov/07 07:46 AM   Updated: 23/Feb/11 01:17 PM
Component/s: Engine
Affects Version/s: 2.0.2, 2.0.3, 2.1 Beta 2
Fix Version/s: 2.5 Beta 1

Time Tracking:
Not Specified

File Attachments: 1. Zip Archive MemoryBug.zip (2.60 MB)

Environment: Windows Vista Business, 2 GB RAM, Firebird 2.0.3 Super Server
Issue Links:
Relate

Target: 2.5.0


 Description  « Hide
Dear all,

I found a serious bug leading Firebird in allocating a very large amount of RAM - in my example (with 80.000 records) it crashes after allocating 1.7 GB of RAM.

You can reproduce this bug by using the attached database "MemoryBug.fdb" by execute the following two queries WITHOUT commiting after the first query.

Query A:
======

update mytable
  set CIS = 0;

==> Firebird uses (with my DefaultDBCachePages) approx. 90 MB of RAM.

Query B:
======

update mytable
  set CIS = 1;

==> use of RAM for the Firebird servers grows in a few seconds up to 1.7 GB + and crashes.


Note 1: It seems that updating records several times in the SAME transaction leads in this bug. If one commits after the first query, every works fine.

Note 2: Using a stored procedure including the two above statements DOESN'T lead in growing memory that much (just up to about 180 MB in my case).

Note 3: Using tables with less fields as in my example seems to work correctly. Therefore: Use my example database to reproduce the bug!

Note 4: I guess the bug reported by Eugene Kuznetsov in CORE-1477 is the same.

It is essential for the further development of my project to have a solution for this. So please, let me know, when this bug will be fixed.

Thanks in advance.

Daniel Bauten


 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Daniel Bauten added a comment - 08/Nov/07 07:50 AM - edited
A small database with one table ('MYTABLE') containing about 80.000 records.

Just use the following two queries WITHOUT commiting after the first one to "see" the bug reported in CORE-1575.

update mytable
  set CIS = 0;

update mytable
  set CIS = 1;

Daniel Bauten added a comment - 26/Nov/07 02:49 AM
Dear Dmitry,

three years ago for „CORE-381" you wrote that this is a design pitfall...

As I mentioned this bug leads in several problems for my actual project. Can you tell me when this will be fixed?

Thanks in advance for your help, Dmitry.

Daniel

Dmitry Yemanov added a comment - 26/Nov/07 03:17 AM
Second update in the same transaction transforms the delta record to a full record version, hence requiring more I/O. This is by design and unlikely to change. The big memory consumption is another (although related) issue which hopefully can be optimized. I have a draft solution ready, but it requires some more work.

Daniel Bauten added a comment - 26/Nov/07 03:51 AM
I see. Then I will check the memory consumption for "my database" after CORE-1477 is fixed. As you have a draft solution, is it possible to fix the big memory consumption (i.e. CORE-1477) in Firebird 2.1 Final?