Daniel Black added a comment - 2024-10-24 11:30 Unit test also fails: 10.5 10.5 buildbot@p8-aix1-mariadb:[/home/buildbot/ppc64be-aix-71/build/build]./unittest/mysys/stack_allocation-t 1..4 not ok 1 - stack checking failed not ok 2 - stack checking failed not ok 3 - stack checking failed not ok 4 - stack checking failed # Failed 4 tests! IBM Engineers have reached out and I've provided details on building this unit test and running it. I'm hoping they can help with some other remain AIX test failures too. A less than fully awake attempt to debug this: gdb ./unittest/mysys/stack_allocation-t (gdb) b main Breakpoint 1 at 0x10000728: file /home/buildbot/ppc64be-aix-71/build/mariadb-10.5.27/unittest/mysys/stack_allocation-t.c, line 104. (gdb) r Starting program: /home/buildbot/ppc64be-aix-71/build/build/unittest/mysys/stack_allocation-t [New Thread 1] [Switching to Thread 1]   Thread 2 hit Breakpoint 1, main (argc=1, argv=0xffffffffffffa60) at /home/buildbot/ppc64be-aix-71/build/mariadb-10.5.27/unittest/mysys/stack_allocation-t.c:104 104 MY_INIT(argv[0]); (gdb) list 99 { 100 pthread_attr_t thr_attr; 101 pthread_t check_thread; 102 void *value; 103 104 MY_INIT(argv[0]); 105 106 plan(4); 107 test_stack_detection(3, STACK_ALLOC_SMALL_BLOCK_SIZE-1); 108 test_stack_detection(4, STACK_ALLOC_SMALL_BLOCK_SIZE+1); (gdb) n 106 plan(4); (gdb) n 1..4 107 test_stack_detection(3, STACK_ALLOC_SMALL_BLOCK_SIZE-1); (gdb) s test_stack_detection (stage=3, stack_allocation=4095) at /home/buildbot/ppc64be-aix-71/build/mariadb-10.5.27/unittest/mysys/stack_allocation-t.c:75 75 my_get_stack_bounds(&stack_start, &stack_end, (gdb) bt #0 test_stack_detection (stage=3, stack_allocation=4095) at /home/buildbot/ppc64be-aix-71/build/mariadb-10.5.27/unittest/mysys/stack_allocation-t.c:75 #1 0x0000000100000778 in main (argc=<optimized out>, argv=<optimized out>) at /home/buildbot/ppc64be-aix-71/build/mariadb-10.5.27/unittest/mysys/stack_allocation-t.c:107 (gdb) info locals stack_start = 0xbadc0ffee0ddf00d stack_end = 0xbadc0ffee0ddf00d res = <optimized out> (gdb) list 70 71 void test_stack_detection(int stage, size_t stack_allocation) 72 { 73 void *stack_start, *stack_end; 74 int res; 75 my_get_stack_bounds(&stack_start, &stack_end, 76 (void*) &stack_start, my_stack_size); 77 stack_allocation_total= 0; 78 res= test_stack(stack_start, stack_end, 1, stack_allocation); 79 if (!res) (gdb) s my_get_stack_bounds (stack_start=0xffffffffffff918, stack_end=0xffffffffffff910, fallback_stack_start=0xffffffffffff918, fallback_stack_size=299008) at /home/buildbot/ppc64be-aix-71/build/mariadb-10.5.27/mysys/my_stack.c:48 48 pthread_t thread= pthread_self(); (gdb) n 52 if (pthread_getattr_np(thread, &attr) == 0) (gdb) 55 pthread_attr_getstack(&attr, &stack_base, &stack_size); (gdb) 60 *stack_start= stack_base - stack_size * STACK_DIRECTION; (gdb) 61 pthread_attr_destroy(&attr); /* Clean up */ (gdb) 79 *stack_end= *stack_start + stack_size * STACK_DIRECTION; (gdb) test_stack_detection (stage=<optimized out>, stack_allocation=4095) at /home/buildbot/ppc64be-aix-71/build/mariadb-10.5.27/unittest/mysys/stack_allocation-t.c:77 77 stack_allocation_total= 0; (gdb) info locals stack_start = 0x100000003ffff1c0 stack_end = 0xffffffffffff9e0 res = <optimized out> (gdb) info registers r1 r1 0xffffffffffff8a0 1152921504606845088 (gdb) list 72 { 73 void *stack_start, *stack_end; 74 int res; 75 my_get_stack_bounds(&stack_start, &stack_end, 76 (void*) &stack_start, my_stack_size); 77 stack_allocation_total= 0; 78 res= test_stack(stack_start, stack_end, 1, stack_allocation); 79 if (!res) 80 ok(1, "%llu bytes allocated on stack of size %ld with %lu alloc size", 81 (unsigned long long) stack_allocation_total, (gdb) s 78 res= test_stack(stack_start, stack_end, 1, stack_allocation); (gdb) s test_stack (stack_start=0x100000003ffff1c0, stack_end=0xffffffffffff9e0, iteration=1, stack_allocation=4095) at /home/buildbot/ppc64be-aix-71/build/mariadb-10.5.27/include/my_stack_alloc.h:44 44 /home/buildbot/ppc64be-aix-71/build/mariadb-10.5.27/include/my_stack_alloc.h: No such file or directory.

Michael Widenius added a comment - 2024-10-27 18:43 Answering @marko: "In the changeset it does not look like any optimizations were disabled as suggested; at least I see none of the following: function attribute optimize(0) (GCC) or optnone (clang) #pragma optimize( "", off ) (MSVC)" This was tested without and with buildbot and was not needed. The code seams to work perfectly with and without optimization. There is an unit test that verifies this. "To my understanding, none of our CI systems enable link-time optimization (cmake -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=ON). Some GNU/Linux distributions that package MariaDB Server do that, and they might now hit some trouble." I have been told that MariaDB build systems already uses compilation with link time optimization for some platforms. We have not seen any indication of any problem with the stack optimization with these builds. The way link time optimization works is not different from running -O2/-O3 on one compilation unit. As this works (and the functions are inlined already), I do not see any reason why link time optimization would cause any different results. If I understood it correctly, the following kind of a predicate should work if used in the appropriate way: #ifdef _MSC_VER include <intrin.h> define my_get_stack_pointer() _AddressOfReturnAddress() #elif defined _ GNUC _ /* GCC or clang or derivatives */ define my_get_stack_pointer() __builtin_frame_address(0) As was already concluded in an earlier comment for this Jira entry, the above does not work. frame pointer is the address of the stack pointer before any local variables (or variables from inline functions) are allocated on stack. As link time optimization adds even more variables on the stack, using the above approach will cause failures that is less likely to happen with the current code.

Daniel Black added a comment - 2024-10-28 00:45 The explicit Debian/Ubuntu disabling has only just been lifted ( MDEV-25633 ). Debian LTO is opt in https://wiki.debian.org/LTO , so the disable was around Ubuntu usage. Ubuntu LTO is https://wiki.ubuntu.com/ToolChain/LTO , so effectively 22.04+ if we include maintained versions that are in BB. 22.04+ builds are for 10.6+ so it wasn't until this was merged last Monday to 10.6 that this was even had the first exposure to LTO testing. Since this is merged up to bb-11.4-release https://buildbot.mariadb.org/#/builders/352/builds/17055/steps/7/logs/stdio unit.stack_allocation w2 [ pass ] 51 For values of 24.04 LTO usage, it applies to bb-10.11-release, which was first tested 2 days ago. Ubuntu 24.10 is from the bb-11.4-release, first tested 2 days ago still passes. The OpenSUSE LTO example MDEV-21248 is for OpenSUSE Tumbleweed ( https://en.opensuse.org/openSUSE:LTO ) which isn't in CI. It currently has a gcc version above Ubuntu 24.10 (by a minor gcc release number), but overall the combination of other compilation options may affect results too. There are some older clang test exercising this, possibly not with LTO. monty you are obviously right in that inline makes this, optionally (its still a likely compiler choice), not dependant on LTO. The functions of this commit are verging into the territory of undefined behaviour and while tested on our current platforms it can easily fail elsewhere, like it has for AIX (which isn't fixed by O0 or fallback btw). Disabling optimization of a few inline instructions was a risk management strategy in light of pervious bug reports and the considerable freedoms that optimizations have when inline.

Marko Mäkelä added a comment - 2025-01-07 11:06 MDEV-31151 ( https://github.com/MariaDB/server/pull/2541 ) had fixed a bug in the stack usage check earlier. To fix MDEV-33209 , I simply used more direct debug injection instead of trying to tweak the use of alloca() . If the stack overflow check is now supposed to be accurate, it could make sense to revisit that.