A Linux UDR library for Firebird should be forgotten very quickly. When you have read this, you see the pitfalls of the whole thing.
https://gitlab.com/freepascal.org/fpc/source/-/issues/39531
Your post is interesting. I have yet to see the problem with Pascal UDRs that you are reporting. Perhaps you would like to try out the current beta version that is available at
https://svn.mwasoftware.co.uk/viewvc/public/ibx/branches/udr/There is a UDR user guide in the doc folder.
In the udr/testsuite/udrlib folder you will find a ready made example UDR complete with SQL scripts to add the test functions, procedures and triggers to a DB and to then to exercise their use. Some of the examples assume the Firebrd example employee database. There is also a runtest.sh script to automate the whole compile - install - test cycle. But that does assume a specific firebird installation in /opt (on Linux of course).
It would be interesting to know if you can duplicate your problem.
SIGSEGV signals are a general problem, as you observe. In testing they have occurred whenever you get a bad memory reference and can crash the process. Firebird SuperClassic seems to be best here. When writing a UDR, you do have to be extra careful to avoid these by being paranoid when it comes to checking pointers and object references.
Exception handling in the UDR is something that I have paid considerable attention to. All calls the UDR library are protected within try..except blocks so that Pascal Exceptions can be translated into Firebird status vectors and thus returned to the client.
You are having a specific problem on UDR unload. I am wondering if your problem is with the very Firebird specific unload mechanism. You need to emulate the C++ static class "UnloadDetector". This does sound like where your problem may be. In my UDR implementation, the TFBUDRController class includes this functionality and seems to work well.