[MDEV-14530] garbd binary from linux generic "glibc_214" tarballs segfault with config file Created: 2017-11-29  Updated: 2018-01-27  Resolved: 2018-01-27

Status: Closed
Project: MariaDB Server
Component/s: Galera Arbitrator garbd
Affects Version/s: 10.2.10
Fix Version/s: 10.2.11

Type: Bug Priority: Major
Reporter: Hartmut Holzgraefe Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-9961 Garbd segfaults when using a configur... Closed

 Description   

When using binary tarballs from mariabd.org on Ubuntu 16.04 garbd from the "glibc_214" tarball crashes when reading options from a config file.

The garbd binaries from the other two tarballs work fine with the same config file, and all three binaries work fine when passing the same options via command line options directly instead of putting them into a config file.

Looking further the content of the config file doesn't even really matter, garbd even crashes on an empty config file.

Core file backtrace:

(gdb) bt
#0 0x0000000000434635 in _gnu_cxx::exchange_and_add (_mem=0xfffffffffffffff8, __val=<optimized out>)
at /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../include/c++/4.7.3/ext/atomicity.h:48
#1 _gnu_cxx::exchange_and_add_dispatch (mem=_mem@entry=0xfffffffffffffff8, __val=-1)
at /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../include/c++/4.7.3/ext/atomicity.h:81
#2 0x000000000044532c in std::string::Rep::_M_dispose (_a=..., this=0xffffffffffffffe8)
at /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../include/c++/4.7.3/bits/basic_string.h:242
#3 std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string (this=0x7ffebdb5be20, __in_chrg=<optimized out>)
at /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../include/c++/4.7.3/bits/basic_string.h:536
#4 boost::program_options::options_description::~options_description (this=0x7ffebdb5be20, __in_chrg=<optimized out>)
at /usr/local/include/boost/program_options/options_description.hpp:163
#5 0x0000000000443746 in garb::Config::Config (this=0x7ffebdb5c940, argc=3, argv=0x7ffebdb5d0a8) at garb/garb_config.cpp:157
#6 0x0000000000435ee8 in garb::main (argc=<optimized out>, argv=<optimized out>) at garb/garb_main.cpp:82
#7 0x000000000043612d in main (argc=<optimized out>, argv=<optimized out>) at garb/garb_main.cpp:113

 Comments   
Comment by Andrii Nikitin (Inactive) [ 2017-11-29 ]

It looks parse_config_file() does corrupt memory somehow - I bet it is related to compiler-related issues

102	        if (!ifs.good())
 
(gdb) 
109	        store(parse_config_file(ifs, config), vm);
 
(gdb) 
 
 
Hardware watchpoint 4: other.m_caption
 
 
 
Old value = "Other options"
 
New value = <error reading variable: Cannot access memory at address 0xffffffffffffffe8>
 
0x0000000000547f7d in boost::program_options::basic_parsed_options<char> boost::program_options::parse_config_file<char>(std::basic_istream<char, std::char_traits<char> >&, boost::program_options::options_description const&, bool) ()

Comment by Andrii Nikitin (Inactive) [ 2017-11-30 ]

The problem doesn't happen with 10.2.11-glibc_214 packages, probably because libgalera version was upgraded:

# strings -a mariadb-10.2.10-linux-glibc_214/bin/garbd | grep '25\.3\.2'
 
25.3.20
 
# strings -a mariadb-10.2.11-linux-glibc_214/bin/garbd | grep '25\.3\.2'
 
25.3.22

Or because different compiler was used in 10.2.11

# strings -a mariadb-10.2.11-linux-glibc_214/bin/garbd | grep "GCC: " | uniq
 
GCC: (Debian 4.7.1-2) 4.7.1
 
GCC: (Debian 4.7.2-5) 4.7.2
 
GCC: (Debian 4.4.7-1) 4.4.7
 
# strings -a mariadb-10.2.10-linux-glibc_214/bin/garbd | grep "GCC: " | uniq
 
GCC: (GNU) 4.7.3
 
GCC: (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
 
# strings -a mariadb-10.2.9-linux-glibc_214/bin/garbd | grep "GCC: " | uniq
 
GCC: (GNU) 4.7.3
 
GCC: (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

Comment by Elena Stepanova [ 2018-01-27 ]

Closing as fixed in 10.2.11 based on the comment above. Please comment if you still experience the problem with 10.2.11+.

Generated at Thu Feb 08 08:14:18 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.