3.6.2-1 FTBFS in Jammy on s390x

For arm64, the execution of test 15 (/wmem/datastruct/tree) of 37 - suite_unittests ends in SIGSEGV.

Adding the compilation flag "-moutline-atomics" didn't work... I'm still investigating.

Hi Miriam
moutline-atomics was an arm related optimization - that was related to CPC work, but not here. Sorry if my quick hint in the meeting was misleading.

I meant to quick try:
1. disable LTO https://wiki.ubuntu.com/ToolChain/LTO
2. do not use symbolic-functions https://git.launchpad.net/ubuntu/+source/autofs/tree/debian/rules?h=ubuntu/cosmic-devel#n9

And see if that helps, as it often enough was one of these so that it is worth to quick check these.

Hmm,
I quickly rebuilt as-is and with both suggestions disabled in local sbuild.
They BOTH worked fine which implies that the build issue on launchpad is
a) only happening on launchpad
or
b) something in jammy-proposed has been fixed in the last few days/hours that resolved this

In both cases:
wireshark_3.6.2-1_amd64.build:36/38 Test #37: suite_unittests ........................ Passed 16.60 sec
wireshark_3.6.2-1ubuntu1~test1_amd64.build:36/38 Test #37: suite_unittests ........................ Passed 10.33 sec

Checking with Miriam now who looked at the same in PPAs ...

FYI debdiff used in local tests https://paste.ubuntu.com/p/W4JvNthN9H/

And by opening my eyes (thanks Miriam) this wasn't ever on amd64 but only arm64 (+s390x).
Ok, so ignore my local tests, we'll need arm64 or s390x systems for this.

Hi!

I made several buildings in a ppa (arm64,s 390x and proposed pocket) here [1], with three scenarios:

1) the optimization moutline-atomics (sorry for the misunderstanding) plus disabling Bsymbolic-functions -> doesn't work
2) only disabling Bsymbolic-functions (in a bad attempt to restrict the disabling of lto for arm64 and s390x... but, happy that this can confirm scenario 3 :) ) -> doesn't work
3) disabling lto and Bsymbolic-functions -> it works.

Therefore, what works for arm64 building is disabling lto. I'll add the package to the lto-disabled-list package for this (adding a related task here).

Continue checking what is happening on the decryption testsuite. We can see in the log the following:

FAIL: test_80211_wpa2_ft_eap (suite_decryption.case_decrypt_80211)
IEEE 802.11 decode WPA2 FT EAP
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/<<PKGBUILDDIR>>/test/fixtures.py", line 54, in wrapped
    test_fn(self, *fixtures)
  File "/<<PKGBUILDDIR>>/test/suite_decryption.py", line 271, in test_80211_wpa2_ft_eap
    self.assertTrue(self.grepOutput('Who has 192.168.1.1')) # Verifies GTK decryption
AssertionError: False is not true

======================================================================
FAIL: test_80211_wpa2_ft_psk_no_roam (suite_decryption.case_decrypt_80211)
IEEE 802.11 decode WPA2 FT PSK (without roam verification)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/<<PKGBUILDDIR>>/test/fixtures.py", line 54, in wrapped
    test_fn(self, *fixtures)
  File "/<<PKGBUILDDIR>>/test/suite_decryption.py", line 235, in test_80211_wpa2_ft_psk_no_roam
    self.assertEqual(self.countOutput('DHCP Discover'), 2)
AssertionError: 0 != 2

======================================================================
FAIL: test_80211_wpa2_ft_psk_roam (suite_decryption.case_decrypt_80211)
IEEE 802.11 decode WPA2 FT PSK
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/<<PKGBUILDDIR>>/test/fixtures.py", line 54, in wrapped
    test_fn(self, *fixtures)
  File "/<<PKGBUILDDIR>>/test/suite_decryption.py", line 255, in test_80211_wpa2_ft_psk_roam
    self.assertEqual(self.countOutput('DHCP Discover'), 2)
AssertionError: 0 != 2

[1] https://launchpad.net/~mirespace/+archive/ubuntu/wireshark-arm64-jammy/+builds?build_text=&build_state=all

Thanks, I reviewed and sponsored the lto-disabled change.

For the remaining s390x issue please use the s390x containers that we set up to debug this Miriam

Repro:
$ cd ~/wireshark-3.6.2/obj-s390x-linux-gnu
$ /usr/bin/cmake -E env PYTHONIOENCODING=UTF-8 /usr/bin/python3.10 ../test/test.py --verbose --program-path /root/wireshark-3.6.2/obj-s390x-linux-gnu/run suite_decryption

This will trigger the same fails, but run just this test.

And to pick just one sub-case from that like:
$ /usr/bin/cmake -E env PYTHONIOENCODING=UTF-8 /usr/bin/python3.10 ../test/test.py --verbose --program-path /root/wireshark-3.6.2/obj-s390x-linux-gnu/run suite_decryption.case_decrypt_80211.test_80211_wpa2_ft_eap

From here you can modify the python code and run the test programs as you need to find what is wrong.

This bug was fixed in the package lto-disabled-list - 22

---------------
lto-disabled-list (22) jammy; urgency=medium

  * Add wireshark @ arm64 s390x (LP: #1961901)

 -- Miriam España Acebal <email address hidden> Thu, 24 Feb 2022 13:11:15 +0100

Thank you Christian for the sponsorship, the test environment and the commands.

The first test that is failing looks for a string phrase (test/suite_decryption.py @ line 271 self.assertTrue(self.grepOutput('Who has 192.168.1.1')) ). I put a line of debug in the countOutput function (test/subprocesstest.py) to check what was the output from the tshark command executed before... it shows 192.168.5.1 (among others, but always 192.168.5.*):

line is -- 38 12.586605105 02:00:00:00:00:00 → ff:ff:ff:ff:ff:ff ARP 110 Who has 192.168.
5.5? Tell 192.168.5.1--
line is -- 25 10.547097155 02:00:00:00:00:00 → ff:ff:ff:ff:ff:ff ARP 110 Who has 192.168.
5.5? Tell 192.168.5.1--
line is -- 32 11.562579505 02:00:00:00:00:00 → ff:ff:ff:ff:ff:ff ARP 110 Who has 192.168.
5.5? Tell 192.168.5.1--
line is -- 38 12.586605105 02:00:00:00:00:00 → ff:ff:ff:ff:ff:ff ARP 110 Who has 192.168.
5.5? Tell 192.168.5.1--
line is -- 21 15.399324999 02:00:00:00:00:00 → ff:ff:ff:ff:ff:ff ARP 110 Who has 192.168.
5.5? Tell 192.168.5.1--
line is -- 32 16.402513535 02:00:00:00:00:00 → ff:ff:ff:ff:ff:ff ARP 110 Who has 192.168.
5.5? Tell 192.168.5.1--
line is -- 50 17.426588527 02:00:00:00:00:00 → ff:ff:ff:ff:ff:ff ARP 110 Who has 192.168.
5.5? Tell 192.168.5.1--
root@j-wireshark1:~/wireshark-3.6.2/obj-s390x-linux-gnu#
root@j-wireshark1:~/wireshark-3.6.2/obj-s390x-linux-gnu#
root@j-wireshark1:~/wireshark-3.6.2/obj-s390x-linux-gnu#
root@j-wireshark1:~/wireshark-3.6.2/obj-s390x-linux-gnu#
root@j-wireshark1:~/wireshark-3.6.2/obj-s390x-linux-gnu# grep Who miriam.log | wc -l
72
root@j-wireshark1:~/wireshark-3.6.2/obj-s390x-linux-gnu# grep Who miriam.log | grep 192.168.5 | wc -l
72

I checked that, in that entire test/suite_decryption.py file, all the asserts checking for verification of the GTK are with addresses 192.168.5.* except this. I'm wondering if this is intentional or not in the middle of my no-knowledge and inexpertise in tshark, although, on the other hand, the test passes in arm64 (I didn't see it neither the suite launched for other architectures)...

Any ideas from anyone on why the command

tshark -o "wlan.enable_decryption: TRUE" -r wireshark-3.6.2/test/captures/wpa2-ft-eap.pcapng.gz -Y 'wlan.analysis.tk == 65471b64605bf2a04af296284cb4ae2a || wlan.analysis.gtk == 1783a5c28e046df6fb58cf4406c4b22c'

throws 192.168.5.* instead of 192.168.1.* are very welcome (or if you have concerns/suspicious about why this particular case is looking for the 192.168.1.1).

Thanks!

P.S. In the meantime, reviewing the https://www.wireshark.org/docs/wsdg_html_chunked/ChapterTests.html

There is a typo in the debian/rules affecting s390x arch (thanks a lot to @mwhudson for the catch). @Doko already made the change and the build was successful [1].

[1] (https://launchpad.net/ubuntu/+source/wireshark/3.6.2-1ubuntu1/+build/23210749)