On 10/27/16 10:57, Stephan Bergmann wrote: > When building Firebird 3.0 as part of LibreOffice (on Linux), it > occasionally happens that the build fails with > > ... >> rm -f ../../gen/examples/employee.fdb >> ./empbuild ../../gen/examples/employee.fdb >> creating database ../../gen/examples/employee.fdb >> Turning forced writes off >> Couldn't turn forced writes off (139) >> Makefile.examples:125: recipe for target '../../gen/examples/employee.fdb' >> failed > (I've patched examples/empbuild/empbuild.e to print the failed process's > exit status, 139 i.e. SIGSEGV, > <https://cgit.freedesktop.org/libreoffice/core/commit/?id=128e7ce3ffa50b11b2d5ff9777a27b095a84e5d7> > "external/firebird: Try track down 'Couldn't turn forced writes off' > failure"). > > Looking at the core file of the SIGSEGV'ed 'gfix -write async > ../../gen/examples/employee.fdb' (see below), it smells like thread 1 is > executing code in some .so while another hread called dlcose on that .so > (there's a call to dlcose in ~DlfcnModule in > src/common/os/posix/mod_loader.cpp). Is this a known problem/could my > assumption be right? >
Your assumption seems to be right. I've used to see such stacks before but could not reproduce it locally. How stable is it bug reproduced for you? If rather stable, can you uncomment debugging macro //#define DEBUG_PLUGINS near lines 50-55 in src/yvalve/PluginManager.cpp. This should print (except others) line: resetCleanup() of module <name of unloaded .so> and (I hope) help me reproduce a bug locally and finally fix it. ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
