Linux x64 "try (finally/except) end" breaks things that mess up dynamic linking under LINUX with (dlopen/dlclose) when external threading really occurs.
Summary
I wrote a C library for Firebird many years ago and ported it to FPC a little over two years ago. The C library has worked without problems for years. However, the FPC library has led to SIGSEGV , which I first attributed to Firebird itself. Since it only happened once a week, I didn't care for a long time. After 3 days of intensive testing I found out that the problem lies with FPC and more precisely with "try (finally/except) end". Since a Firebird "UDF/UDR" is a plugin, which is not known at compile time of Firebird, it must be used with "dlopen/dlclose). Firebird itself (Superserver) is highly modular and loads this module via a module responsible for it. The SIGSEGV exception occurs whenever the module that loaded the FPC UDF is unloaded. This happens quite directly after the last DB connection has been closed. First the FPC-UDF(Plugin) is unloaded and then (approx. 1min) the module which is responsible for loading the Plugin. That the exception occurs only once a week has several reasons. Server processes that always run keep the plugin loaded or it was never used threaded. Thus the problem can remain undetected for a long time.
Again the points that must be met to get the problem(SIGSEGV on unload).
- "try (finally/except) end" must be used in the FPC library.
- the library must have been used multithreaded by the server.
To create multithreading I used 8 simultaneous connections to the plugin (UDF). This was sufficient for 100% reproducibility. e.g. two connections are not sufficient.
I hope that the explanation is understandable. If there are any ideas that could solve the problem, I would like to test them. At the "IFEDFS" in the example code, you can see which combinations I have already tested. I haven't tested it on Windows yet, as it is secondary for me as a server system.
System Information
Linux Ubtuntu x86-64 all ( 16.04/18.04/20.04 DatiscumPlus_UDF_TestVersion.tar.bz2)
Steps to reproduce
Install Firebird Database server. Copy the created library from the sample code to the UDF folder. Use the PLUGIN (UDF) with a test program that establishes at least 8 connections to the fitebird server. I can also provide my test program compiled. When all connections are established wait about one minute and see if the server crashes with a SIGSEGV.
Example Project
Attached DatiscumPlus_UDF_TestVersion.tar.bz2
What is the current bug behavior?
SIGSEGV exception
What is the expected (correct) behavior?
No SIGSEGV exception.
Relevant logs and/or screenshots
Possible fixes
None