[DatabaseTasks] Back at it again with TFS 1.2 Crash

[SixNine]

Im not sure but death caused the crash? TFS 1.2

---------------------------------------------------Signal caught: SIGSEGVT - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

databasetask.cpp

/** * The Forgotten Server - a free and open-source MMORPG server emulator * - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

 

[Loney]

If death happened after a long while without any kill, it must be mysql wait timeout problem.
If I remember correctly MariaDB loses connection after (8 hours?) of inactivity (I'm pretty sure this only happens with MariaDB & Debian)

If this is your case, you'll need to change your wait_timeout (by loggin in as a root in mysql) to a larger number and restart mysql service.

 

[SixNine]

If death happened after a long while without any kill, it must be mysql wait timeout problem.
If I remember correctly MariaDB loses connection after (8 hours?) of inactivity (I'm pretty sure this only happens with MariaDB & Debian)

If this is your case, you'll need to change your wait_timeout (by loggin in as a root in mysql) to a larger number and restart mysql service.

It just my guess that crash happened because of death, i cant read crash logs that well.

 

[Loney]

This query was executed at the moment of crash (line 57 in gdb log). As you can see, it was caused by player id 590.

DELETE FROM `player_deaths` WHERE `player_id` = 590 ORDER BY `time` LIMIT 1

 

[fabian766]

If death happened after a long while without any kill, it must be mysql wait timeout problem.
If I remember correctly MariaDB loses connection after (8 hours?) of inactivity (I'm pretty sure this only happens with MariaDB & Debian)

If this is your case, you'll need to change your wait_timeout (by loggin in as a root in mysql) to a larger number and restart mysql service.

It doesn't have any sense, if mysql would always crash after loosing connection then nobody would even consider using something with such vulnerability and why would there be error 2013(CB_SERVER_LOST) when it would crash instead.

The thing is tfs mysql code is written in thread-unsafe manner, what can you do? Use different mysql library that will fix this problem for you or rewrite code according to mysql documentation about thread-safety.

 

[SixNine]

It doesn't have any sense, if mysql would always crash after loosing connection then nobody would even consider using something with such vulnerability and why would there be error 2013(CB_SERVER_LOST) when it would crash instead.

The thing is tfs mysql code is written in thread-unsafe manner, what can you do? Use different mysql library that will fix this problem for you or rewrite code according to mysql documentation about thread-safety.

Damn that sounds like an serious issue

 

[SixNine]

You mentioned "or rewrite code according to mysql documentation about thread-safety." how can i find the unsafe code tho?

 

[fabian766]

You mentioned "or rewrite code according to mysql documentation about thread-safety." how can i find the unsafe code tho?

MySQL :: MySQL 5.7 C API Developer Guide :: 4.3 Writing C API Threaded Client Programs (https://dev.mysql.com/doc/c-api/5.7/en/c-api-threaded-clients.html)

When you call mysql_init(), MySQL creates a thread-specific variable for the thread that is used by the debug library (among other things). If you call a MySQL function before the thread has called mysql_init(), the thread does not have the necessary thread-specific variables in place and you are likely to end up with a core dump sooner or later. To avoid problems, you must do the following:

1. Call mysql_library_init() before any other MySQL functions. It is not thread-safe, so call it before threads are created, or protect the call with a mutex.
2. Arrange for mysql_thread_init() to be called early in the thread handler before calling any MySQL function. (If you call mysql_init(), it calls mysql_thread_init() for you.)
3. In the thread, call mysql_thread_end() before calling pthread_exit(). This frees the memory used by MySQL thread-specific variables.

If you look at tfs code the only thread that actually gets thread-specific variables initialized is dispatcher so it is only thread that is completely safe to make queries, database-thread and main/asio thread shouldn't be doing any queries because it has nullptr dereference

The pthread_getspecific() function shall return the thread-specific data value associated with the given key. If no thread-specific data value is associated with key, then the value NULL shall be returned.

since nullptr dereference is undefined behavior it doesn't mean it'll always crash.

 

[SixNine]

MySQL :: MySQL 5.7 C API Developer Guide :: 4.3 Writing C API Threaded Client Programs (https://dev.mysql.com/doc/c-api/5.7/en/c-api-threaded-clients.html)

When you call mysql_init(), MySQL creates a thread-specific variable for the thread that is used by the debug library (among other things). If you call a MySQL function before the thread has called mysql_init(), the thread does not have the necessary thread-specific variables in place and you are likely to end up with a core dump sooner or later. To avoid problems, you must do the following:

1. Call mysql_library_init() before any other MySQL functions. It is not thread-safe, so call it before threads are created, or protect the call with a mutex.
2. Arrange for mysql_thread_init() to be called early in the thread handler before calling any MySQL function. (If you call mysql_init(), it calls mysql_thread_init() for you.)
3. In the thread, call mysql_thread_end() before calling pthread_exit(). This frees the memory used by MySQL thread-specific variables.

If you look at tfs code the only thread that actually gets thread-specific variables initialized is dispatcher so it is only thread that is completely safe to make queries, database-thread and main/asio thread shouldn't be doing any queries because it has nullptr dereference

The pthread_getspecific() function shall return the thread-specific data value associated with the given key. If no thread-specific data value is associated with key, then the value NULL shall be returned.

since nullptr dereference is undefined behavior it doesn't mean it'll always crash.

I still cant figure out the solution lul