[#CORE-2326] Access Violation when committing new view while trigger on rdb$relations in place

Firebird Core

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

Created: 16/Feb/09 12:22 PM Updated: 18/Feb/09 05:25 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

Time Tracking:

Not Specified

File Attachments:	1. drwatson_log_fb_crash_20090216_rdbrelations_views_trigger.txt (81 kB) 2. procedure_trigger_view_customize_protection.txt (4 kB)
Environment:	SuperServer Win32 (PDB)

Planning Status:

Unspecified

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

Work Log

Change History

Version Control

FishEye

Sort Order:

[ Permalink | « Hide ]

Philip Williams added a comment - 16/Feb/09 12:22 PM

Dr Watson log file from server AV

[ Permalink | « Hide ]

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.)

[ Permalink | « Hide ]

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.

[ Permalink | « Hide ]

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.

[ Permalink | « Hide ]

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.