Subject | RE: UDF sandbox?... (was: Re: [Firebird-Architect] Re: Database level triggers) |
---|---|
Author | Claudio Valderrama C. |
Post date | 2003-07-31T07:51:57Z |
Martijn Tonies wrote:
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.
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.
>> Does this means that calls to UDF function from the server code areUDF calls are protected. The problem is how the engine handles the errors.
>> 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...
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, forIn old times, in the very first versions of Windows, MS alleged that it
> 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.
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.