Subject RE: UDF sandbox?... (was: Re: [Firebird-Architect] Re: Database level triggers)
Author Claudio Valderrama C.
Martijn Tonies wrote:
>> Does this means that calls to UDF function from the server code are
>> not wrapped in a SEH bracket (Win32) or even a C++ catch-all
>> exception ? It would allow the server to recover and emit an error
>> instead of going mad...

UDF calls are protected. The problem is how the engine handles the errors.
There are different errors, like CPU's flags conditions (overflow), logic
math errors (division by zero) and bad code (null pointer exception), etc. I
think there's no question an access violation (or equivalent in other OS)
should cause the engine to shut down itself. Now, why math/flags errors are
treated this way is not documented, but it makes a bit of sense if you think
there's no defined mechanism for an UDF to return a condition to the engine.
Since a division by zero caused the UDF code to abort, what should be the
result of the udf call? Garbage? An engine exception like the dreaded
"arithmetic exception or string truncation" that stops the execution of the
request? I'm not saying it's the best behavior, but what's proposed instead?
To provide the UDF with the memory address of a flag set it can manipulate?
It would require all UDFs to have proper exception handling inside them.


> I'm not sure - (didn't check the code). From an access violation, for
> example, the server crashes/shuts down, which pretty much makes
> sense (you don't know what happened in the server memory/code
> space). But for a divide by zero, raising an exception would be good
> enough I guess.

In old times, in the very first versions of Windows, MS alleged that it
couldn't trap CPU exceptions, so users complained that any program making a
division by zero in Windows v2 would cause the pseudo-OS to die. I never
used those versions, so I can't comment on the accuracy of the story.

The current code that protects UDF calls in the engine is an ugly macro that
has definitions for all operating systems used. IIRC, in Unix some signals
produce the same fatal effect when they are caused by a UDF. Maybe we could
separate the pure-logical errors from the rest and provide a better
handling.

C.