Issue Details (XML | Word | Printable)

Key: CORE-6253
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Minor Minor
Assignee: Vlad Khorsun
Reporter: Basil A. Sidorov
Votes: 0
Watchers: 0

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

Crash caused by the locked fb_lock file

Created: 20/Feb/20 12:59 PM   Updated: 08/Jul/20 11:20 PM
Component/s: Engine
Affects Version/s: 4.0 Beta 1, 3.0.5
Fix Version/s: 3.0.7, 4.0 RC 1

File Attachments: 1. Zip Archive (62 kB)

WI-V3.0.5.33220 Firebird 3.0
WI-T4.0.0.1779 Firebird 4.0 Beta 1

QA Status: Deferred

 Description  « Hide
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.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Basil A. Sidorov added a comment - 20/Feb/20 01:05 PM
Info from dumpchk and stack traces

Basil A. Sidorov added a comment - 15/Apr/20 07:06 AM
Not resolved - crash on WI-V3.0.6.33281 Firebird 3.0.

Vlad Khorsun added a comment - 08/Jul/20 11:20 PM
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.