Issue Details (XML | Word | Printable)

Key: CORE-1980
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Nickolay Samofatov
Votes: 0
Watchers: 0
Operations

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

Sweeper consumes 100% CPU forever

Created: 05/Jul/08 05:40 PM   Updated: 08/Nov/09 07:04 PM
Component/s: Engine
Affects Version/s: 2.5 Initial, 2.1.0
Fix Version/s: 2.5 Beta 1

Time Tracking:
Not Specified

Environment:
- slightly corrupted database (one data page damaged, and a few blob
pages have problems)
- ODS 11.0
- current HEAD Windows x86 SuperServer

Planning Status: Unspecified


 Description  « Hide
After attaching to database with ISQL server always consumes 100% of one
CPU. GFIX cannot be used against database because server always keeps
internal attachment to it.

The situation is that sweep thread tends to re-spawn itself (please see
stack trace below) and ignore errors. In most cases it doesn't seem to
cause problems, but in case of sweep error this is enough to cause
endless re-spawn cycle.

 > fbserver.exe!gds__thread_start(unsigned int (void *)*
entrypoint=0x00475880, void * arg=0x00380658, int priority=0x00000003,
int __formal=0x00000000, void * thd_id=0x00000000) Line 79 C++
     fbserver.exe!start_sweeper(Jrd::thread_db * tdbb=0x06e7fa8c,
Jrd::Database * dbb=0x011be0a0) Line 2659 + 0x14 bytes C++
     fbserver.exe!transaction_start(Jrd::thread_db * tdbb=0x06e7fa8c,
Jrd::jrd_tra * temp=0x03da2c5c) Line 3412 + 0xd bytes C++
     fbserver.exe!TRA_start(Jrd::thread_db * tdbb=0x06e7fa8c, int
tpb_length=0x00000000, const unsigned char * tpb=0x00000000,
Jrd::jrd_tra * outer=0x00000000) Line 1598 + 0xd bytes C++
     fbserver.exe!jrd8_attach_database(int * user_status=0x06e7fdd0,
const char * filename=0x011a6454, Jrd::Attachment * * handle=0x06e7fd1c,
short dpb_length=0x0010, const unsigned char * dpb=0x06e7fbb8) Line
1247 + 0x23 bytes C++
     fbserver.exe!isc_attach_database(int * user_status=0x06e7fdd0,
short file_length=0x0000, const char * file_name=0x00380a40, void * *
public_handle=0x06e7fdc4, short dpb_length=0x0010, const char *
dpb=0x06e7fe50) Line 1321 + 0x70 bytes C++
     fbserver.exe!sweep_database(void * database=0x00380a40) Line
2697 C++
     fbserver.exe!ThreadPriorityScheduler::run() Line 163 + 0x10
bytes C++
     fbserver.exe!`anonymous namespace'::threadStart(void *
arg=0x011a633c) Line 99 + 0x8 bytes C++
     msvcr80d.dll!_callthreadstartex() Line 348 + 0xf bytes C
     msvcr80d.dll!_threadstartex(void * ptd=0x012f1c68) Line 331 C

dbb->dbb_flags=0x61168 at this particular call stack.

Vlad Khorsun diagnosed the problem as regression related to introducing database triggers.


 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 09/Mar/09 02:38 PM
The fix is to set\clear flag ATT_no_cleanup around TRA_start call to not trigger auto sweep.
Mentioned TRA_start is used to start transaction in which ON CONNECT\ON DISCONNECT triggers executed.