Issue Details (XML | Word | Printable)

Key: CORE-3524
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Jesus Angel Garcia Zarco
Votes: 0
Watchers: 1
Operations

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

Server crashes while compiling a stored procedure being in use

Created: 15/Jun/11 08:44 PM   Updated: 23/Apr/13 01:00 PM
Component/s: Engine
Affects Version/s: 2.5.0, 2.1.4
Fix Version/s: 2.5.1, 2.1.5

Time Tracking:
Not Specified

File Attachments: 1. File fbcrash1.rar (652 kB)
2. File FBCRASHDB.part01.rar (7.63 MB)
3. File FBCRASHDB.part02.rar (5.78 MB)

Environment: Windows 2003 server. FB 2.5 Superserver
Issue Links:
Duplicate
 

Planning Status: Unspecified


 Description  « Hide
Our database has one stored procedure called from 2 triggers. Today doing something that has been done before without problem, that is compile one stored procedure while others users connected to the database, and recompiling the two triggers that calls the stored procedure makes the server crash. I have done the process 2 times. First i have recompiled the stored procedure and the two triggers and 7 minutes after i have done the process again. After the second time, the database has been sutted down, when compiling the triggers that calls the stored procedure.


This is the firebird log file.

SVD13SL03 (Server) Mon Dec 13 13:02:07 2010
Modifying procedure PET_FORMULA_CALC_RESULTADO which is currently in use by active user requests

SVD13SL03 (Server) Mon Dec 13 13:09:51 2010
Modifying procedure PET_FORMULA_CALC_RESULTADO which is currently in use by active user requests

SVD13SL03 (Client) Mon Dec 13 13:10:02 2010
"C:\Archivos de programa\Firebird\Firebird_2_5\bin\fbserver.exe": terminated abnormally (4294967295)

SVD13SL03 (Client) Mon Dec 13 13:10:07 2010
Guardian starting: "C:\Archivos de programa\Firebird\Firebird_2_5\bin\fbserver.exe"

SVD13SL03 (Client) Mon Dec 13 13:10:09 2010
INET/inet_error: send errno = 10054

SVD13SL03 (Client) Mon Dec 13 13:11:00 2010
INET/inet_error: send errno = 10054

SVD13SL03 (Client) Mon Dec 13 13:11:00 2010
REMOTE INTERFACE/gds__detach: Unsuccesful detach from database.
Uncommitted work may have been lost

SVD13SL03 (Client) Mon Dec 13 13:11:59 2010
REMOTE INTERFACE/gds__detach: Unsuccesful detach from database.
Uncommitted work may have been lost

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Jesus Angel Garcia Zarco added a comment - 15/Jun/11 08:46 PM
I have now a test case To reproduce the error

Vlad Khorsun added a comment - 16/Jun/11 07:19 AM
So why don't provide test case here ?

Jesus Angel Garcia Zarco added a comment - 16/Jun/11 09:22 AM
Application to reproduce the error in two steps

Jesus Angel Garcia Zarco added a comment - 16/Jun/11 09:25 AM
Database Part 1

Jesus Angel Garcia Zarco added a comment - 16/Jun/11 09:30 AM
Database part 2

Jesus Angel Garcia Zarco added a comment - 16/Jun/11 09:46 AM
Open the application
Input database and user + password
Click on connect
Click on step 1
Click on step 2

The database is 2.1.4, but opening from 2.5 also crash.


Vlad Khorsun added a comment - 17/Jun/11 11:36 AM
Reproduced, looking into

Jesus Angel Garcia Zarco added a comment - 17/Jun/11 12:24 PM
I open the same bug in CORE-3513, but because i did not see any action, i clone one issue i reported in December, then there is a duplicate.

Vlad Khorsun added a comment - 17/Jun/11 12:37 PM
The call stack is

> fbserver.exe!TRA_detach_request(Jrd::jrd_req * request=0x09ad0018) Line 159 + 0x32 bytes C++
  fbserver.exe!EXE_unwind(Jrd::thread_db * tdbb=0x0236fa9c, Jrd::jrd_req * request=0x09ad0018) Line 1158 + 0x9 bytes C++
  fbserver.exe!CMP_release(Jrd::thread_db * tdbb=0x0236fa9c, Jrd::jrd_req * request=0x09ad0018) Line 2490 + 0xd bytes C++
  fbserver.exe!MET_release_triggers(Jrd::thread_db * tdbb=0x0236fa9c, Firebird::ObjectsArray<Jrd::Trigger,Firebird::Array<Jrd::Trigger *,Firebird::InlineStorage<Jrd::Trigger *,8> > > * * vector_ptr=0x0236f354) Line 6670 + 0xd bytes C++
  fbserver.exe!load_trigs(Jrd::thread_db * tdbb=0x0236fa9c, Jrd::jrd_rel * relation=0x041eebf4, Firebird::ObjectsArray<Jrd::Trigger,Firebird::Array<Jrd::Trigger *,Firebird::InlineStorage<Jrd::Trigger *,8> > > * * triggers=0x0236f4d8) Line 5971 + 0xd bytes C++
  fbserver.exe!make_version(Jrd::thread_db * tdbb=0x0236fa9c, short phase=3, Jrd::DeferredWork * work=0x09b641cc, Jrd::jrd_tra * transaction=0x09b63fa8) Line 6691 + 0x17 bytes C++
  fbserver.exe!DFW_perform_work(Jrd::thread_db * tdbb=0x0236fa9c, Jrd::jrd_tra * transaction=0x09b63fa8) Line 1174 + 0x21 bytes C++
  fbserver.exe!TRA_commit(Jrd::thread_db * tdbb=0x0236fa9c, Jrd::jrd_tra * transaction=0x09b63fa8, const bool retaining_flag=false) Line 443 + 0xd bytes C++
  fbserver.exe!commit(Jrd::thread_db * tdbb=0x0236fa9c, Jrd::jrd_tra * transaction=0x09b63fa8, const bool retaining_flag=false) Line 4252 + 0x11 bytes C++
  fbserver.exe!JRD_commit_transaction(Jrd::thread_db * tdbb=0x0236fa9c, Jrd::jrd_tra * * transaction=0x012807c4) Line 6438 + 0x11 bytes C++
  fbserver.exe!jrd8_commit_transaction(int * user_status=0x0236fc58, Jrd::jrd_tra * * tra_handle=0x012807c4) Line 1658 + 0x21 bytes C++
  fbserver.exe!isc_commit_transaction(int * user_status=0x0236fc58, void * * tra_handle=0x0215e3fc) Line 1743 + 0x5e bytes C++
  fbserver.exe!rem_port::end_transaction(P_OP operation=op_commit, p_rlse * release=0x0215e12c, packet * sendL=0x0215dda0) Line 2050 C++
  fbserver.exe!process_packet(rem_port * port=0x0215ed0c, packet * sendL=0x0215dda0, packet * receive=0x0215e030, rem_port * * result=0x0236fee8) Line 3403 C++
  fbserver.exe!loopThread(void * __formal=0x0000007a) Line 5212 + 0x4f bytes C++
  fbserver.exe!ThreadPriorityScheduler::run() Line 169 + 0x10 bytes C++
  fbserver.exe!`anonymous namespace'::threadStart(void * arg=0x01280d90) Line 93 + 0x8 bytes C++
  msvcr80d.dll!_callthreadstartex() Line 348 + 0xf bytes C
  msvcr80d.dll!_threadstartex(void * ptd=0x00a064b8) Line 331 C

And the crash happens here :

void TRA_detach_request(Jrd::jrd_req* request)
{
if (!request->req_transaction)
return;

// Remove request from the doubly linked list
if (request->req_tra_next)
{
fb_assert(request->req_tra_next->req_tra_prev == request);
request->req_tra_next->req_tra_prev = request->req_tra_prev; <-- HERE
}

Note, fb_assert is triggered in DEBUG build and request->req_tra_next points to already deallocated request.

Research shows that deallocated request is clone of the trigger request and this "main" trigger request was
deallocated a bit earlier.

The problem is that TRA_detach_request (usually called by EXE_unwind) was not called for clone and main
request was released and destroyed its memory pool from where all clones are allocated.

The simples solution is to call EXE_unwind for all clones before deallocation of main request and its memory pool

Vlad Khorsun added a comment - 17/Jun/11 01:28 PM
Fix is committed into 2.5.1 and 2.1.5 branches.

v3 is not affected.

Vlad Khorsun added a comment - 17/Jun/11 01:33 PM
> I open the same bug in CORE-3513, but because i did not see any action, i clone one issue i reported in December, then there is a duplicate.

It is strange that i missed CORE-3513... I closed it as duplicate.

Next time when you see no reaction in your ticket, please, ask in tracker and then in fb-devel, but don't clone tickets.