[raiguard][not a bug] 1.1.80 (build 60618, linux64, full): crash in libc memory management

[Polite1E6aire]

Factorio 1.1.80 (build 60618, linux64, full)

With a latest development build of glibc, factorio triggers a libc-internal sanity check and gets aborted when
a game is loaded:

Code: Select all

Fatal glibc error: malloc.c:3617 (_mid_memalign): assertion failed: !p || chunk_is_mmapped (mem2chunk (p)) || ar_ptr == arena_for_chunk (mem2chunk (p))

I've isolated the offending commit in the glibc codebase [1], opened a bugreport [2] and reverting it fixes the crash in factorio;
however since only factorio seems to be adversely affected (all other closed-source linux games I have run fine) I thought to also report it here, in case a dev wants to take a closer look.

[1] https://sourceware.org/git/?p=glibc.git ... c4c486ed6f
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=30301

[raiguard]

Thanks for the report. Seeing as several Rust programs are also crashing, I think it's safe to say that this isn't a bug in Factorio. I will keep an eye on the bugzilla thread.

[Polite1E6aire]

Yes, a patch was posted in the glibc mailinglist that fixes this. It's not a factorio bug, but factorio was useful to expose it. Sorry for the noise!

[archon810]

Yes, a patch was posted in the glibc mailinglist that fixes this. It's not a factorio bug, but factorio was useful to expose it. Sorry for the noise!

@Polite1E6aire Are you able to reference the post where the fix is listed? Having the same issue, but with MariaDB, which keeps crashing after some recent updates and would really appreciate it. Thank you.

Here's the crash in our case:

Code: Select all

Fatal glibc error: malloc.c:3617 (_mid_memalign): assertion failed: !p || chunk_is_mmapped (mem2chunk (p)) || ar_ptr == arena_for_chunk (mem2chunk (p))
230417  1:28:30 [ERROR] mysqld got signal 6 ;
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.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

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.

Server version: 10.11.2-MariaDB-log source revision: cafba8761af55ae16cc69c9b53a341340a845b36
key_buffer_size=536870912
read_buffer_size=262144
max_used_connections=47
max_threads=2050
thread_count=18
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 5301674 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f1f200015a8
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 = 0x7f25d98b95c8 thread_stack 0x49000
??:0(my_print_stacktrace)[0x555e1bb74bdd]
??:0(handle_fatal_signal)[0x555e1b673065]
??:0(__restore_rt)[0x7f25d9a57270]
??:0(__pthread_kill_implementation)[0x7f25d9aa7f8c]
??:0(__GI_raise)[0x7f25d9a571b2]
??:0(__GI_abort)[0x7f25d9a3f34f]
??:0(_IO_peekc_locked.cold)[0x7f25d9a400c9]
??:0(__libc_assert_fail)[0x7f25d9a4f363]
??:0(_mid_memalign.isra.0)[0x7f25d9ab7522]
??:0(std::unique_lock<std::mutex>::unlock())[0x555e1b9806d6]
??:0(std::thread::thread<void (&)()>(void (&)()))[0x555e1bab6045]
??:0(std::thread::thread<void (&)()>(void (&)()))[0x555e1bab6662]
??:0(std::thread::thread<void (&)()>(void (&)()))[0x555e1bab6738]
??:0(std::thread::thread<void (&)()>(void (&)()))[0x555e1baa25bf]
??:0(std::thread::thread<void (&)()>(void (&)()))[0x555e1baa2cb3]
??:0(std::thread::thread<void (&)()>(void (&)()))[0x555e1ba948ce]
??:0(wsrep_notify_status(wsrep::server_state::state, wsrep::view const*))[0x555e1b917ca6]
??:0(wsrep_notify_status(wsrep::server_state::state, wsrep::view const*))[0x555e1b9247bb]
??:0(handler::ha_open(TABLE*, char const*, int, unsigned int, st_mem_root*, List<String>*))[0x555e1b67831a]
??:0(open_table_from_share(THD*, TABLE_SHARE*, st_mysql_const_lex_string const*, unsigned int, unsigned int, unsigned int, TABLE*, bool, List<String>*))[0x555e1b517ead]
??:0(open_table(THD*, TABLE_LIST*, Open_table_context*))[0x555e1b3d22ce]
??:0(open_tables(THD*, DDL_options_st const&, TABLE_LIST**, unsigned int*, unsigned int, Prelocking_strategy*))[0x555e1b3d53a7]
??:0(mysql_update(THD*, TABLE_LIST*, List<Item>&, List<Item>&, Item*, unsigned int, st_order*, unsigned long long, bool, unsigned long long*, unsigned long long*))[0x555e1b5016d3]
??:0(mysql_execute_command(THD*, bool))[0x555e1b43c82b]
??:0(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x555e1b441fae]
??:0(Query_log_event::do_apply_event(rpl_group_info*, char const*, unsigned int))[0x555e1b799647]
??:0(Log_event::apply_event(rpl_group_info*))[0x555e1b78d337]
??:0(Item_string::get_copy(THD*))[0x555e1b38bb08]
??:0(handle_slave_sql)[0x555e1b395b58]
??:0(MyCTX_nopad::finish(unsigned char*, unsigned int*))[0x555e1b87597d]
??:0(start_thread)[0x7f25d9aa6154]
??:0(__clone3)[0x7f25d9b2d3d8]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f1f208e4ef0): UPDATE `wp_usermeta` SET `meta_value` = '0' WHERE `user_id` = 19 AND `meta_key` = 'use_ssl'