[Firebird-devel] [ firebird-Bugs-919246 ] Exception/Freeze in gds32

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Bugs item #919246, was opened at 2004-03-19 03:22
Message generated for change (Comment added) made by pahom
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: Andrew Pahomov (pahom)
Date: 2004-05-25 08:29

Message:
Logged In: YES 
user_id=1049197

Hi All!

Looks like this bug the same as 837925 and 740310.

The problem in auxiliary connection for event firing 
in "./src/remote/inet.cpp". Look disconnect(Port* port) 
method :

	else if (port->port_async) {
#ifdef MULTI_THREAD

		port->port_async->port_flags |= 
PORT_disconnect;

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(in this line occurs access violation)
#else
		disconnect(port->port_async);
		port->port_async = NULL;
#endif
	}

But at this moment "port_async" already disconnected and 
freed through call "server_death" procedure.

I've propose my quick and dirty solution (implemented and 
tested)

1) add 
	struct port*	port_owner;		
	/* port owner */

   to "port" structure in "remote.h" header file.
Because when async port allocated through call "alloc_port"
it takes as parent port not parent but port->port_parent;

2) add next code to inet.cpp methods "aux_connect" 
and "aux_request":
(old code)
	port->port_async = new_port = alloc_port(port-
>port_parent);
(new code)
	port->port_async = new_port = alloc_port(port-
>port_parent);
	new_port->port_owner = port;

and add to "disconnect"  method:
(old code)
	if (port->port_handle) {
		SOCLOSE((SOCKET) port->port_handle);
	}

	gds__unregister_cleanup(exit_handler, (void *) 
port);

(new code)
	if (port->port_handle) {
		SOCLOSE((SOCKET) port->port_handle);
	}

	if (port->port_flags & PORT_async)
	{
	 if(port->port_owner)	
	 {
	   port->port_owner->port_async = NULL;
	 }
	}
	gds__unregister_cleanup(exit_handler, (void *) 
port);

and enjoy ;-)

PS: Sorry for my terrible english pronounce :)

----------------------------------------------------------------------

Comment By: Nickolay Samofatov (skidder)
Date: 2004-03-25 05: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-24 22: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 18: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 17: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 04: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 04: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 03: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

[Firebird-devel] [ firebird-Bugs-919246 ] Exception/Freeze in gds32

A powerful, cross platform, SQL database system

[Firebird-devel] [ firebird-Bugs-919246 ] Exception/Freeze in gds32