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

Sweeper consumes 100% CPU forever [CORE1980] #2418

Closed
firebird-automations opened this issue Jul 5, 2008 · 6 comments
Closed

Sweeper consumes 100% CPU forever [CORE1980] #2418

firebird-automations opened this issue Jul 5, 2008 · 6 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @samofatov

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.

Commits: 002ec66

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

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

resolution: Fixed [ 1 ]

Fix Version: 2.5 Beta 1 [ 10251 ]

@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

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

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

QA Status: No test => Cannot be tested

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