Issue Details (XML | Word | Printable)

Key: CORE-2326
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: Philip Williams
Votes: 0
Watchers: 1

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

Access Violation when committing new view while trigger on rdb$relations in place

Created: 16/Feb/09 12:22 PM   Updated: 19/Jan/16 04:45 AM
Component/s: Engine
Affects Version/s: 2.0.0, 1.5.4, 2.0.1, 2.0.2, 2.0.3, 1.5.5, 2.1.0, 2.0.4, 2.1.1, 2.0.5
Fix Version/s: 2.1.2, 2.0.6

File Attachments: 1. Text File drwatson_log_fb_crash_20090216_rdbrelations_views_trigger.txt (81 kB)
2. Text File procedure_trigger_view_customize_protection.txt (4 kB)

Environment: SuperServer Win32 (PDB)

QA Status: No test

 Description  « Hide
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.)

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Philip Williams added a comment - 16/Feb/09 12:22 PM
Dr Watson log file from server AV

Philip Williams added a comment - 16/Feb/09 12:24 PM
Triggers and procedures that resulted in the crash. (Minus the final statement that actually crashed it.)

Dmitry Yemanov added a comment - 17/Feb/09 05:30 AM
Your test case is incomplete, some procedures and functions are missing.
BTW, basically triggers on system tables were never promised to work, so your logic may stop working some day.

Philip Williams added a comment - 17/Feb/09 12:29 PM
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:
a) their limits should be documented (or a recommendation should be in place not to use them) -- I haven't seen this anywhere yet?
b) they should be disabled if they're actually unreliable (is there a current narrow use case where their unreliability is okay, and they're required?)
c) they should not crash the server.

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.

Dmitry Yemanov added a comment - 17/Feb/09 02:17 PM
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.