Ubuntu
libsigrok package

Built-in driver list is empty when compiled with LTO

Bug #2025248 reported by Victor Westerhuis
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
sigrok
Unknown
Unknown
libsigrok (Debian)
Fix Released
Unknown
libsigrok (Fedora)
Fix Released
Medium
libsigrok (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

This bug only shows up when libsigrok is compiled with LTO and was reported (https://sigrok.org/bugzilla/show_bug.cgi?id=1433) and fixed (http://sigrok.org/gitweb/?p=libsigrok.git;a=commit;h=da5286bfa5d2dad1e24b9c9442c9875332d84e64) upstream.

I have opened a MR on https://salsa.debian.org/electronics-team/sigrok/libsigrok/-/merge_requests/3.

ProblemType: Bug
DistroRelease: Ubuntu 23.04
Package: libsigrok4 0.5.2-4
ProcVersionSignature: Ubuntu 6.2.0-23.23-generic 6.2.12
Uname: Linux 6.2.0-23-generic x86_64
ApportVersion: 2.26.1-0ubuntu2
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Wed Jun 28 12:30:13 2023
InstallationDate: Installed on 2023-06-27 (1 days ago)
InstallationMedia: Ubuntu 23.04 "Lunar Lobster" - Release amd64 (20230418)
ProcEnviron:
 LANG=nl_NL.UTF-8
 PATH=(custom, no user)
 SHELL=/bin/zsh
 TERM=xterm-256color
 XDG_RUNTIME_DIR=<set>
SourcePackage: libsigrok
UpgradeStatus: No upgrade log present (probably fresh install)

See original description
Revision history for this message
In , atu (atu-redhat-bugs) wrote :

Description of problem:
After upgrade to latest build list of supported hardware becomes empty.
All dependent programs refuses to work.

Version-Release number of selected component (if applicable):
libsigrok-0.5.2-3.fc33.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Update to new libsigrok, install sigrok-cli
2. sigrok-cli -L

Actual results:
Supported hardware drivers:

Supported input formats:
  binary Raw binary logic data

Expected results:
After downgrade to libsigrok-0.5.2-2.fc32.x86_64:
sigrok-cli -L

Supported hardware drivers:
agilent-dmm Agilent U12xx series DMMs
appa-55ii APPA 55II
arachnid-labs-re-load-pro Arachnid Labs Re:load Pro
.... long long list

Additional info:
Manual rebuild does not help.

Revision history for this message
In , atu (atu-redhat-bugs) wrote :

Build without LTO - all OK.

Revision history for this message
In , dan (dan-redhat-bugs-1) wrote :

Thanks for trying, there are many issues revealed by enabling LTO. This issue points more to a bug in libsigrok itself than anything else (glib2 perhaps?). Could you open an upstream bug for it?

Revision history for this message
In , dan (dan-redhat-bugs-1) wrote :

Hmm, I can't reproduce the reported behaviour, I'm always getting the full list of the device/drivers. Can you provide more details about your environment? Is it a fresh install of Rawhide or F-33? Or do you get it also in mock's chroot? Can you attach "rpm -qa" output (all installed rpms)?

Revision history for this message
In , atu (atu-redhat-bugs) wrote :

Created attachment 1715638
List of installed packages

It's not a fresh install. It's a host (working device) with long history and additional self-made packages (*.xf\d\d.*)

Revision history for this message
In , dariomas (dariomas-redhat-bugs) wrote :

I get the same problem with sigrok-cli and pulseview, my system is Fedora 33, fresh install
The same problem is reported with root account

The AppImage downloaded from sigrok site (https://sigrok.org/wiki/Downloads )works very well.

Revision history for this message
In , mironov.ivan (mironov.ivan-redhat-bugs) wrote :

I can confirm this issue on Fedora 33 x86_64. There is an upstream bug report: https://sigrok.org/bugzilla/show_bug.cgi?id=1433. Also, there is a fix from OpenSUSE developers.

I added patch from OpenSUSE into Fedora package: https://src.fedoraproject.org/rpms/libsigrok/pull-request/1

Revision history for this message
In , dan (dan-redhat-bugs-1) wrote :

Ivan, thanks for the bug link and the PR. Could you poke the upstream developers about it, please? The fix hasn't been merged yet, if I see right. I would rather disable LTO in our build than merge a non-upstream fix.

Revision history for this message
In , mironov.ivan (mironov.ivan-redhat-bugs) wrote :

Dan, I found a simpler fix and posted it on Sigrok's Bugzilla. Let's wait for an answer there. I hope that my version is more "mainlineable".

Revision history for this message
In , dan (dan-redhat-bugs-1) wrote :

Thanks, Ivan, yes, your fix is much more straightforward and could be merged downstream.

Jeff, could you, please, take a look at this LTO-related problem? The details are in the upstream ticket (in comment #6).

Revision history for this message
In , updates (updates-redhat-bugs) wrote :

FEDORA-2020-180c961a3b has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-180c961a3b

Revision history for this message
In , updates (updates-redhat-bugs) wrote :

FEDORA-2020-180c961a3b has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-180c961a3b`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-180c961a3b

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Revision history for this message
In , atu (atu-redhat-bugs) wrote :

tested libsigrok-0.5.2-4.fc34.x86_64 - works for me

Revision history for this message
In , updates (updates-redhat-bugs) wrote :

FEDORA-2020-180c961a3b has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Revision history for this message
In , law (law-redhat-bugs) wrote :

Fundamentally this code from src/drivers.c is broken:

        for (const struct sr_dev_driver **drivers = sr_driver_list__start + 1;
             drivers < sr_driver_list__stop; drivers++)
                g_array_append_val(array, *drivers);

The patch referenced in this BZ may work now, but I wouldn't at all be surprised if this breaks again one day.

Depending on two distinct objects being ordered in a particular way in memory is just wrong and I'm confident if I had the time to dig through the ISO C/C++ standards that it's got undefined behavior.

Revision history for this message
In , dan (dan-redhat-bugs-1) wrote :

Thanks Jeff, I'll pass this info to upstream.

Revision history for this message
Victor Westerhuis (viccie30) wrote :
Revision history for this message
Victor Westerhuis (viccie30) wrote :
tags: added: patch
Bug Watch Updater (bug-watch-updater)
Changed in libsigrok (Fedora):
importance: Unknown → Medium
status: Unknown → Fix Released
Victor Westerhuis (viccie30)
affects: debian → libsigrok (Debian)
Victor Westerhuis (viccie30)
description: updated
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "0001-Unbreak-list-of-builtin-drivers-for-LTO-configuratio.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Bug Watch Updater (bug-watch-updater)
Changed in libsigrok (Debian):
status: Unknown → Confirmed
Victor Westerhuis (viccie30)
no longer affects: sigroktest
Victor Westerhuis (viccie30)
tags: added: lto
Brian Murray (brian-murray)
Changed in libsigrok (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Frank Henigman (fjhub) wrote :

This was working in ubuntu 22.04 then broken again in 23.04. LTO must have been off in the former?
In any case, the solution is either disable LTO for libsigrok or go to a newer version of libsigrok.
0.5.2 is 3.5 years old, though to be fair it is the last tagged release.
The patch referred to in #19 was commited to libsigrok 2.5 years ago and I can confirm it also solves the problem.
http://sigrok.org/gitweb/?p=libsigrok.git;a=commit;h=3decd3b1f0cbb3a035f72e9eade42279d0507b89

Revision history for this message
Zach Bloomquist (flotwig) wrote :

I am having this issue on two separate installs of Kubuntu 23.04. I shared a workaround here that involves using Debian's apt packages in the meantime: https://askubuntu.com/a/1483990/844221

Revision history for this message
fenugrec (fenugrec) wrote :

Hi, looking for testers (building with -flto) for this possible upstream fix , https://github.com/sigrokproject/libsigrok/pull/233 .

Revision history for this message
Rob Frohne (frohro) wrote :
Download full text (5.4 KiB)

I thought I'd try and help you out testing this possible upstream fix. I built libsigrokdecode and libsigrok with your pull request and then pulseview. I now see the Saleae Logic logic analyzer, but I get a bunch of errors and a core dump when I try and select the I2C decoder which may be another bug or not. Here is the output from my terminal.
pulseview
QSocketNotifier: Can only be used with threads started with QThread
srd: ImportError: Failed to load decoder ir_sirc: import by name failed: cannot import name 'bitpack_lsb' from 'common.srdhelper' (/usr/share/libsigrokdecode/decoders/common/srdhelper/__init__.py)
srd: Traceback (most recent call last):
  File "/usr/local/share/libsigrokdecode/decoders/ir_sirc/__init__.py", line 26, in <module>
    from .pd import Decoder
  File "/usr/local/share/libsigrokdecode/decoders/ir_sirc/pd.py", line 20, in <module>
    from common.srdhelper import bitpack_lsb
ImportError: cannot import name 'bitpack_lsb' from 'common.srdhelper' (/usr/share/libsigrokdecode/decoders/common/srdhelper/__init__.py)

srd: ImportError: Failed to load decoder sle44xx: import by name failed: cannot import name 'bitpack_lsb' from 'common.srdhelper' (/usr/share/libsigrokdecode/decoders/common/srdhelper/__init__.py)
srd: Traceback (most recent call last):
  File "/usr/local/share/libsigrokdecode/decoders/sle44xx/__init__.py", line 26, in <module>
    from .pd import Decoder
  File "/usr/local/share/libsigrokdecode/decoders/sle44xx/pd.py", line 20, in <module>
    from common.srdhelper import bitpack_lsb
ImportError: cannot import name 'bitpack_lsb' from 'common.srdhelper' (/usr/share/libsigrokdecode/decoders/common/srdhelper/__init__.py)

srd: ImportError: Failed to load decoder st25r39xx_spi: import by name failed: cannot import name 'SrdIntEnum' from 'common.srdhelper' (/usr/share/libsigrokdecode/decoders/common/srdhelper/__init__.py)
srd: Traceback (most recent call last):
  File "/usr/local/share/libsigrokdecode/decoders/st25r39xx_spi/__init__.py", line 31, in <module>
    from .pd import Decoder
  File "/usr/local/share/libsigrokdecode/decoders/st25r39xx_spi/pd.py", line 22, in <module>
    from common.srdhelper import SrdIntEnum
ImportError: cannot import name 'SrdIntEnum' from 'common.srdhelper' (/usr/share/libsigrokdecode/decoders/common/srdhelper/__init__.py)

srd: ImportError: Failed to load decoder adxl345: import by name failed: cannot import name 'SrdIntEnum' from 'common.srdhelper' (/usr/share/libsigrokdecode/decoders/common/srdhelper/__init__.py)
srd: Traceback (most recent call last):
  File "/usr/local/share/libsigrokdecode/decoders/adxl345/__init__.py", line 26, in <module>
    from .pd import Decoder
  File "/usr/local/share/libsigrokdecode/decoders/adxl345/pd.py", line 21, in <module>
    from common.srdhelper import SrdIntEnum
ImportError: cannot import name 'SrdIntEnum' from 'common.srdhelper' (/usr/share/libsigrokdecode/decoders/common/srdhelper/__init__.py)

srd: ImportError: Failed to load decoder nrf905: import by name failed: cannot import name 'SrdIntEnum' from 'common.srdhelper' (/usr/share/libsigrokdecode/decoders/common/srdhelper/__init__.py)
srd: Traceback (most recent call last):
  File "/usr/...

Read more...

Revision history for this message
Rob Frohne (frohro) wrote :

I went and built libsigrok without your pull request and it behaved he same. I could connect to the Saleae and it had a core dump the same way.

Revision history for this message
Rob Frohne (frohro) wrote :

I uninstalled all the Ubuntu packages that had to do with sigrok and rebuilt everything and now it appears everything is working with your pull request. I will try without. So without it the Saleae unit appeared it the devices and there were other options, but when I tried to look at an i2c decoder, it crashed. Then I put your pull request in and it worked. I don't know what that all means, but it seems I have a working system with your pull request and everything built from source.

Revision history for this message
fenugrec (fenugrec) wrote (last edit ):

@frohro thanks a lot for testing this.

To confirm, what we're trying to address upstream is the test described in post #3 above ( https://bugs.launchpad.net/ubuntu/+source/libsigrok/+bug/2025248/comments/3 ), where 'sigrok-cli -L' would show an empty list, prior to my patch.

If I understand correctly your initial issues were because you hadn't yet recompiled PV against the new libsigrok ?

For anyone else testing, it will be important to specify exactly what combination of build versions / sources (commit hash if applicable) were used. All official tagged releases are quite old, and will most likely *not* work when mix-and-matched with components compiled from master.

Bug Watch Updater (bug-watch-updater)
Changed in libsigrok (Debian):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.