[MDEV-24131] 10.5.7 does not build stacktrace-t (OpenBSD) - HAVE_BACKTRACE / HAVE_BACKTRACE_FD missing Created: 2020-11-04  Updated: 2021-02-19  Resolved: 2021-01-28

Status: Closed
Project: MariaDB Server
Component/s: Compiling, Platform OpenBSD
Affects Version/s: 10.5.7
Fix Version/s: 10.2.37, 10.3.28, 10.4.18, 10.5.9

Type: Bug Priority: Blocker
Reporter: Brad Smith Assignee: Daniel Black
Resolution: Fixed Votes: 0
Labels: None

Attachments: File 0001-stacktrace-t.c-make-the-test-conditional.patch     File MDEV-24131.patch     Text File stacktrace.log    

 Description   

The 10.5.7 release does not build.

[499/1657] : && /home/ports/pobj/mariadb-10.5.7/bin/c++  -O2 -pipe  -I/usr/local/include -fstack-protector --param=ssp-buffer-size=4 -DNDEBUG -D_FORTIFY_SOURCE=2 -DDBUG_OFF  -L/usr/local/lib -Wl,-z,relro,-z,now unittest/mysys/CMakeFiles/stacktrace-t.dir/stacktrace-t.c.o  -o unittest/mysys/stacktrace-t -L/usr/lib   -L/usr/local/lib -lpthread  unittest/mytap/libmytap.a  mysys/libmysys.a  dbug/libdbug.a  strings/libstrings.a  mysys/libmysys.a  dbug/libdbug.a  strings/libstrings.a  -lz  -lm  -lpthread  -Wl,-rpath-link,/usr/X11R6/lib && :
FAILED: unittest/mysys/stacktrace-t
: && /home/ports/pobj/mariadb-10.5.7/bin/c++  -O2 -pipe  -I/usr/local/include -fstack-protector --param=ssp-buffer-size=4 -DNDEBUG -D_FORTIFY_SOURCE=2 -DDBUG_OFF  -L/usr/local/lib -Wl,-z,relro,-z,now unittest/mysys/CMakeFiles/stacktrace-t.dir/stacktrace-t.c.o  -o unittest/mysys/stacktrace-t -L/usr/lib   -L/usr/local/lib -lpthread  unittest/mytap/libmytap.a  mysys/libmysys.a  dbug/libdbug.a  strings/libstrings.a  mysys/libmysys.a  dbug/libdbug.a  strings/libstrings.a  -lz  -lm  -lpthread  -Wl,-rpath-link,/usr/X11R6/lib && :
ld: error: undefined symbol: my_safe_print_str
>>> referenced by stacktrace-t.c
>>>               unittest/mysys/CMakeFiles/stacktrace-t.dir/stacktrace-t.c.o:(test_my_safe_print_str)
>>> referenced by stacktrace-t.c
>>>               unittest/mysys/CMakeFiles/stacktrace-t.dir/stacktrace-t.c.o:(test_my_safe_print_str)
>>> referenced by stacktrace-t.c
>>>               unittest/mysys/CMakeFiles/stacktrace-t.dir/stacktrace-t.c.o:(test_my_safe_print_str)
>>> referenced by stacktrace-t.c
>>>               unittest/mysys/CMakeFiles/stacktrace-t.dir/stacktrace-t.c.o:(test_my_safe_print_str)
>>> referenced by stacktrace-t.c
>>>               unittest/mysys/CMakeFiles/stacktrace-t.dir/stacktrace-t.c.o:(test_my_safe_print_str)
>>> referenced by stacktrace-t.c
>>>               unittest/mysys/CMakeFiles/stacktrace-t.dir/stacktrace-t.c.o:(test_my_safe_print_str)
>>> referenced by stacktrace-t.c
>>>               unittest/mysys/CMakeFiles/stacktrace-t.dir/stacktrace-t.c.o:(test_my_safe_print_str)
c++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.



 Comments   
Comment by Daniel Black [ 2020-11-04 ]

brad0,

This looks like a lack of backtrace or backtrace_fd function on OpenBSD.

diff --git a/unittest/mysys/stacktrace-t.c b/unittest/mysys/stacktrace-t.c
index 8fa0db15b36..67eb099028e 100644
--- a/unittest/mysys/stacktrace-t.c
+++ b/unittest/mysys/stacktrace-t.c
@@ -22,6 +22,14 @@
 
 char b_bss[10];
 
+#ifndef HAVE_STACKTRACE
+int  my_safe_print_str(const char* val, size_t max_len)
+{
+  printf("%*s\n", (int) max_len, val);
+  return 0;
+}
+#endif
+
 void test_my_safe_print_str()
 {
   char b_stack[10];

Should get it to compile. The unit test probably isn't sufficiently meaningful however.

It was easier than copying the include/my_stacktrace.h HAVE_BACKTRACE logic to a CMakeList defination to exclude this test.

Comment by Brad Smith [ 2020-11-05 ]

Ah. Thanks. We have a libexecinfo port which provides backtrace() but only tend to use it where absolutely necessary. That bit of code did build and the build is still going.

Comment by Brad Smith [ 2020-11-05 ]

It built in full after that diff.

Comment by Daniel Black [ 2020-11-13 ]

brad0 can you try the attached MDEV-24131.patch against 10.5.

Is the built unit test ./unittest/mysys/stacktrace-t successfully built, and does it run returning 0?

Expected output isn't pretty, e.g. on linux:

$ ./unittest/mysys/stacktrace-t
 
===== heap =====
LEGALa�
 
===== BSS =====
LEGALx�b���`U��XN/home/dan�����宱��ࣟ�`U
 
===== data =====
LEGAL
===== stack =====
 
===== heap =====
 
===== BSS =====
 
===== data =====
 
===== NULL =====
 
===== (const char*) 1 =====
test_my_safe_print_str
===== Above is a junk, but it is expected. =====
 
===== Nornal length test =====
# Bail out! Signal %d thrown
MYTAP_CONFIG1..%d
1..0 # skip todo # %s %s%sok %d%snot  - skip days  day  hours  hour Failed %d tests!%ld %s%ld min %.2f secTest took %s
%d tests planned,  %d failed,  %d was last executed%d tests planned but%s %d executed�@�C �@N@UMASKUMASK_DIRunknownHOMEWaiting for table level lock
User time %.2f, System time %.2f
Maximum resident set size %ld, Integral resident set size %ld
Non-physical pagefaults %ld, Physical pagefaults %ld, Swaps %ld
Blocks in %ld out %ld, Messages in %ld out %ld, Signals %ld
Voluntary context switches %ld, Involuntary context switches %ld
Y@TCPSOCKETPIPEMEMORY01230120022455012623010202Error in my_thread_global_end(): %d threads didn't exit
Can't initialize threads: error %d
NPTLlinuxthreadsno_namestack_bottom = %p thread_stack 0x%lx
(my_addr_resolve failure: %s)
%s:%u(%s)[%p]
%s(%s+%s
(null)Can't access address %pError while parsing '%s': %s
ucs2utf8utf8mb3utf8mb4utf16utf32/usr/local/mysql/sharecharsets//usr/local/mysqlutf8mb3_utf8_%s.xml[import ?646latin1ANSI_X3.4-1968ansi1251cp1251armscii8armscii-8Big5big5cp1255hebrewCP866cp866eucCNgb2312euc-CNeucJPujiseuc-JPeucKReuckreuc-KRgbkgeorgianpsgeostd8georgian-psIBM-1252cp1252iso88591ISO_8859-1ISO8859-1ISO-8859-1iso885913latin7ISO_8859-13ISO8859-13ISO-8859-13iso88592latin2ISO_8859-2ISO8859-2ISO-8859-2iso88597greekISO_8859-7ISO8859-7ISO-8859-7iso88598ISO_8859-8ISO8859-8ISO-8859-8iso88599latin5ISO_8859-9ISO8859-9ISO-8859-9koi8rKOI8-Rkoi8uKOI8-Uroman8hp8Shift_JISsjisSJISshiftjisx0213tis620tis-620US-ASCIIutf-���:���:���:���:���:���:���:���:���:�������:���:������:���:���:���:���:���:���:���:���:���:���:���:���@���:���:���:���:���:���:���:�������:���:���:���:�������Retry in %d secs. Message reprinted in %d secsCan't create/write to file '%s' (Errcode: %M)Error reading file '%s' (Errcode: %M)Error writing file '%s' (Errcode: %M)Error on close of '%s' (Errcode: %M)Out of memory (Needed %u bytes)Error on delete of '%s' (Errcode: %M)Error on rename of '%s' to '%s' (Errcode: %M)Unexpected end-of-file found when reading file '%s' (Errcode: %M)Can't unlock file (Errcode: %M)Can't read dir of '%s' (Errcode: %M)Can't get stat of '%s' (Errcode: %M)Can't change size of file (Errcode: %M)Can't open stream from handle (Errcode: %M)Can't get working directory (Errcode: %M)Can't change dir to '%s' (Errcode: %M)Warning: %d files and %d streams is left open
....
(many many lines of junk)
....
Q�R�R�R�RHVBVLV5VAVJVIVFVXVZV@V3V=V,V>V8V*V:V�W�X�X�X�X�X�X�X�X�X�X�Z�Z�Z�Z�Z[�Z[�Z[[[[g\�]�]�]�]�]�]�]�]�]�]�]�]i^]^`^\^�}�^�^�^I_�_�a�aya�a�a�a�a�a�a�a�a�a�a�a�a�afa�a-bndpd�d�d�d�d�dj�i�id�djjj%jj�i&jj�ijQk�k�k�k�kll�klAo&o~o�o�o�o�o�o�oboOo�oZo�ovolo�oUoroRoPoWo�o�o]ooaoko}ogo�oSo�oioo�ocowojo{o�q�q�q�q�q�q�q�q�q�q�q�q�q�q�q�q�q�r�rXsRs^s_s`s]s[sasZsYsbs�t�t�t�t�t}t�t�t|tyuu~u%vv
 
===== Above is a junk, but it is expected. =====
 
===== Nornal length test =====
LEGAL
 
===== NULL =====
(null)
===== (const char*) 1 =====
Can't access address 0x1
ok 1 - test_my_safe_print_str
Test took 0.16 sec
 
$ echo $?
0

Comment by Brad Smith [ 2020-11-13 ]

The output of the test is nuts. I attached a log file with the output. I don't know where the PuTTy PuTTy bit at the end comes from but I noticed the bar at the top of the window which usually as the hostname/IP of the host connected to is now some odd ASCII characters.

Comment by Daniel Black [ 2020-11-15 ]

Yes, there's terminal escape message that change the title.

For the most part unit tests are run with their stderr redirected.

Can you try the following? I'm mostly interested in the successful or not return code.

$ ./unittest/mysys/stacktrace-t  2> /dev/null; echo $?
1..1
ok 1 - test_my_safe_print_str
Test took 0.06 sec
0

Comment by Brad Smith [ 2020-11-16 ]

From my system...

humpty$ ./unittest/mysys/stacktrace-t  2> /dev/null; echo $?
1..1
ok 1 - test_my_safe_print_str
Test took 0.25 sec
0

Comment by Daniel Black [ 2020-11-16 ]

Thanks brad0

Robert, can I get a review on:

bb-10.2-danielblack-MDEV-24131-fix-stacktrace-t-for-non-win-non-backtrace-systems

Merge notes: just keep the func my_safe_print_str before `#else /* _WIN_*/` which keeps it out of `#ifdef HAVE_STACKTRACE` at the top of file.

Comment by Robert Bindar [ 2020-11-24 ]

Hi brad0 and thank you for reporting this problem!
And hii danblack! My review for the patch is in a comment here: https://github.com/MariaDB/server/commit/84c01f1af5c421ca4c4407343e28d5346ceee85d

Also, did the patch compile for you? On my OpenBSD 6.8, before getting to this compile error Brad reported, compilation failed with incorrect pointer type from my_alarm.h. A fix for those errors is here: https://github.com/MariaDB/server/compare/bb-10.4-robert...robertbindar:bb-10.4-robert (please note the solution is not very well reasoned about, it was a quick fix to get past the errors), feel free to include that on top of your commit if you can reproduce the failure too.

Comment by Brad Smith [ 2020-11-24 ]

The issue with my_alarm.h appears to be legit. Though I don't see where the build error is. The build does not use -Werror. I don't see what the issue is with my_gethwaddr.c. It builds for us without any warnings at all.

/home/ports/pobj/mariadb-10.5.8/mariadb-10.5.8/mysys/my_lock.c:183:7: warning: incompatible function pointer types assigning to 'sig_return' (aka 'void (*)(void)') from 'void (*)(int)' [-Wincompatible-function-pointer-types]
      ALARM_INIT;
      ^~~~~~~~~~
/home/ports/pobj/mariadb-10.5.8/mariadb-10.5.8/include/my_alarm.h:43:16: note: expanded from macro 'ALARM_INIT'
                        alarm_signal=signal(SIGALRM,my_set_alarm_variable);
                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ports/pobj/mariadb-10.5.8/mariadb-10.5.8/mysys/my_lock.c:189:7: warning: incompatible function pointer types passing 'sig_return' (aka 'void (*)(void)') to parameter of type 'void (*)(int)' [-Wincompatible-function-pointer-types]
      ALARM_END;
      ^~~~~~~~~
/home/ports/pobj/mariadb-10.5.8/mariadb-10.5.8/include/my_alarm.h:44:41: note: expanded from macro 'ALARM_END'
#define ALARM_END       (void) signal(SIGALRM,alarm_signal); \
                                              ^~~~~~~~~~~~
/usr/include/sys/signal.h:199:27: note: passing argument to parameter here
void    (*signal(int, void (*)(int)))(int);
                             ^
2 warnings generated.

Comment by Mingli-Yu [ 2021-01-26 ]

I run into this issue with mariadb 10.5.8 with below steps and attach the patch 0001-stacktrace-t.c-make-the-test-conditional.patch which used to fix the issue on my side.
1, mkdir -p /work/builds
2, cd /work
3, git clone git://git.yoctoproject.org/poky
3, git clone git://git.openembedded.org/meta-openembedded
4, cd poky
5, . oe-init-build-env ../builds/
6, echo "TCLIBC = \"musl\"" >> conf/local.conf
7, sed -i 's/^MACHINE.*/MACHINE ??= "qemuarm64"/g' conf/local.conf
8, add below lines to conf/bblayers.conf
/work/meta-openembedded/meta-oe \
/work/meta-openembedded/meta-networking \
/work/meta-openembedded/meta-python \
9, bitbake mariadb

Comment by Robert Bindar [ 2021-01-26 ]

Hey brad0 and Mingli-Yu, Daniel here had already worked out the patch and I reviewed it, my guess is that Daniel is overloaded with work at the moment and probably didn't get the chance to adjust the patch and push it, we're sorry for the delay. danblack is there anything else stopping your patch from getting pushed?

Comment by Daniel Black [ 2021-01-27 ]

Correct. Sorry for delay. I did mean to go back and adjust it to fix the implicit declaration.

Comment by Daniel Black [ 2021-01-28 ]

Thanks Mingli-Yu, that's a nice simple patch and I've used it. Thank you.

Comment by Brad Smith [ 2021-02-19 ]

I see the patch for MDEV-24131 has been commited to the 10.2 branch. Can it please be merged forward to the 10.3 through 10.6 branches before the next releases are out?

Comment by Daniel Black [ 2021-02-19 ]

It will be merged to the following branches.

Comment by Sergei Golubchik [ 2021-02-19 ]

brad0, it's guaranteed by our release procedure. We always merge from 10.2 (or whatever the lowest branch is) all the way up before the release

Generated at Thu Feb 08 09:27:40 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.