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
Access Violation when committing new view while trigger on rdb$relations in place [CORE2326] #2750
Comments
Commented by: Philip Williams (unordained) Dr Watson log file from server AV |
Modified by: Philip Williams (unordained)Attachment: drwatson_log_fb_crash_20090216_rdbrelations_views_trigger.txt [ 11360 ] |
Commented by: Philip Williams (unordained) Triggers and procedures that resulted in the crash. (Minus the final statement that actually crashed it.) |
Modified by: Philip Williams (unordained)Attachment: procedure_trigger_view_customize_protection.txt [ 11361 ] |
Commented by: @dyemanov Your test case is incomplete, some procedures and functions are missing. |
Commented by: Philip Williams (unordained) It looks to me like only log_debug() UDF is missing, and it's not required. All it does is log text to disk. Did I miss something else? If triggers on system tables are not promised to work then I would recommend: I'm posting this here as a bug for reason c) because I'm concerned that I was able to segfault FB via non-sysdba DDL. That's not cool. It would of course be cool (as a separate feature request) if they could work reliably; they feel like they're not too far away from doing so as it is. I know I'm not the only one to have found a use for them. As for limits (for anyone who comes across this): system table triggers seem to work reliably until you do a gbak backup/restore, or you drop a database object. These actions, and possibly others, cause the triggers to be dropped silently. I have not attempted to place triggers on all system tables to make sure they all react the same way. I've certainly only tried it with rdb$ tables, not with mon$ tables. |
Commented by: @dyemanov Now I can confirm the crash. And I agree that triggers on system tables should not crash the server, it will be surely fixed. As for disabling them, maybe in v3.0 which will offer triggers for DDL operations as an official replacement. |
Modified by: @dyemanovassignee: Dmitry Yemanov [ dimitr ] |
Modified by: @dyemanovVersion: 2.0.5 [ 10222 ] Version: 2.0.4 [ 10211 ] Version: 2.1.0 [ 10041 ] Version: 1.5.5 [ 10220 ] Version: 2.0.3 [ 10200 ] Version: 2.0.2 [ 10130 ] Version: 2.0.1 [ 10090 ] Version: 1.5.4 [ 10100 ] Version: 2.0.0 [ 10091 ] |
Modified by: @dyemanovstatus: Open [ 1 ] => In Progress [ 3 ] |
Modified by: @dyemanovstatus: In Progress [ 3 ] => Open [ 1 ] |
Modified by: @dyemanovstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 2.1.3 [ 10302 ] |
Modified by: @dyemanovFix Version: 2.0.6 [ 10303 ] |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pavel-zotovQA Status: No test |
Submitted by: Philip Williams (unordained)
Attachments:
drwatson_log_fb_crash_20090216_rdbrelations_views_trigger.txt
procedure_trigger_view_customize_protection.txt
Triggers on rdb$procedures and rdb$triggers do not seem to cause access violations when creating or altering objects of those types, but a trigger on rdb$relations does. Once the trigger was in place and committed, I got an AV from simply doing:
create view x as select * from rdb$database;
I'm attaching both the scripts to setup the test case (which works for procedures and triggers, but not views), and the drwatson PDB output from the crash. (It's the log file, not the binary dump, let me know if you need the other.)
Commits: 5792f04 81bc7d3 f1d139f
The text was updated successfully, but these errors were encountered: