Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.2.9, 10.3.2, 10.4.0, 10.4.10
-
OSX Catalina, Homebrew binary & source compiled
Description
Hi,
this is the same bug that occurred in https://jira.mariadb.org/browse/MDEV-14453. Here's the transcript from IRC #maria:
18:22 < karolyi> hey guys, mariabackup is coredumping for me on Catalina: 'mariabackup -prepare --target...' terminated by signal SIGABRT (Abort)
18:22 < karolyi> does anyone have an idea as to what this could be?
18:24 < karolyi> I'm using 10.4.10 from homebrew, manually compiled, but the binary version segfaults too
18:27 < karolyi> what da...
18:27 < karolyi> mariabackup --help
18:27 < karolyi> fish: 'mariabackup --help' terminated by signal SIGABRT (Abort)
18:27 < karolyi> but when I call it with its full path, /usr/local/bin/mariabackup --help, works
18:28 < karolyi> what sorcery is this
18:32 < Xgc> karolyi: which mariabackup will show the implicit path.
18:32 < karolyi> with the binary package I get: '/usr/local/bin/mariabackup --he...' terminated by signal SIGSEGV (Address boundary error)
18:32 < karolyi> Xgc: it was that path all along
18:33 < karolyi> I bet this is something Catalina related
18:33 < karolyi> okay, reinstall from source...
18:33 < Xgc> karolyi: Hmmm... That suggests a logic problem in the application. Sometimes the application will take the 0th argument (the name) for some processing. If name contains the full path, maybe some error is avoided.
18:34 < Xgc> At first it seemed like a bad installation (wrong package installed).
18:35 < karolyi> Xgc: the one in /usr/local/bin is a symlink: lrwxr-xr-x 1 laszlokarolyi admin 43 Dec 11 18:07 /usr/local/bin/mariabackup -> ../Cellar/mariadb/10.4.10_1/bin/mariabackup
18:35 < Xgc> or missing prerequisites.
18:35 < karolyi> but interestingly, the binary version fails even when called with full path
18:36 < karolyi> let me try and call it with the path in Cellar
18:36 < karolyi> fish: '/usr/local/Cellar/mariadb/10.4....' terminated by signal SIGSEGV (Address boundary error)
18:37 < karolyi> bash-3.2$ /usr/local/Cellar/mariadb/10.4.10_1/bin/mariabackup --help
18:37 < karolyi> Segmentation fault: 11
18:37 < karolyi> building from source again
18:44 < karolyi> btw I use mbstream and mariabackup extensively to restore previously loaded DBs for development
18:44 < karolyi> so this is why it's a PITA
18:44 < karolyi> https://gist.github.com/karolyi/48e0e7909ae67e9d8f2503bfc3c79225
18:58 < karolyi> okay, so it only works when called with a full path AND compiled from source (binary package segfaults as shown above)
seemingly the bug still persists.
Attachments
Issue Links
- is caused by
-
MDEV-13466 Implement --export option for MariaDB Backup
-
- Closed
-
- relates to
-
-
- Closed
-
Activity
Sorry, my bad, GDB has to be started as root. I see the following:
Attaching to process 31669
[New Thread 0x1003 of process 31669]
Error calling thread_get_state for GP registers for thread 0x1003
warning: Mach error at "i386-darwin-nat.c:132" in function "virtual void i386_darwin_nat_target::fetch_registers(struct regcache *, int)": (os/kern) invalid argument (0x4)
Reading symbols from /usr/local/Cellar/mariadb/10.4.10_1/bin/mariabackup...
warning: unhandled dyld version (16)
0x00007fff6fef75be in ?? ()
(gdb)
I debugged this problem (on FreeBSD - it doesn't happen on Linux as it uses /proc/self/exe which always works).
It crashes in my_realpath
#0 0x000000000161a637 in my_realpath (to=0x1a2e180 <mariabackup_exe> "", filename=0x7fffffffedb0 "mxb", MyFlags=0) at my_symlink.c:158
|
#1 0x00000000009a14d7 in get_exepath (size=<optimized out>, argv0=0x50ce9f "error", buf=<optimized out>) at xtrabackup.cc:6391
|
#2 main (argc=1, argv=0x7fffffffeb48) at xtrabackup.cc:6091
|
|
|
158 my_errno=errno;
|
because call to realpath(3) fails and above assignment is invalid as my_errno is not int, it's defined as
include/my_pthread.h:#define my_errno my_thread_var->thr_errno
|
include/my_pthread.h:#define my_thread_var (_my_thread_var())
|
but above test runs before threads are initialized and my_thread_var is unusable
marcin.gryszkalis, thank you for your analysis! Could you please submit a pull request for MariaDB Server 10.2 to fix it? That seems to be the earliest affected version.
I managed to put a my_sleep(1000000) into main() and copied the compiled file in place.
GDB can't attach, here's the message:
Attaching to process 30804
Unable to find Mach task port for process-id 30804: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
the newly compiled file still crashes.