- Package:
- src:libmodbus
- Source:
- libmodbus
- Submitter:
- John David Anglin
- Date:
- 2025-07-08 08:39:01 UTC
- Severity:
- normal
- Tags:
Dear Maintainer, See build log: https://buildd.debian.org/status/fetch.php?pkg=libmodbus&arch=hppa&ver=3.1.6-1&stamp=1566917369&raw=0 Test fails: FAIL: ./unit-tests.sh ===================== Starting server Starting client unit-test-server: no process found FAIL unit-tests.sh (exit status: 255) Regards, Dave Anglin
Note, that I see this error on armel (buster-backports), too: https://buildd.debian.org/status/fetch.php?pkg=libmodbus&arch=armel&ver=3.1.6-2%7Ebpo10%2B1&stamp=1582655638 (from: https://buildd.debian.org/status/package.php?p=libmodbus&suite=buster-backports) FAIL: ./unit-tests.sh ===================== Starting server Starting client unit-test-server: no process found FAIL unit-tests.sh (exit status: 255)
Note, that I see this error on armel (buster-backports), too: https://buildd.debian.org/status/fetch.php?pkg=libmodbus&arch=armel&ver=3.1.6-2%7Ebpo10%2B1&stamp=1582655638 (from: https://buildd.debian.org/status/package.php?p=libmodbus&suite=buster-backports) FAIL: ./unit-tests.sh ===================== Starting server Starting client unit-test-server: no process found FAIL unit-tests.sh (exit status: 255)
Maybe on slow™ architectures the waiting time after
starting the unit-test-server is just too short:
echo "Starting server"
./unit-test-server > $server_log 2>&1 &
sleep 1
echo "Starting client"
./unit-test-client > $client_log 2>&1
If that is really the problem, something like that is
probably better (untested, not even tried to compile):
--- a/tests/unit-test-server.c
+++ b/tests/unit-test-server.c
@@ -110,6 +110,9 @@
}
}
+ int ready = open("READY", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666);
+ close(ready);
+
for (;;) {
do {
rc = modbus_receive(ctx, query);
--- a/tests/unit-tests.sh
+++ b/tests/unit-tests.sh
@@ -6,9 +6,13 @@
rm -f $client_log $server_log
echo "Starting server"
+rm -f READY
./unit-test-server > $server_log 2>&1 &
Maybe on slow™ architectures the waiting time after
starting the unit-test-server is just too short:
echo "Starting server"
./unit-test-server > $server_log 2>&1 &
sleep 1
echo "Starting client"
./unit-test-client > $client_log 2>&1
If that is really the problem, something like that is
probably better (untested, not even tried to compile):
--- a/tests/unit-test-server.c
+++ b/tests/unit-test-server.c
@@ -110,6 +110,9 @@
}
}
+ int ready = open("READY", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666);
+ close(ready);
+
for (;;) {
do {
rc = modbus_receive(ctx, query);
--- a/tests/unit-tests.sh
+++ b/tests/unit-tests.sh
@@ -6,9 +6,13 @@
rm -f $client_log $server_log
echo "Starting server"
+rm -f READY
./unit-test-server > $server_log 2>&1 &
I don't think that's the problem. I tried increasing the sleep time and your patch but neither worked. Had to add includes for open with your patch.
I don't think that's the problem. I tried increasing the sleep time and your patch but neither worked. Had to add includes for open with your patch.
I don't think that's the problem. I tried increasing the sleep time and your patch but neither worked. Had to add includes for open with your patch.
John, could you try this one: https://salsa.debian.org/debian/libmodbus/-/blob/debian/buster-backports/debian/patches/Wait-for-unit-test-server.patch It worked for me, but it could be accidental.
John, could you try this one: https://salsa.debian.org/debian/libmodbus/-/blob/debian/buster-backports/debian/patches/Wait-for-unit-test-server.patch It worked for me, but it could be accidental.
John, could you try this one: https://salsa.debian.org/debian/libmodbus/-/blob/debian/buster-backports/debian/patches/Wait-for-unit-test-server.patch It worked for me, but it could be accidental.
It still fails with the same error: FAIL: ./unit-tests.sh ===================== Starting server Starting client unit-test-server: no process found FAIL unit-tests.sh (exit status: 255) https://buildd.debian.org/status/fetch.php?pkg=libmodbus&arch=hppa&ver=3.1.6-2&stamp=1582986840&raw=0 Think the unit-test-server must die before it is looked for.
It still fails with the same error: FAIL: ./unit-tests.sh ===================== Starting server Starting client unit-test-server: no process found FAIL unit-tests.sh (exit status: 255) https://buildd.debian.org/status/fetch.php?pkg=libmodbus&arch=hppa&ver=3.1.6-2&stamp=1582986840&raw=0 Think the unit-test-server must die before it is looked for.
It still fails with the same error: FAIL: ./unit-tests.sh ===================== Starting server Starting client unit-test-server: no process found FAIL unit-tests.sh (exit status: 255) https://buildd.debian.org/status/fetch.php?pkg=libmodbus&arch=hppa&ver=3.1.6-2&stamp=1582986840&raw=0 Think the unit-test-server must die before it is looked for.
Too bad, it seems to be a different problem then. Thanks for testing, John!
Too bad, it seems to be a different problem then. Thanks for testing, John!
Too bad, it seems to be a different problem then. Thanks for testing, John!
I built package outside buildd. Attached are log files.
I built package outside buildd. Attached are log files.
I built package outside buildd. Attached are log files.
Hi,
How did you reproduce this issue?
I cannot reproduce this issue on my side by using qemu+hppa, as shown below.
AFAICT, I don't think it's an endianness or 32/64 bit issue.
==
<snip>
/usr/bin/make check-TESTS
PASS: unit-tests.sh
============================================================================
Testsuite summary for libmodbus 3.1.6
============================================================================
# TOTAL: 1
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
make[1]: Leaving directory '/build/libmodbus-3.1.6'
create-stamp debian/debhelper-build-stamp
dh_testroot -O--exclude=.la
dh_prep -O--exclude=.la
dh_auto_install -O--exclude=.la
make -j1 install DESTDIR=/build/libmodbus-3.1.6/debian/tmp
AM_UPDATE_INFO_DIR=no
make[1]: Entering directory '/build/libmodbus-3.1.6'
Making install in src
/bin/mkdir -p '/build/libmodbus-3.1.6/debian/tmp/usr/lib/hppa-linux-gnu'
<snip>
==
SZ
John David Anglin <dave.anglin@bell.net> 於 2020年3月1日 週日 上午3:56寫道：
Hi,
How did you reproduce this issue?
I cannot reproduce this issue on my side by using qemu+hppa, as shown below.
AFAICT, I don't think it's an endianness or 32/64 bit issue.
==
<snip>
/usr/bin/make check-TESTS
PASS: unit-tests.sh
============================================================================
Testsuite summary for libmodbus 3.1.6
============================================================================
# TOTAL: 1
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
make[1]: Leaving directory '/build/libmodbus-3.1.6'
create-stamp debian/debhelper-build-stamp
dh_testroot -O--exclude=.la
dh_prep -O--exclude=.la
dh_auto_install -O--exclude=.la
make -j1 install DESTDIR=/build/libmodbus-3.1.6/debian/tmp
AM_UPDATE_INFO_DIR=no
make[1]: Entering directory '/build/libmodbus-3.1.6'
Making install in src
/bin/mkdir -p '/build/libmodbus-3.1.6/debian/tmp/usr/lib/hppa-linux-gnu'
<snip>
==
SZ
John David Anglin <dave.anglin@bell.net> 於 2020年3月1日 週日 上午3:56寫道：
Hi,
How did you reproduce this issue?
I cannot reproduce this issue on my side by using qemu+hppa, as shown below.
AFAICT, I don't think it's an endianness or 32/64 bit issue.
==
<snip>
/usr/bin/make check-TESTS
PASS: unit-tests.sh
============================================================================
Testsuite summary for libmodbus 3.1.6
============================================================================
# TOTAL: 1
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
make[1]: Leaving directory '/build/libmodbus-3.1.6'
create-stamp debian/debhelper-build-stamp
dh_testroot -O--exclude=.la
dh_prep -O--exclude=.la
dh_auto_install -O--exclude=.la
make -j1 install DESTDIR=/build/libmodbus-3.1.6/debian/tmp
AM_UPDATE_INFO_DIR=no
make[1]: Entering directory '/build/libmodbus-3.1.6'
Making install in src
/bin/mkdir -p '/build/libmodbus-3.1.6/debian/tmp/usr/lib/hppa-linux-gnu'
<snip>
==
SZ
John David Anglin <dave.anglin@bell.net> 於 2020年3月1日 週日 上午3:56寫道：
It was on a 4-way rp3440. Most hppa buildds run on PA 2.0 machines with 64-bit kernels. I believe qemu only supports 32-bit PA 1.1 kernels. I think Helge Deller would be interested in this since we appear to have different application behavior with different kernels. There is a porter box available for testing. https://db.debian.org/machines.cgi?host=panama It's a UP machine however. Dave
It was on a 4-way rp3440. Most hppa buildds run on PA 2.0 machines with 64-bit kernels. I believe qemu only supports 32-bit PA 1.1 kernels. I think Helge Deller would be interested in this since we appear to have different application behavior with different kernels. There is a porter box available for testing. https://db.debian.org/machines.cgi?host=panama It's a UP machine however. Dave
It was on a 4-way rp3440. Most hppa buildds run on PA 2.0 machines with 64-bit kernels. I believe qemu only supports 32-bit PA 1.1 kernels. I think Helge Deller would be interested in this since we appear to have different application behavior with different kernels. There is a porter box available for testing. https://db.debian.org/machines.cgi?host=panama It's a UP machine however. Dave
I did some analysis, and this bug was quite interesting...
Patch which fixes it (and probably armel too) is below.
a) The "unit-test-server: no process found" error is misleading.
It does not indicate that the server or client test program did
not start, but it just means the "killall" program in the unit-tests.sh
shell script could not find the "unit-test-server" process any longer
(which is correct, since it executed and exited quite fine).
The patch below pipes errors of killall to /dev/null to avoid it.
b)
The main problem, is the timeout of 7ms in unit-test-client.c around
line 681.
On SMP parisc machines where more than one CPU is running, the internal
timers are not as fine-grained as on single-CPU machines, or as x86
machines. That leads that it's not guaranteed, that chars gets delivered
in a 2ms boundary timeframe (7ms total - 5ms wait time = 2ms delivery time max).
I increased the timeout to 15ms, and now the tests succeed.
Can you please include the patch below and bring it upstream?
Thanks,
Helge
diff -up ./tests/unit-test-client.c.org ./tests/unit-test-client.c
--- ./tests/unit-test-client.c.org 2024-05-19 12:40:47.232000000 +0000
+++ ./tests/unit-test-client.c 2024-05-19 12:43:34.644000000 +0000
@@ -679,11 +679,12 @@ int main(int argc, char *argv[])
usleep(11 * 5000);
modbus_flush(ctx);
- /* Timeout of 7ms between bytes */
- modbus_set_byte_timeout(ctx, 0, 7000);
+ /* Timeout of 15ms between bytes (allow slow machines or machines
+ with unreliable SMP timers to succeed) */
+ modbus_set_byte_timeout(ctx, 0, 15000);
rc = modbus_read_registers(
ctx, UT_REGISTERS_ADDRESS_BYTE_SLEEP_5_MS, 1, tab_rp_registers);
- printf("2/2 Adapted byte timeout (7ms > 5ms): ");
+ printf("2/2 Adapted byte timeout (15ms > 5ms): ");
ASSERT_TRUE(rc == 1, "");
}
diff -up ./tests/unit-tests.sh.org ./tests/unit-tests.sh
--- ./tests/unit-tests.sh.org 2024-05-19 12:39:00.572000000 +0000
+++ ./tests/unit-tests.sh 2024-05-19 12:39:22.904000000 +0000
@@ -14,6 +14,6 @@ echo "Starting client"
./unit-test-client > $client_log 2>&1
rc=$?
On Sun, 19 May 2024 14:59:16 +0200 Helge Deller <deller@kernel.org> wrote: > I did some analysis, and this bug was quite interesting... > Patch which fixes it (and probably armel too) is below. > > a) The "unit-test-server: no process found" error is misleading. > It does not indicate that the server or client test program did > not start, but it just means the "killall" program in the unit-tests.sh > shell script could not find the "unit-test-server" process any longer > (which is correct, since it executed and exited quite fine). > The patch below pipes errors of killall to /dev/null to avoid it. > > b) > The main problem, is the timeout of 7ms in unit-test-client.c around > line 681. > On SMP parisc machines where more than one CPU is running, the internal > timers are not as fine-grained as on single-CPU machines, or as x86 > machines. That leads that it's not guaranteed, that chars gets delivered > in a 2ms boundary timeframe (7ms total - 5ms wait time = 2ms delivery time max). > I increased the timeout to 15ms, and now the tests succeed. > > Can you please include the patch below and bring it upstream? Thanks for your investigation I did forward this bug upstream: https://github.com/stephane/libmodbus/issues/815 The failure on hurd-* seems to be related to that too. I tested on the hurd porterbox and increasing the timeout to 30ms is fixing the build (15ms was not enough) Would be nice is this could be fixed Kind regards, Laurent Bigonville