TablePlus / DBngin

DB Engine
https://dbngin.com
1.08k stars 19 forks source link

Assertion Failure after reboot. #142

Open aaronduce opened 7 months ago

aaronduce commented 7 months ago

Please fill out the detail below, it helps me investigate the bug:

  1. Driver (Ex: PostgreSQL 10.0): MySQL 8.0.27

  2. DBngin build number: 7.0 (70)

  3. macOS version: 13.4 - M2 MBP

  4. The steps to reproduce this issue:

I rebooted my machine as normal last Friday, and come in Monday to my main DB server not starting (goes green, but refresh and back to 'start' btn)

other DB servers start fine, but 3 of my 8 now have this issue for starting.

Looking at logs:

2024-04-08T08:42:59.663424Z 0 [System] [MY-010116] [Server] /Users/Shared/DBngin/mysql/8.0.27/bin/mysqld (mysqld 8.0.27) starting as process 11595
2024-04-08T08:42:59.664894Z 0 [Warning] [MY-010159] [Server] Setting lower_case_table_names=2 because file system for /Users/aaronduce/Library/Application Support/com.tinyapp.DBngin/Engines/mysql/9DECE674-39D5-44CC-96B3-C0FAE755201E/ is case insensitive
2024-04-08T08:42:59.665139Z 0 [Warning] [MY-010122] [Server] One can only use the --user switch if running as root
2024-04-08T08:42:59.667539Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2024-04-08T08:42:59.977231Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2024-04-08T08:43:00.074690Z 1 [ERROR] [MY-013183] [InnoDB] Assertion failure: dict0dict.cc:3386:for_table || ref_table thread 0x16efaf000
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
08:43:00 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x12308ea00
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 = 16efaeea8 thread_stack 0x100000
0   mysqld                              0x0000000101ea3140 my_print_stacktrace(unsigned char const*, unsigned long) + 68
1   mysqld                              0x000000010150cea8 handle_fatal_signal + 428
2   libsystem_platform.dylib            0x000000019cb22a24 _sigtramp + 56
3   libsystem_pthread.dylib             0x000000019caf3c28 pthread_kill + 288
4   libsystem_c.dylib                   0x000000019ca01ae8 abort + 180
5   mysqld                              0x0000000102261b2c ut_dbg_assertion_failed(char const*, char const*, unsigned long) + 400
6   mysqld                              0x000000010200be98 dict_foreign_add_to_cache(dict_foreign_t*, char const**, bool, bool, dict_err_ignore_t) + 1344
7   mysqld                              0x000000010201f0c0 dd_table_load_fk_from_dd(dict_table_t*, dd::Table const*, char const**, dict_err_ignore_t, bool) + 1544
8   mysqld                              0x0000000102023d34 dict_table_t* dd_open_table_one<dd::Table>(dd::cache::Dictionary_client*, TABLE const*, char const*, dd::Table const*, THD*, std::__1::deque<char const*, ut::allocator<char const*, ut::detail::allocator_base_pfs<char const*>>>&) + 6696
9   mysqld                              0x0000000102015608 dd_table_open_on_dd_obj(THD*, dd::cache::Dictionary_client*, dd::Table const&, dd::Partition const*, char const*, dict_table_t*&, TABLE const*) + 1732
10  mysqld                              0x000000010201684c dd_table_open_on_id_low(THD*, MDL_ticket**, unsigned long long) + 1272
11  mysqld                              0x000000010201602c dd_table_open_on_id(unsigned long long, THD*, MDL_ticket**, bool, bool) + 1996
12  mysqld                              0x000000010218835c MetadataRecover::apply() + 104
13  mysqld                              0x0000000102222600 srv_dict_recover_on_restart() + 360
14  mysqld                              0x00000001020f53c4 innobase_dict_recover(dict_recovery_mode_t, unsigned int) + 2048
15  mysqld                              0x0000000101d139f8 dd::bootstrap::restart(THD*) + 216
16  mysqld                              0x0000000101e87560 dd::upgrade_57::restart_dictionary(THD*) + 76
17  mysqld                              0x0000000101e85f50 dd::upgrade_57::do_pre_checks_and_initialize_dd(THD*) + 2216
18  mysqld                              0x00000001010918a4 bootstrap::handle_bootstrap(void*) + 228
19  mysqld                              0x00000001022cdd64 pfs_spawn_thread(void*) + 392
20  libsystem_pthread.dylib             0x000000019caf3fa8 _pthread_start + 148
21  libsystem_pthread.dylib             0x000000019caeeda0 thread_start + 8

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): 
Connection ID (thread ID): 1
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.
aaronduce commented 7 months ago

This has been solved in the meantime by creating a full new instance of 8.0.33, copying the files from the other server to the new server data folder, and removing the InnoDB redo and temp files so that the data could be upgraded. Seems to be working. Leaving open as the above seems to be an issue of something and still have two other less essential databases im not rushing to solve like this one.

liekevdvoort commented 2 months ago

We have the same issue! Creating a new instance and copying the files results in the same error however. @aaronduce which files and folders did you delete in order to get the new instance running?

aaronduce commented 2 months ago

These two I believe

Screenshot 2024-09-10 at 14 16 32

@liekevdvoort