Firebird 2.5.3+SQLDB crashes Lazarus IDE & compiled app when close connection ! lazarus / 16-Databases ---------------------------------------------------------------------- patyi · 2014-08-06 22:11 Hi all ! Yesterday I upgraded the Firebird SQL server (superclassic 2.5.2 -> 2.5.3 xubuntu i386) version and then the Lazarus IDE and the compiled application is without any error message crashes when database connection is disconnecting. This happens using SQLDB package. Zeos 7.2 work correct ! FlameRobin and IBExpert work normally, database is sweeped, validated, no limbo transactions ... Please can someone confirm this ? Or something is wrong on my installation ? this is tested on fallowing configuration: fpc 2.6.5 svn, fpc 2.7.1 svn, Lazarus 1.3 svn, SqlDB, Zeos 7.2 trunc,  Firebird 2.5.3 from ubuntu repositoty, xubuntu 14.04 i386 ---------------------------------------------------------------------- rvk · 2014-08-06 22:52 Maybe this is the same issue BigChimp had here: http://forum.lazarus.freepascal.org/index.php/topic,25380.0.html It is confirmed that with the client fbembed.dll 2.5.3.26778 (on Windows) you'll get a crash when closing the database connection. The normal fbclient.dll works correctly. BigChimp had a similar issue on Debian: http://forum.lazarus.freepascal.org/index.php/topic,25220.0.html I'm not sure which client was used there (fbclient or fbembed) but if the same base-code is used for Windows and Linux for the fbembed it could have the same problems (crashing a few moments after issueing a close on the connection). Do you know what library the SQLDB package uses for the Firebird connection? Is it the same library Zeos 7.2 uses? ---------------------------------------------------------------------- patyi · 2014-08-07 06:17 Hi rvk ! I use libfbclient.so.2.5.3 (not try embedded version) with SqlDB. Zeos 7.2 is using the same library and work Ok. ! ---------------------------------------------------------------------- rvk · 2014-08-07 07:22 Could you try the sample program I mentioned in this post: http://forum.lazarus.freepascal.org/index.php/topic,25380.msg154164.ht ml#msg154164 (Changing the variables to use your db and server) It would be interesting to know if it crashes too. If it does with that components maybe the code in zeos holds a solution to make these one work too. Which connection component did you use? Perhaps you could strip down the code to just the connection and disconnection and if that fails too post the code here. ---------------------------------------------------------------------- BigChimp · 2014-08-07 09:05 Working on a patch; the attached patch (against trunk) seems to fix issues with the embedded client but needs to be - tested - redone so it doesn't break compatibility with Firebird < 2.5 and Interbase You could try it and see if it fixes your problem... ---------------------------------------------------------------------- rvk · 2014-08-07 10:29 Quote from: BigChimp on August 07, 2014, 11:05:29 amWorking on a patch; That does seem to solve the issue for fbembed.dll  (with my zero knowledge i struggled to apply this fix to the standard install of fpc 2.6.4 and hope i did it right) But before fixing this permanently... Isn't this a bug in fbembed itself? (and also seeing that fbclient on Windows doesn't suffer from this problem) Should this be fixed in fpc with the possibility when it is fixed in fbembed you get other side effects? New API call in Firebird 2.5 to shutdown server Quotefb_shutdown() performs smart shutdown of various Firebird subsystems (yValve, engine, redirector). ... Normally it should not be used, because Firebird libraries (both kinds - embedded or pure client) do call it automatically at exit().But you've already discovered that judging at your Firebird-tracker entry. Another question... does this fix also work for your problem on the Debian installation? Here patyi has the problem with  libfbclient.so.2.5.3. (I'm not sure if you had the same problem with the same library). But perhaps for Linux the problem is both in  libfbclient.so and libfbembed.so. If this is the same problem (needing to call fb_shutdown) the Firebird-tracker needs to be changed to include Linux and maybe raised to major (instead of minor). In your fbembedshutdown.diff you did define a FB25UP but forgot to use it for the call to fb_shutdown in ibconnection.pp  So when removing the define it will result in a compilation error that fb_shutdown is not found. But that's all academic because it needs to be rewritten to only work for certain fbclients (if it is decided not to wait for the Firebird fix because i still think it is a bug in Firebird). ---------------------------------------------------------------------- BigChimp · 2014-08-07 10:38 Quote from: rvk on August 07, 2014, 12:29:09 pmBut before fixing this permanently... Isn't this a bug in fbembed itself? (and also seeing that fbclient on Windows doesn't suffer from this problem) No, the Firebird devs indicate you need to call fb_shutdown, see the firebird bug report linked to in the fpc bug report. Obviously fbclient doesn't suffer from this because fb_shutdown should have no effect there. Quote from: rvk on August 07, 2014, 12:29:09 pmNew API call in Firebird 2.5 to shutdown server Quotefb_shutdown() performs smart shutdown of various Firebird subsystems (yValve, engine, redirector). ... Normally it should not be used, because Firebird libraries (both kinds - embedded or pure client) do call it automatically at exit().But you've already discovered that judging at your Firebird-tracker entry. Yes. And as I indicated there that doc should be changed because apparently is incorrect. Quote from: rvk on August 07, 2014, 12:29:09 pmAnother question... does this fix also work for your problem on the Debian installation? Here patyi has the problem with  libfbclient.so.2.5.3. (I'm not sure if you had the same problem with the same library). But perhaps for Linux the problem is both in  libfbclient.so and libfbembed.so. Haven't tested yet. First going to run dbtestframework on windows to check for regressions. Quote from: rvk on August 07, 2014, 12:29:09 pmIf this is the same problem (needing to call fb_shutdown) the Firebird-tracker needs to be changed to include Linux and maybe raised to major (instead of minor). I don't really care as long as the problem is solved. Quote from: rvk on August 07, 2014, 12:29:09 pm In your fbembedshutdown.diff you did define a FB25UP but forgot to use it for the call to fb_shutdown in ibconnection.pp  So when removing the define it will result in a compilation error that fb_shutdown is not found. Thanks will have a look. It's always better to have tidy code however temporary it may seem Quote from: rvk on August 07, 2014, 12:29:09 pmBut that's all academic because it needs to be rewritten to only work for certain fbclients (if it is decided not to wait for the Firebird fix because i still think it is a bug in Firebird). Please comment when you've also read the yahoo messages discussion linked to on the FIrebird bug Also, any Firebird fix will not fix existing FB2.5 installs. Sure, a fix in Firebird might break the fix in FPC; if so we'll need to fix the fix Finally, because the change in the patch means effectively splitting up Firebird 2.5 and older Firebird/Interbase, there will need to be a discussion with other FPC db devs on how/whether to do that. So this may take a while. ---------------------------------------------------------------------- rvk · 2014-08-07 12:23 Alright, i now get that they are saying at Firebird that you need to call fb_shutdown before unloading the library... for fbembed.dll. But... with your changes implemented here... When i create 2 TIBConnections to the same database (this should be possible with a server-version) after disconnecting one the other gets disconnected too (giving me an error when i try to disconnect that one). The fb_shutdown should only be called if the RefCount in ibase60.inc is 0, so only if the UnloadLibrary is really called. See ReleaseIBase60 in ibase60.inc where the library only gets unloaded when there is no more references to it. Maybe move the fb_shutdown to that procedure? Or do a check after ReleaseIBase60 in ibconnection.pp to see if the library is still loaded and if not then call fb_shutdown. Or am i completely off-base here? ---------------------------------------------------------------------- BigChimp · 2014-08-07 12:24 You're right, I realized already fb_shutdown should only be called when uploading - please try the patch in the bugtracker instead. Comments welcome... currently testing on Linux. ---------------------------------------------------------------------- BigChimp · 2014-08-07 13:49 Updated patch to avoid conditional compilation. Works fine on Windows; haven't tested this one on Linux (but don't see why it should be problematic) ---------------------------------------------------------------------- BigChimp · 2014-08-08 08:40 Committed in trunk - thanks for the help, rvk! ---------------------------------------------------------------------- patyi · 2014-08-11 20:08 Thanks to everyone ! Now the FPC 2.7.1 svn (trunc) okay (Xubuntu 14.04 i386), we tested it, it seems to be okay. For the FPC 2.6.5 can be done  same  ? I can not use the 2.7.1 svn (trunc) mainly because of the Fortes4Lazarus report generator is unstable. (on XUbuntu 14,04 i386) Regards, Patyi. ---------------------------------------------------------------------- BigChimp · 2014-08-12 08:15 There are no plans to backport trunk fixes to 2.6.x, sorry. You can do it yourself of course, based on the patch in the bugtracker. ---------------------------------------------------------------------- Zoran · 2014-08-12 09:00 Quote from: BigChimp on August 12, 2014, 10:15:55 amThere are no plans to backport trunk fixes to 2.6.x, sorry. Why not? Isn't it a bug fix, not introducing new feature? ---------------------------------------------------------------------- BigChimp · 2014-08-12 09:48 Because AFAIK there no plans to release a new 2.6.x based on the 2.6.x code. Instead, the next stable release will be based on 2.7.1 ---------------------------------------------------------------------- Zoran · 2014-08-12 11:37 Quote from: BigChimp on August 12, 2014, 11:48:08 amBecause AFAIK there no plans to release a new 2.6.x based on the 2.6.x code. Instead, the next stable release will be based on 2.7.1 But, as far as I know, we are still far from 2.8 (or perhaps it will be 3.0) release! I would expect the stable "fixes" branch to be regularly updated until next major release. The longer it takes to new release, then more "fixes" subreleases should come out. But now they abandoned the fixes branch already, although next release will not be released in many months (probably a year or even more). Isn't that wrong? Isn't taking care of the stable branch actually more important than further development for a serious product? ---------------------------------------------------------------------- BigChimp · 2014-08-12 12:28 Well, in a serious product the compiler should be fairlgy bug free already, so a time without fixes wouldn't be so bad. As I said, people can maintain their own backports; perhaps FPC devs would welcome volunteers who want to maintain a fixes 2.6 branch. I'd suggest discussing this on the fpc-devel mailing list as you'll probably get more FPC devs there... ---------------------------------------------------------------------- Zoran · 2014-08-12 12:47 Quote from: BigChimp on August 12, 2014, 02:28:19 pmWell, in a serious product the compiler should be fairlgy bug free already, so a time without fixes wouldn't be so bad. Anyway, if bugs appear, the fixes are needed. Quote from: BigChimp on August 12, 2014, 02:28:19 pmAs I said, people can maintain their own backports; Ordinary user should not be expected to do this. Quote from: BigChimp on August 12, 2014, 02:28:19 pm; perhaps FPC devs would welcome volunteers who want to maintain a fixes 2.6 branch. Perhaps. And of course, nobody is to blame, when we know that every developer does it for free, at his own time. If he prefers to spend his time improving the future version and not maintain the stable, perhaps because he finds it boring — well, we have to respect that. And, BigChimp, I must not forget — thanks for the patch. ---------------------------------------------------------------------- BigChimp · 2014-08-12 12:56 Thanks for your post. Re ordinary users: I wonder. I suspect most of them even want to have some kind of updates download instead of using svn :0 And then they want Lazarus incorporated with these fixes. But I might be wrong. Re the patch - my pleasure - it fixes my problems, too ---------------------------------------------------------------------- LacaK · 2014-08-13 05:13 Quote from: Zoran on August 12, 2014, 01:37:36 pmBut, as far as I know, we are still far from 2.8 (or perhaps it will be 3.0) release! I would expect the stable "fixes" branch to be regularly updated until next major release. The longer it takes to new release, then more "fixes" subreleases should come out. This is my feeling also  As this is relative serious bug IMO it should be fixed and released to users ASAP. I understand , that there is no plan for release FPC 2.6.6 or so, but why not let Lazarus team to release Lazarus with patched FPC 2.6.4 (it is not important if we will call it 2.6.4a or 2.6.5) ? (as Lazarus releases are more often than FPC)