Issue Details (XML | Word | Printable)

Key: CORE-2679
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Alexandr N. Zamaraev
Votes: 2
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Do not correct exit applications with embedded server

Created: 13/Oct/09 12:10 PM   Updated: 04/Feb/11 11:26 AM
Component/s: None
Affects Version/s: 2.1.3
Fix Version/s: 2.1.4

Time Tracking:
Not Specified

File Attachments: 1. Text File embeded.txt (5 kB)

Environment:
Windows Vista Home Ru + sp2 + UAC
Python 2.6.2 (from python.org)
py2exe (py2exe-0.6.9.win32-py2.6.exe)
Qt 4.5.2 (self build mingw32 v 4.4.0)
PyQt 4.5.4 (self build mingw32 4.4.0)
KinterbaseDB 3.3.0 svn rev 1038 (self build mingw32 4.4.0)
mingw32 gcc (GCC) 4.4.0
mingw32 g++ (GCC) 4.4.0
GNU ld (GNU Binutils) 2.19

Planning Status: Unspecified


 Description  « Hide
After run and exit WinDBG show 2 threads:

Thread 000:1138
WARNING: Stack unwind information not available. Following frames may be wrong.
00 ntdll!KiFastSystemCallRet
01 fbclient!THD_sleep+0xd (FPO: [1,0,0]) (CONV: cdecl)
02 fbclient!delete_process+0x5c (FPO: [0,0,0]) (CONV: cdecl)
03 fbclient!exit_handler+0x28 (FPO: [1,20,4]) (CONV: cdecl)
04 fbclient!gds__cleanup+0x29 (FPO: [0,0,0]) (CONV: cdecl)
05 fbclient!_CRT_INIT+0x167 (FPO: [3,0,0]) (CONV: stdcall)
06 fbclient!__DllMainCRTStartup+0xb7 (FPO: [Non-Fpo]) (CONV: cdecl)
07 fbclient!_DllMainCRTStartup+0x1d (FPO: [3,0,0]) (CONV: stdcall)
08 ntdll!RtlQueryInformationActivationContext+0x19f
09 ntdll!RtlExitUserProcess+0xe6
0a ntdll!RtlExitUserProcess+0x68
0b kernel32!ExitProcess+0x15
0c MSVCR90!amsg_exit+0x75
0d MSVCR90!get_pgmptr+0x196
0e MSVCR90!exit+0x11
0f PYTHON26!Py_Exit+0xf
10 PYTHON26!PyErr_PrintEx+0x22
11 PYTHON26!PyErr_Print+0xd
12 image00400000+0x1b39
13 image00400000+0x1bf5

Thread 001:1158:
WARNING: Stack unwind information not available. Following frames may be wrong.
00 ntdll!DbgBreakPoint
01 kernel32!BaseThreadInitThunk+0x12
02 ntdll!RtlInitializeExceptionChain+0x63
03 ntdll!RtlInitializeExceptionChain+0x36


 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order

Davide Angeli added a comment - 03/Nov/09 09:56 PM
I've got the same problem using the embedded 2.1.3 version in a win32 application written with Delphi. The application remains always in memory with a couple of threads still working. With version 2.1.2 there is no problem.

Henri Gourvest added a comment - 26/Jul/10 12:15 PM
the problem still occur on "Windows Embedded POSReady ".

Vlad Khorsun added a comment - 26/Jul/10 12:24 PM
Henri,

why do you think it is the same issue ?

Are you run latest snapshot of 2.1.4 ?

I can said almost nothing lookng at your embedded.txt.

Antti Nivala added a comment - 26/Jul/10 02:58 PM
Hi,

This looks like a potentially serious issue for us given that we are using Firebird Embedded in a Win32 application. We are currently using version 2.1.2 and considering updating to 2.1.3. I would like to know the following:

1. This seems to be a 2.1.3 issue only, and 2.1.2 does not seem to have the same problem. Is this correct?

2. Can this deadlock occur in the process exit stage after "normal use", or does it require some special circumstances such as using some specific API calls?

3. Do you recommend staying with 2.1.2 and going directly to 2.1.4 once it is available, in order to avoid this issue?

I'm posting these questions as a comment in Tracker because the information is probably useful to others, too.

-Antti

Vlad Khorsun added a comment - 26/Jul/10 07:20 PM
1. Correct
2. It is related to the events usage. If your application not used events then its not affected by this bug.
3. If you not used events - try 2.1.3. Else you can try 2.1.4 - either wait for final release or use current snapshot build. Careful testing will not harm, as usual ;)

Henri Gourvest added a comment - 27/Jul/10 07:48 AM
Vlad,

> why do you think it is the same issue ?
The problem occur when activating events and closing application using the embedded version.
It look like something related to this report.

> Are you run latest snapshot of 2.1.4 ?
yes, same problem in 2.1.3

it work fine on windows XP but fail on WEPOS.

Vlad Khorsun added a comment - 27/Jul/10 07:56 AM
> it work fine on windows XP but fail on WEPOS.
Could you provide process dump at point where it hungs ?

Antti Nivala added a comment - 27/Jul/10 07:59 AM
Many thanks, Vlad!

As far as I understand, we don't use events in our application. I'm assuming that "using events" refers to the SQL commands such as EVENT INIT, EVENT WAIT, POST_EVENT and the API calls such as isc_event_block, isc_wait_for_event, isc_que_events. We don't use any of these so it seems this bug wouldn't affect us.

Henri Gourvest added a comment - 27/Jul/10 08:47 AM
I uploaded the dump file here:
http://www.megaupload.com/?d=0H5FLFHA

Vlad Khorsun added a comment - 27/Jul/10 09:42 PM
Henri,

What exact build of Firebird did you used when produced dump ?

Henri Gourvest added a comment - 28/Jul/10 07:47 AM

Vlad Khorsun added a comment - 28/Jul/10 01:03 PM
Snapshots was refreshed and i can't match your dump with current binaries.
Create new dump or upload fbclient.dll and fbclient.pdb (both renamed from fbembed.*) for me, please.

Henri Gourvest added a comment - 29/Jul/10 10:35 AM
Vlad,

This is
- the mini and full dump files
- corresponding firebird binaries and pdb
http://www.megaupload.com/?d=168KOPU5

thanks

Vlad Khorsun added a comment - 29/Jul/10 07:15 PM
It seems Windows Embedded not terminated secondary threads when process exits and DLL's is unloaded.
Make sure that :
a) you canceled all events before detach
b) you detached from all databases before application exits
c) try to unload fbembed.dll explicitly before application exits (if you loaded it using LoadLibrary() API)

Engine performs cleanup at DLLMain() call and no threads syncronization is allowed at this time.
In Firebird 2.5 we have special new fb_shutdown() API which performs all necessary cleanup of the engine and application should call it before exit.