Skip to content
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

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

Closed
firebird-automations opened this issue May 17, 2019 · 12 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @AlexPeshkoff

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.

Commits: f9f22af

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

This bug was fixed in FB3 by Adriano when reworking layout of class jrd_prc.

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.5.9 [ 10862 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

Alex,

Are you saying:

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

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Yes Sean - it's correct

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

summary: Segfaults when procedures are permanently created, altered and dropped => Segfaults can (sometimes) result when DDL operations are performed against Stored Procedures under active database/multi-user access conditions.

@firebird-automations
Copy link
Collaborator Author

Commented by: Omacht András (aomacht)

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

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: Omacht András (aomacht)

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

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: No test => Cannot be tested

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment