I hope someone might have additional ideas on what is going wrong and how we could solve it.
Our MySQL Database keeps crashing due to Signal 11 (Segfault) from the OS.
Quick overview of the server:
Centos 7
MySQL Server Community Edition 8.0.23 via the official mysql repository
4 cores
8GB RAM
100GB HDD with 85GB free space
We started to get crashes with the following log:
15:09:23 UTC - mysqld got signal 11 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x7f678c000d20
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f6800141c30 thread_stack 0x46000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x3d) [0x21e102d]
/usr/sbin/mysqld(handle_fatal_signal+0x313) [0x1009643]
/lib64/libpthread.so.0(+0xf5d0) [0x7f68181975d0]
/usr/sbin/mysqld() [0x24c7e0e]
/usr/sbin/mysqld(trx_undo_update_rec_get_update(unsigned char const*, dict_index_t const*, unsigned long, unsigned long, unsigned long, unsigned long, trx_t*, mem_block_info_t*, upd_t**, lob::undo_vers_t*, type_cmpl_t&)+0x7bb) [0x24c9d3b]
/usr/sbin/mysqld(trx_undo_prev_version_build(unsigned char const*, mtr_t*, unsigned char const*, dict_index_t const*, unsigned long*, mem_block_info_t*, unsigned char**, mem_block_info_t*, dtuple_t const**, unsigned long, lob::undo_vers_t*)+0x43d) [0x24cb7cd]
/usr/sbin/mysqld(row_vers_build_for_consistent_read(unsigned char const*, mtr_t*, dict_index_t*, unsigned long**, ReadView*, mem_block_info_t**, mem_block_info_t*, unsigned char**, dtuple_t const**, lob::undo_vers_t*)+0x279) [0x2476cb9]
/usr/sbin/mysqld(row_search_mvcc(unsigned char*, page_cur_mode_t, row_prebuilt_t*, unsigned long, unsigned long)+0x2b34) [0x2462c14]
/usr/sbin/mysqld(ha_innobase::index_read(unsigned char*, unsigned char const*, unsigned int, ha_rkey_function)+0x29a) [0x22c7e2a]
/usr/sbin/mysqld(handler::ha_index_read_map(unsigned char*, unsigned char const*, unsigned long, ha_rkey_function)+0x347) [0x11184e7]
/usr/sbin/mysqld() [0xe8c415]
/usr/sbin/mysqld(join_read_const_table(JOIN_TAB*, POSITION*)+0x87) [0xe8c4d7]
/usr/sbin/mysqld(JOIN::extract_func_dependent_tables()+0x4c3) [0xeaff03]
/usr/sbin/mysqld(JOIN::make_join_plan()+0x10e7) [0xec0fb7]
/usr/sbin/mysqld(JOIN::optimize()+0xbcb) [0xec247b]
/usr/sbin/mysqld(SELECT_LEX::optimize(THD*)+0xb6) [0xf1ebe6]
/usr/sbin/mysqld(SELECT_LEX_UNIT::optimize(THD*, TABLE*, bool)+0x7b) [0xf92dab]
/usr/sbin/mysqld(Sql_cmd_dml::execute_inner(THD*)+0x3d) [0xf1d63d]
/usr/sbin/mysqld(Sql_cmd_dml::execute(THD*)+0x525) [0xf272e5]
/usr/sbin/mysqld(mysql_execute_command(THD*, bool)+0x9f0) [0xecb7a0]
/usr/sbin/mysqld(dispatch_sql_command(THD*, Parser_state*)+0x42b) [0xecff7b]
/usr/sbin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0x1ed6) [0xed22f6]
/usr/sbin/mysqld(do_command(THD*)+0x19c) [0xed302c]
/usr/sbin/mysqld() [0xffa6b8]
/usr/sbin/mysqld() [0x2782d4e]
/lib64/libpthread.so.0(+0x7dd5) [0x7f681818fdd5]
/lib64/libc.so.6(clone+0x6d) [0x7f6816575ead]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f678c009a68): SELECT job_project_id AS projectid, user_id_fk AS userid, job_name AS jobname FROM job WHERE job_id=2463
Connection ID (thread ID): 9
Status: NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Reading through the logs it seems that the culprit is the following query:
SELECT job_project_id AS projectid, user_id_fk AS userid,
job_name AS jobname
FROM job
WHERE job_id=2463
The table job has the following columns:
Columns:
job_id int AI PK
job_name varchar(50)
job_status json
job_fileset_list json
user_id_fk int
job_project_id int
job_start_time datetime
job_end_time datetime
job_pipeline json
job_task_blobs json
job_exe_blobs json
The my.cnf is:
# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/8.0/en/server-configuration-defaults.html
[mysqld]
#
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
innodb_buffer_pool_size = 5500M
#
# Remove the leading "# " to disable binary logging
# Binary logging captures changes between backups and is enabled by
# default. It's default setting is log_bin=binlog
# disable_log_bin
#
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M
#
# Remove leading # to revert to previous value for default_authentication_plugin,
# this will increase compatibility with older clients. For background, see:
# https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_default_authentication_plugin
# default-authentication-plugin=mysql_native_password
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
max_connections=500
We have only ever seen this error with above query. This segfault occurs semi-regularly, where we can run the query fine a couple of times and then it segfaults. We tried running the queries sequentially, no difference. We tried running them with breaks of 1 seconds, no difference.
The server definitely does not go out of memory, there is enough around when the segfault comes along.
I am completely out of ideas and I also cannot find people with the same problem.
The closest I found was a bug report
however this is for a much older version of mysql, and did not offer any resolution.
If anyone has any ideas, hunches or even had this problem themselves before, I would very much appreciate your input!
So this is not really a solution to the bug/problem itself.
But thanks to Don we have narrowed the cause down to most probably be MySQL itself. We have switched to MariaDB and the problem does not occur anymore. We will stick with MariaDB for the forseeable future.
Related
I want to load some initial Data into my DB2 Database with the Liquibase "Load-Data"-Tag. It works with the 70 other files just fine, but it throws this Error with one specific file.
SQLCODE=-1218, SQLSTATE=57011, SQLERRMC=4096
Already attempted fixes
I already tried all the possible fixes in the db2 documentation, but the Problem persisited:
1. increase the bufferpool size
2. decrease the maximum number of database agents and/or connections
3. decrease the maximum degree of parallelism
4. decrease the prefetch size for table spaces that are in this
bufferpool
5. move some table spaces into other bufferpools.
The original file-size was over 4000 lines but even when decreasing the size it still throws the error when one of the following lines is in the csv (examples, there are more of these lines):
"0141.651 ";"004";"default ";"- Valor neto en % "
"0144.654 ";"002";"default ";"- Net Value as % "
"0311.000-TC ";"002";"default ";"Raw Materials, Supplies "
Code
Following there is my initialisation of the bufferpool, the tablespace, the table and the liquibase script:
CREATE BUFFERPOOL BPDAT SIZE 5000 PAGESIZE 4 K;
CREATE TABLESPACE TSBLCORE MANAGED BY DATABASE USING (FILE 'tsblcore.001' 200000) BUFFERPOOL BPDAT;
create table BLPDET
(
SYMBOLICPOSITIONNO CHAR(15) not null,
LANGUAGEKEY CHAR(3) not null,
REPORTGROUPKEY CHAR(24) not null,
DESCRIPTION CHAR(100) not null
) in TSBLCORE;
<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog
xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:pro="http://www.liquibase.org/xml/ns/pro"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.1.xsd
http://www.liquibase.org/xml/ns/pro
http://www.liquibase.org/xml/ns/pro/liquibase-pro-4.1.xsd"
>
<changeSet author="Jonas" id="4.31">
<sql>COMMIT;</sql>
<loadData encoding="UTF-8"
file="build/Server/resources/changelog/Data/BL_POSDESCRIPTION.csv"
commentLineStartsWith=""
quotchar="""
relativeToChangelogFile="false"
schemaName="DB5"
separator=";"
tableName="BLPDET"
usePreparedStatements="false">
</loadData>
</changeSet>
</databaseChangeLog>
Error
This is the Error displayed in the logs:
2022-08-18-10.58.09.909950+000 I424271E825 LEVEL: Severe
PID : 12733 TID : 140309988108032 PROC : db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB : DB2LOCAL
APPHDL : 0-503 APPID: 172.17.0.1.55526.220818105144
UOWID : 366 ACTID: 142
AUTHID : DB2INST1 HOSTNAME: d4fac55a3d2e
EDUID : 48 EDUNAME: db2agent (DB2LOCAL) 0
FUNCTION: DB2 UDB, buffer pool services, sqlbIsExtentAllocated, probe:4792
MESSAGE : ZRC=0x8502002C=-2063466452=SQLB_BPFULL
"no available buffer pool pages"
DATA #1 : Pointer, 8 bytes
0x00007f9c366bc3c8
DATA #2 : unsigned integer, 4 bytes
4
DATA #3 : unsigned integer, 4 bytes
0
DATA #4 : Pointer, 8 bytes
0x00007f9c76ffc0d0
DATA #5 : Pointer, 8 bytes
0x00007f9c64d77440
I tried to raise my number of pages up to like 100,000, but the error persisted.
db2diag.log:
ADM6019E All pages in buffer pool "IBMSYSTEMBP4K" (ID "4096") are in use. Refer to the documentation for SQLCODE -1218
ADM6073W The table space "TSBLCORE" (ID "8") is configured to use buffer pool ID "3", but this buffer pool is not active at this time. In the interim the table space will use buffer pool ID "4096". The inactive buffer pool should become available at next database startup provided that the required memory is available.
Environment
Database Product
DB2/LINUXX8664
Database Version
SQL11055
Driver Version
4.8
Liquibase Version
4.14.0
Is there any possibility that something in the example datasets causes this behaviour?
PS: This is my first Stackoverflow Question, so please excuse me if i forgot to include something.
I am getting Access violation writing location 0xB7066CBC while running this code.Unable to figure out whats going on, any suggestions?
int main(void)
{
unsigned int SIG = 0x00000000;
unsigned int *base = (unsigned int *)0xb7066CBC;
SIG = 0x5a5a5a5a;
memcpy(base ,&SIG, 4);
}
Here are the values I am getting when I encounter this failure.
&SIG 0x003bf7c0 {0x5a5a5a5a}
SIG 0x5a5a5a5a
base 0xb7066cbc {???}
I am getting Access violation writing location 0xB7066CBC while running this code.Unable to figure out whats going on
What's going on is that the 4 bytes at location 0xB7066CBC are not writable.
Your problem most likely lies in whatever reasoning led you to believe that these bytes are (or should be) writable, but since you didn't provide any clue as to what that reasoning might be, it's hard to offer any help.
I have used BIGINT and it accepts only 10 digits. Aadhaar id has 12 digits and hence I am getting an error. Help me out on this.
MySQL BIGINT uses 8 bytes. It should be big enough to hold 12-digit number:
A BIGINT uses 8 bytes, so it can store the numbers:
Signed: -9223372036854775808 to 9223372036854775808
Unsigned: 0 to 18446744073709551615
Can you post error you are getting? We might help you better in that case.
You can use varchar(12) then you can check whether it is numeric by using ISNUMERIC in sql or is_numeric() method in php.
I recently rsync a bunch of MYI, MYD, and FRM files from one MySQL 5.0.95 server to another, both using MyISAM. Due to a forgotten hot-fix, it turns out that the original database was configured to default tables to utf8, and the new database was set to latin1. When we turned on the new database, it worked, but shortly thereafter, several queries caused it to segfault multiple times in a row. I suspect it has to do with the charset difference, but I don't understand the stack trace well enough to get to the bottom of the issue. Below is the decoded stack trace, and then the mysql.log.
Stack trace:
0x819b416 handle_segfault + 806
0xb76246a1 _end + -1358137335
0x8193936 Protocol::store_string_aux(char const*, unsigned int, charset_info_st*, charset_info_st*) + 166
0x8193a2b Protocol_simple::store(Field*) + 139
0x818f671 select_send::send_data(List<Item>&) + 161
0x81e5735 init_read_record_seq(st_join_table*) + 373
0x81e8629 join_read_always_key_or_null(st_join_table*) + 2153
0x81ecbc7 sub_select(JOIN*, st_join_table*, bool) + 135
0x81ef127 JOIN::rollup_write_data(unsigned int, st_table*) + 2487
0x81ff6ed JOIN::exec() + 1341
0x81fc72b _Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select + 219
0x82015a6 handle_select(THD*, st_lex*, select_result*, unsigned long) + 326
0x81b1240 mysql_execute_command(THD*) + 7728
0x81b6140 mysql_parse(THD*, char const*, unsigned int, char const**) + 640
0x81b88d0 dispatch_command(enum_server_command, THD*, char*, unsigned int) + 3408
0x81b9f30 handle_one_connection + 2624
0xb785f10f _end + -1355799945
0xb767c74e _end + -1357776714
mysql.log:
160623 17:39:52 - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=209715200
read_buffer_size=262144
max_used_connections=4
max_connections=1500
threads_connected=4
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 3660800 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x86799f8
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xa648d168, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x819b416
0xb75d56a1
0x8193936
0x8193a2b
0x818f671
0x81e5735
0x81e8629
0x81ecbc7
0x81ef127
0x81ff6ed
0x81fc72b
0x82015a6
0x81b1240
0x81b6140
0x81b88d0
0x81b9f30
0xb781010f
0xb762d74e
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x875aaf0 = SELECT * FROM Data_197_21268_1 ORDER BY ID LIMIT 1
thd->thread_id=8
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Thank you in advance for any help you can offer. Also, I know I have to upgrade MySQL, this is in the works.
When reading through CUDA 5.0 Programming Guide I stumbled on a feature called "Funnel shift" which is present in 3.5 compute-capable device, but not 3.0. It contains an annotation "see reference manual", but when I search for the "funnel shift" term in the manual, I don't find anything.
I tried googling for it, but only found a mention on http://www.cudahandbook.com, in the chapter 8:
8.2.3 Funnel Shift (SM 3.5)
GK110 added a 64-bit “funnel shift” instruction that may be accessed with the following intrinsics:
__funnelshift_lc(): returns most significant 32 bits of a left funnel shift.
__funnelshift_rc(): returns least significant 32 bits of a right funnel shift.
These intrinsics are implemented as inline device
functions (using inline PTX assembler) in sm_35_intrinsics.h.
...but it still does not explain what the "left funnel shift" or "right funnel shift" is.
So, what is it and where does one need it?
In the case of CUDA, two 32-bit registers are concatenated together into a 64-bit value; that value is shifted left or right; and the most significant (for a left shift) or least significant (for right shift) 32 bits are returned.
The intrinsics from sm_35_intrinsics.h are as follows:
unsigned int __funnelshift_lc(unsigned int lo, unsigned int hi, unsigned int shift);
unsigned int __funnelshift_rc(unsigned int lo, unsigned int hi, unsigned int shift);
According to Andy Glew (dead link removed), applications for funnel shift include fast misaligned memcpy; and as njuffa mentions in the comments above, it can be used to implement rotate if the two input words are the same.