Menu
▾
▴
[Firebird-devel] [ firebird-Bugs-919246 ] Exception/Freeze in gds32
|
From: SourceForge.net <no...@so...> - 2004-03-25 05:25:56
|
Bugs item #919246, was opened at 2004-03-19 06:22 Message generated for change (Comment added) made by skidder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109028&aid=919246&group_id=9028 Category: API/Client library Group: Confirmed Bug Status: Open Resolution: None Priority: 9 Submitted By: Rohit Gupta (rohitgupta) Assigned to: Nobody/Anonymous (nobody) Summary: Exception/Freeze in gds32 Initial Comment: Using tcpip, application freezes because of either an access violation in gds32 or gds32 itself freezing. Sometimes any other tcpip-connection to the same database is rejected, but api-connection is accepted. Other times only the one client is locked. Problem happens - with all firebird versions 1.0 - 1.5final - on any workstation 98/2000/XP - on any server 98/2000/Xp/2003/Linux What we know - Interbase 7.1 works. A developer had the same issue with Interbase and Borland have fixed it. - Three other developers with same problems have dumped firebird and gone to interbase. - Users can repeat it 10-30 times a day, we can reproduce it in 20-30 mins but it is impossible to write a test app - we have spent over 240 hrs trying to. What we suspect - Its either a memory write or stack corruption problem. This is a considered opinion of a number of very experienced programmers trying to battle this for about 18 months. The problem incidence fell sharply with FB1.2 but as number of users increased, it was back. Dump from madexcept follows :- main thread ($22c): 77f87e77 ntdll.dll NtWaitForMultipleObjects 77e879b0 kernel32.dll WaitForMultipleObjectsEx 77e9e685 kernel32.dll WaitForMultipleObjects 1000f77e gds32.dll gds__thread_enter 1001757e gds32.dll isc_start_multiple 0050f440 VETLINK.EXE IB_Components 1522 TIB_Transaction.API_Start 0050d863 VETLINK.EXE IB_Components 594 TIB_Transaction.SysStart 005150b8 VETLINK.EXE IB_Components 1365 TIB_Statement.CheckTransaction 00516570 VETLINK.EXE IB_Components 1883 TIB_Statement.SysExecute 0051f9f2 VETLINK.EXE IB_Components 1990 TIB_Dataset.SysExecute 0051f191 VETLINK.EXE IB_Components 1791 TIB_Dataset.SysOpen 00557f8c VETLINK.EXE IBODataset 5636 TIBODataset. DoBeforeOpen Using tdimon - it fails after the server has sent it a packet and teh client freezes after the last packet has been logged as received by the app. ---------------------------------------------------------------------- Comment By: Nickolay Samofatov (skidder) Date: 2004-03-25 08:25 Message: Logged In: YES user_id=495356 I received accurate comments on this issue from Dmitry Emanov and not-so-accurate, but having the same general meaning comments from Jim Starkey. IBO practice is considered legitimate and fix for Firebird is committed into CVS HEAD. I hope that my commit fixes all possibilities for the problem, but since many layers of engine are involved I cannot be 100% sure. Note that using IBO statement caching is still unsafe for FB 1.0.X, 1.5.0 and many Interbase versions. ---------------------------------------------------------------------- Comment By: Nickolay Samofatov (skidder) Date: 2004-03-25 01:10 Message: Logged In: YES user_id=495356 Solution is to set IB_Connection.CacheStatementHandles to FALSE. IBO statement handles caching code is not correct at least for FB1, IB6, FB 1.5 and 2.0. ---------------------------------------------------------------------- Comment By: Nickolay Samofatov (skidder) Date: 2004-03-19 21:06 Message: Logged In: YES user_id=495356 send it to: nickolay _at_ broadviewsoftware dot com ---------------------------------------------------------------------- Comment By: Ryan J. Mills (rjmills) Date: 2004-03-19 20:30 Message: Logged In: YES user_id=351844 I have just come across the same bug for fb1.5 (but not fb1.03). I want it noted that if I use a local connection instead of tcp_ip, the error does not occur at all for me. I've also managed to produce a reproducable test case using Delphi and IBObjects. How/where do I submit the test case? ---------------------------------------------------------------------- Comment By: Nickolay Samofatov (skidder) Date: 2004-03-19 07:41 Message: Logged In: YES user_id=495356 BTW3, I doubt great experience of mentioned developers who spent 18 months on that since Firebird has program databases and source publicly available. Given this data tracing out a reason of crash should not take longer than a few days for any moderately experienced C/C++ programmer. ---------------------------------------------------------------------- Comment By: Nickolay Samofatov (skidder) Date: 2004-03-19 07:32 Message: Logged In: YES user_id=495356 Ok. Install client library from zipped package (!) and take full dump when crash happens. Standard drwtsn32.exe tool is one of the tools capable of doing this. Given the dump most problems may be analysed and fixed. You can send it to me directly. BTW, are you sure that you are using client library from 1.5 Final? I have seen exactly this dump and fixed its reason. BTW2, are you sure that you decouple IBO sessions and threads correctly? In any case dump will tell if this error is coming from application side. ---------------------------------------------------------------------- Comment By: Rohit Gupta (rohitgupta) Date: 2004-03-19 06:34 Message: Logged In: YES user_id=1001532 This sounds like the same problem as the following except we do not use events. [ 740310 ] GDS32.dll Access Violations, Events ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109028&aid=919246&group_id=9028 |
