Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server crashes while compiling a stored procedure being in use [CORE3524] #3881

Closed
firebird-automations opened this issue Jun 15, 2011 · 21 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Jesus Angel Garcia Zarco (cointec)

Is duplicated by CORE3513

Attachments:
fbcrash1.rar
FBCRASHDB.part01.rar
FBCRASHDB.part02.rar

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

Commits: b3cc1c2 86a63f7

@firebird-automations
Copy link
Collaborator Author

Commented by: Jesus Angel Garcia Zarco (cointec)

I have now a test case To reproduce the error

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

So why don't provide test case here ?

@firebird-automations
Copy link
Collaborator Author

Commented by: Jesus Angel Garcia Zarco (cointec)

Application to reproduce the error in two steps

@firebird-automations
Copy link
Collaborator Author

Modified by: Jesus Angel Garcia Zarco (cointec)

Attachment: fbcrash1.rar [ 11969 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Jesus Angel Garcia Zarco (cointec)

Database Part 1

@firebird-automations
Copy link
Collaborator Author

Modified by: Jesus Angel Garcia Zarco (cointec)

Attachment: FBCRASHDB.part01.rar [ 11970 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Jesus Angel Garcia Zarco (cointec)

Database part 2

@firebird-automations
Copy link
Collaborator Author

Modified by: Jesus Angel Garcia Zarco (cointec)

Attachment: FBCRASHDB.part02.rar [ 11971 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Jesus Angel Garcia Zarco (cointec)

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: Jesus Angel Garcia Zarco (cointec)

Version: 2.1.4 [ 10361 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Reproduced, looking into

@firebird-automations
Copy link
Collaborator Author

Commented by: Jesus Angel Garcia Zarco (cointec)

I open the same bug in CORE3513, but because i did not see any action, i clone one issue i reported in December, then there is a duplicate.

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

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

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Fix is committed into 2.5.1 and 2.1.5 branches.

v3 is not affected.

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.5.1 [ 10333 ]

Fix Version: 2.1.5 [ 10420 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

Link: This issue is duplicated by CORE3513 [ CORE3513 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

> I open the same bug in CORE3513, 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 CORE3513... 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.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

summary: Compiling stored procedure while in use shutdown database => Server crashes while compiling a stored procedure being in use

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants