swupdate test failures on ppc64el with -O3 and not with -O2

[Gianfranco Costamagna (LocutusOfBorg)]

Hello as said,

when we build on ppc64el for Ubuntu, we default to O3 and the package fails during tests run:

https://launchpadlibrarian.net/865516714/buildlog_ubuntu-stonking-ppc64el.swupdate_2026.05+dfsg-3_BUILDING.txt.gz

RUN test_flash_handler

TAP version 14 1..39

malloc(): corrupted top size Aborted (core dumped)

According to a log of a successful run, I guess the malloc issue is in "test_simple" or something similar

LD_LIBRARY_PATH=. ./test/test_flash_handler
[==========] flash_handler: Running 39 test(s).
[ RUN      ] test_simple
malloc(): corrupted top size
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted                    (core dumped) LD_LIBRARY_PATH=. ./test/test_flash_handler

The patch contributed by chatgpt is here:

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Gianfranco Costamagna <locutu...@debian.org>
Date: Jun, 18 2026 12:36:50 +0200
Subject: [PATCH] Fix undefined behaviour with -O3

open() is not declared as:

int open(const char *, int);

Its actual prototype is:

int open(const char *pathname, int flags, ...);

Internally, mkstemps() eventually calls open(..., O_CREAT | ..., mode).

Because you've wrapped open() with a non-variadic function, you have an ABI mismatch:

caller passes 3 arguments
wrapper accepts 2 arguments

That's undefined behavior.

--- swupdate-2026.05+dfsg.orig/test/test_flash_handler.c
+++ swupdate-2026.05+dfsg/test/test_flash_handler.c
@@ -97,25 +97,50 @@ void *__wrap_malloc(size_t size)
        return impl_malloc(size);
 }

-int __real_open(const char *pathname, int flags);
-static int default_open(const char *pathname, int flags)
+int __real_open(const char *pathname, int flags, ...);
+static int default_open(const char *pathname, int flags, ...)
 {
-       int ret;
-       if (strcmp(pathname, image.device) == 0)
-               return MTD_FD;
-       ret = __real_open(pathname, flags);
-       /* Usually file descriptors start from 0. Since MTD_FD is big enough,
-        * a collision is very unlikely. */
-       assert_int_not_equal(ret, MTD_FD);
-       return ret;
-}
-static int (*impl_open)(const char *pathname, int flags) = default_open;
-int __wrap_open(const char *pathname, int flags);
-int __wrap_open(const char *pathname, int flags)
-{
-       return impl_open(pathname, flags);
+    mode_t mode = 0;
+
+    if (flags & (O_CREAT | O_TMPFILE)) {
+        va_list ap;
+        va_start(ap, flags);
+        mode = va_arg(ap, mode_t);
+        va_end(ap);
+    }
+
+    if (strcmp(pathname, image.device) == 0)
+        return MTD_FD;
+
+    int ret;
+
+    if (flags & (O_CREAT | O_TMPFILE))
+        ret = __real_open(pathname, flags, mode);
+    else
+        ret = __real_open(pathname, flags);
+
+    assert_int_not_equal(ret, MTD_FD);
+
+    return ret;
 }
+static int (*impl_open)(const char *pathname, int flags, ...) = default_open;
+int __wrap_open(const char *pathname, int flags, ...);
+int __wrap_open(const char *pathname, int flags, ...)
+{
+    mode_t mode = 0;
+
+    if (flags & (O_CREAT | O_TMPFILE)) {
+        va_list ap;
+        va_start(ap, flags);
+        mode = va_arg(ap, mode_t);
+        va_end(ap);
+    }

+    if (flags & (O_CREAT | O_TMPFILE))
+        return impl_open(pathname, flags, mode);
+
+    return impl_open(pathname, flags);
+}
 int __real_close(int fd);
 int __wrap_close(int fd);
 int __wrap_close(int fd)
@@ -954,7 +979,7 @@ static void test_empty_image(void **stat
 }

 static int open_mtd_dev_failure_errno;
-static int open_mtd_dev_failure(const char *pathname, int flags)
+static int open_mtd_dev_failure(const char *pathname, int flags, ...)
 {
        if (strcmp(pathname, image.device) == 0) {
                errno = open_mtd_dev_failure_errno;

Patch also here:

http://launchpadlibrarian.net/865535072/swupdate_2026.05+dfsg-3ubuntu1_2026.05+dfsg-3ubuntu2.diff.gz

Please let me know if it works for you and looks sane enough for you, thanks

G.

[Stefano Babic]

Hi Gianfranco,

On 6/18/26 15:00, Gianfranco Costamagna (LocutusOfBorg) wrote:
> Hello as said,
>
> when we build on ppc64el for Ubuntu, we default to O3 and the package
> fails during tests run:
>

I do not think this is the reason, I guess it is a different cmocka version.

> https://launchpadlibrarian.net/865516714/buildlog_ubuntu-stonking-
> ppc64el.swupdate_2026.05+dfsg-3_BUILDING.txt.gz

>
> RUN test_flash_handler
> TAP version 14 1..39

That is here.

what the ....

__real_open() is *NOT* defined by SWUpdate but part of the cmocka
package. If as it seems __real_open was changed, SWUpdate's test should
then run with new and old version of cmocka, or should detect the
version and behave accordingly.

Nevertheless:

I hope you do not *really* think that this patch is usable and can be
applied in some way. Just check any other patch and you see this is a mess.

Please read how to contribute on the documentation, prepare a formal
patch for contribution and push it via ghit send-mail to the mailing list.

Best regards,
Stefano Babic

--
_______________________________________________________________________
Nabla Software Engineering GmbH
Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596
Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
E-Mail: sba...@nabladev.com

[Gianfranco Costamagna (LocutusOfBorg)]

Hello,

__real_open() is *NOT* defined by SWUpdate but part of the cmocka
package. If as it seems __real_open was changed, SWUpdate's test should
then run with new and old version of cmocka, or should detect the
version and behave accordingly.

The test started failing as soon as 2025.05 version (the first version with that test added inside)

https://launchpad.net/ubuntu/+source/swupdate/2025.05+dfsg-2

cmocka was at that time version:

1.1.7-3

then it was updated to 1.1.8, then to 2.0.1, now to 2.0.2, but the test fails with every cmocka version.

 

I hope you do not *really* think that this patch is usable and can be
applied in some way. Just check any other patch and you see this is a mess.

I don't think so, I don't trust my knowledge for the patch sanity and I don't know this cmocka stuff at all.

I am pretty sure this is a test (optimization) issue, not a real code bug (I am confident because adding printfs in the init function makes the failure go magically away).

The "patch" in any case is touching a test file only and makes the test bug disappear in Ubuntu builders, so

I'm fine with it as long as it doesn't break the program, and I'm even more fine in disabling the flaky test too.

If you have any idea about reproducing/testing an eventual patch, please let me know!

 

Please read how to contribute on the documentation, prepare a formal
patch for contribution and push it via ghit send-mail to the mailing list.

Yep I know how to contribute, but I like to do it only if the patch is made by me, and not by AI :)

So, I just sent it to start a discussion around the code, right now I don't have really a patch.

I used to downgrade the build to -O2 on ppc64el to fix the test, but right now after debugging the test code, I think we can use -O3 and disable the test, to not loose efficiency of the compiler optimization.

please let me know if you have any better patch or idea!

Gianfranco