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

Crash caused by the locked fb_lock file [CORE6253] #6496

Closed
firebird-automations opened this issue Feb 20, 2020 · 12 comments
Closed

Crash caused by the locked fb_lock file [CORE6253] #6496

firebird-automations opened this issue Feb 20, 2020 · 12 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Basil A. Sidorov (basid)

Attachments:
CORE-6253.zip

1. Run Firebird server as application or service, connect in isql to localhost:employee
2. Run fb_lock_print -d employee -iw 1 65535
3. Disconnect from employee and (normal) shutdown server. fb_lock_#⁠#⁠#⁠#⁠ file is not deleted (open in fb_lock_print)
3. Run again Firebird server and try again connect to employee. ISQL hung and server fully load one cpu core
4. Terminate (Ctrl+C) fb_lock_print and server is crashed.

Commits: d5fad96 8348349 a1116fe f470a21 6aa0609 57599e6

@firebird-automations
Copy link
Collaborator Author

Commented by: Basil A. Sidorov (basid)

Info from dumpchk and stack traces

@firebird-automations
Copy link
Collaborator Author

Modified by: Basil A. Sidorov (basid)

Attachment: CORE6253.zip [ 13425 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

The crash and its direct reason is fixed but the problem with locked attachments still remains.
The problem is that fb_lock_print holds an "empty" lock table that prevents the initializing "real" attachment from re-creating it.
Probably shmem initialization procedure should be re-thinked (again).

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

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

resolution: Fixed [ 1 ]

Fix Version: 4.0 Beta 2 [ 10888 ]

Fix Version: 3.0.6 [ 10889 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

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

QA Status: No test => Deferred

@firebird-automations
Copy link
Collaborator Author

Commented by: Basil A. Sidorov (basid)

Not resolved - crash on WI-V3.0.6.33281 Firebird 3.0.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

security: Developers [ 10012 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

summary: Crash via locked fb_lock file => Crash caused by the locked fb_lock file

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

status: Resolved [ 5 ] => Reopened [ 4 ]

resolution: Fixed [ 1 ] =>

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Additional pathes was committed:
- fb_lock_print in interactive mode checks every second if lock table is empty and breaks iterations to release shared memory and avoid of blocking new attachments,
- shared memory initialization code now tries to handle case when last process that holds shared memory was killed (or crashed) and OS objects (event, memory mapping,
etc) was released in not correct\expected order. It pevents bugcheck in lock manager in such a case.

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

status: Reopened [ 4 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 4.0 RC 1 [ 10930 ]

Fix Version: 3.0.7 [ 10940 ]

Fix Version: 4.0 Beta 2 [ 10888 ] =>

Fix Version: 3.0.6 [ 10889 ] =>

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