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

[AV] Re-destruction of the rem_port object [CORE6224] #6468

Closed
firebird-automations opened this issue Jan 13, 2020 · 10 comments
Closed

[AV] Re-destruction of the rem_port object [CORE6224] #6468

firebird-automations opened this issue Jan 13, 2020 · 10 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @ibprovider

Attachments:
2020_02_06--fb_bug-core-6224.7z

FB3.0.5.33225 x64 SuperServer.

Connection through TCP/IP.

-------
Under mt-tesing of IBProvider builtin client for Firebird, Firebird crash on the destroy of rem_port object.

This is a reproducible problem on the "clear" build of server.

Run parameters [for history]
target\vs2019-x64-Debug\test_db_client_fb_1.exe /thread_count 10 /auto /log_dir _logs /log_file_prefix fb03-0-4 /inet_host HOME4 /db d:\database\ram\ibp_test_fb30_d3.gdb /db_user GAMER /db_password vermut /new_db_dir d:\database\ram\ /isc_api_library fbclient_30.dll /cn_str "remote:protocol_arch=symmetric,generic;remote:wire_compression=required" /dbms "FB-3" /test RemoteFB.WORK.019.StmtExecute.*

-------- [The "best" case of crash]

I made some changes in FB sources for better undertand of problem.

CRASH THREAD [ID 31192 - not sure at current time]

virtual int release() const
{
fb_assert(m_refCnt.value() > 0); //<- HERE

STACK:
firebird.exe!fb_assert_impl(const char * msg, const char * file, int line, bool do_abort)Строка 48 C++
> firebird.exe!Firebird::RefCounted::release()Строка 45 C++
firebird.exe!rem_port::release()Строка 1162 C++
firebird.exe!Firebird::RefPtr<rem_port>::assign(rem_port * const p)Строка 276 C++
firebird.exe!Firebird::RefPtr<rem_port>::operator=(rem_port * p)Строка 182 C++
firebird.exe!server_req_t::~server_req_t()Строка 130 C++
firebird.exe!server_req_t::`scalar deleting destructor'(unsigned int) C++
firebird.exe!loopThread(void * __formal)Строка 6180 C++
firebird.exe!`anonymous namespace'::ThreadArgs::run()Строка 78 C++
firebird.exe!threadStart(void * arg)Строка 97 C++
ucrtbased.dll!thread_start<unsigned int (__cdecl*)(void *),1>(void * const parameter)Строка 97 C++
kernel32.dll!BaseThreadInitThunk() Нет данных
ntdll.dll!RtlUserThreadStart() Нет данных

LOCAL VARIABLES:
- this 0x00000000008ca1d0 {m_refCnt={...} m_debug__WAS_DELETED=-572662307 } const Firebird::RefCounted *
+ __vfptr 0xdddddddddddddddd {???, ???, ???} void * *
- m_refCnt {...} Firebird::AtomicCounter
+ Firebird::PlatformAtomicCounter {counter=-2459565876494606883 } Firebird::PlatformAtomicCounter
m_debug__WAS_DELETED -572662307 long
refCnt -858993460 const int

NOTE ON THE this - is is 0x00000000008ca1d0

------ TRACE INFORMATION, WHICH WAS CREATED __BEFORE__ CRASH:

It is dirrect call of rem_port::release from "static void disconnect(rem_port* const port)" (inet.cpp). Decrement from 2 to 1.

REM_PORT_RLS - 0x00000000008ca1d0. TID: 31192. R: 1. STACK:
firebird.exe!rem_port::release
firebird.exe!disconnect
firebird.exe!rem_port::disconnect
firebird.exe!rem_port::disconnect
firebird.exe!process_packet
firebird.exe!loopThread
firebird.exe!`anonymous namespace'::ThreadArgs::run
firebird.exe!threadStart
ucrtbased.dll!thread_start<unsigned int (__cdecl*)(void *),1>
kernel32.dll!BaseThreadInitThunk
ntdll.dll!RtlUserThreadStart

It is destroy of rem_port object. Decrement from 1 to 0.

REM_PORT_DCR - 0x00000000008ca1d0. TID: 31192. STACK:
firebird.exe!rem_port::~rem_port
firebird.exe!rem_port::`scalar deleting destructor'
firebird.exe!Firebird::RefCounted::release
firebird.exe!rem_port::release
firebird.exe!Firebird::RefPtr<rem_port>::~RefPtr<rem_port>
firebird.exe!DecrementRequestsQueued::~DecrementRequestsQueued
firebird.exe!process_packet
firebird.exe!loopThread
firebird.exe!`anonymous namespace'::ThreadArgs::run
firebird.exe!threadStart
ucrtbased.dll!thread_start<unsigned int (__cdecl*)(void *),1>
kernel32.dll!BaseThreadInitThunk
ntdll.dll!RtlUserThreadStart

Commits: eae43d8 a9b049e d0a009e

@firebird-automations
Copy link
Collaborator Author

Commented by: @ibprovider

At current time, I have a test fix for this problem.

General idea - do not use direct calls of 'rem_port::release' method and rem_port::addRef in rem_port constructor.

@firebird-automations
Copy link
Collaborator Author

Modified by: @ibprovider

security: Developers [ 10012 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @ibprovider

Test application

@firebird-automations
Copy link
Collaborator Author

Modified by: @ibprovider

Attachment: 2020_02_06--fb_bug-core-6224.7z [ 13421 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Please, confirm - it is not happens without wire compression.
Why test application send 16KB of excess zero's within op_execute in tests "RemoteFB.WORK.019.StmtExecute.*core_bug_4785" ?
Is it reproducible with Firebird client (fbclient.dll) ?

@firebird-automations
Copy link
Collaborator Author

Commented by: @ibprovider

>Please, confirm - it is not happens without wire compression.

This problem appeared after adding (and enabling) connection compression support.

Before (without wire compression) these tests not crash server.

RUS. Да, проблема появилась после включения сжатия данных подключения. Ранее (без сжатия) проблем с этими тестами не наблюдалось.

>Why test application send 16KB of excess zero's within op_execute in tests "RemoteFB.WORK.019.StmtExecute.*core_bug_4785" ?

It is special test for another (old) problem in server - CORE4785.

>Is it reproducible with Firebird client (fbclient.dll) ?

I did not create similar tests for fbclient.dll.

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

> >Is it reproducible with Firebird client (fbclient.dll) ?

> I did not create similar tests for fbclient.dll.

I.e. it is not possible to reproduce it with standard (read correct) client implementation, am I right ?

Network server have a problem, no doubt, and I'll fix it - I just want to find out the real severity of this bug.

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@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: @dyemanov

security: Developers [ 10012 ] =>

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