Issue Details (XML | Word | Printable)

Key: CORE-6064
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Alexander Peshkov
Votes: 0
Watchers: 2
Operations

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

Segfaults can (sometimes) result when DDL operations are performed against Stored Procedures under active database/multi-user access conditions.

Created: 17/May/19 02:26 PM   Updated: 04/Jun/19 04:59 PM
Component/s: None
Affects Version/s: 2.5.0, 2.5.1, 2.5.2, 2.5.2 Update 1, 2.5.3, 2.1.7, 2.5.3 Update 1, 2.5.4, 2.5.5, 2.5.6, 2.5.7, 2.5.8
Fix Version/s: 2.5.9

Environment: Classic / superclassic

QA Status: Cannot be tested


 Description  « Hide
When during normal database operation (I mean multi-user database access) procedures are permanently created, altered and dropped under unsuccessful circumstances almost random block of memory may be overwritten with an array of procedure format blocks.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 17/May/19 02:27 PM
This bug was fixed in FB3 by Adriano when reworking layout of class jrd_prc.

Sean Leyne added a comment - 17/May/19 02:38 PM - edited
Alex,

Are you saying:

Segfaults can (sometimes) result when DDL operations are performed against Stored Procedures under active database/multi-user access conditions.

Alexander Peshkov added a comment - 20/May/19 09:18 AM
Yes Sean - it's correct

Omacht András added a comment - 21/May/19 05:15 AM
Alex,

"random block of memory" means data pages too, or "just" program codes?
In other words is it possible that the data part of the database is corrupted?

András

Alexander Peshkov added a comment - 21/May/19 07:48 AM - edited
András, program codes are not corrupted (hmm, they are read-only for many years in known to me OSes). Only data pages may be corrupted - what place depends upon current structure of DBB memory pool which after some time of engine operation is close to what we call pseudo-random place. I've never seen such corruption in DB pages cache - but this does not mean it's impossible specially when very small cache size (like default for classic server) is used. With large caches it can hardly happen - big pages used for such cache are placed by MemoryPool in another memory area, i.e. far from procedure format.

Omacht András added a comment - 21/May/19 08:55 AM
Thanks Alex.

I mean program codes == stored procedures BLR codes.

Sometimes we have strange errors, "old" data (surely last edited days or months ago) lost from database (the daily backup and restore shows foreign key error, and we have to insert the parent record back from previous backup).
I'm 100% sure this data pages are frequently used for read, but not write, and we could never reproduce this behavior....

And, we are creating and dropping tables, views and stored procedures.

But, we never get segfaults...

András

Alexander Peshkov added a comment - 21/May/19 09:11 AM - edited
yes, both BLR and produced from it execution tree might be damaged

what I do not believe is loosing records instead segfault after that damage