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
Comments
Modified by: @AlexPeshkoffassignee: Alexander Peshkov [ alexpeshkoff ] |
Commented by: @AlexPeshkoff This bug was fixed in FB3 by Adriano when reworking layout of class jrd_prc. |
Modified by: @AlexPeshkoffstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 2.5.9 [ 10862 ] |
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. |
Commented by: @AlexPeshkoff Yes Sean - it's correct |
Modified by: @AlexPeshkoffsummary: 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. |
Commented by: Omacht András (aomacht) Alex, "random block of memory" means data pages too, or "just" program codes? András |
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. |
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). And, we are creating and dropping tables, views and stored procedures. But, we never get segfaults... András |
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 |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: No test => Cannot be tested |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Closed [ 6 ] |
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
The text was updated successfully, but these errors were encountered: