zunzuncito - bugs

A plethora of bug fixes

2024-10-14T20:33:27+02:00

For whatever reason I’ve been uncovering software bugs at an unprecedented rate in the past 10 days. This is by no means a bad thing, I enjoy hunting down and fixing bugs, but it does mean that the additional overhead of drafting a post about each bug becomes a bit too much. So instead here’s a quick overview - the linked patches and merge requests will have more information, if you are interested.</p>

Trash size calculation in KIO</h3>
I noticed this one pretty much right after starting to use Dolphin</a> but did not end up looking into it until quite a bit later: when displaying the size of the items in the trash, the application would always show 0 bytes. This would also cause the automated cleanup of items to fail - Dolphin simply believed that the trash was empty.</p>
KDE uses the KIO</a> framework to provide management of the trash. A recent commit</a> had changed the construction of a QDirIterator</a> in a way that would make it ignore all items when iterating over the trash directory. Thankfully the fix was straightforward and it was merged quickly</a>.</p>

git-shortlog(1) segfaults outside of a git repository</h3>
This one I uncovered as I was writing a small script to give me an overview of commit authors in all the git repositories I had cloned locally. I was happily scanning through my source directory using the `--author</code></a> flag for git-shortlog(1)</code> to generate this, fully expecting git to complain about the few non-git directories I had. Instead of complaints, however, I got a segfault.</p>`
`Turns out that a` `change back in May</a> stopped setting SHA1 as the default object hash. This was done to progress the slow-moving transition to stronger hash functions</a> but inadvertently broke git-shortlog(1)</code> whose argument parsing machinery expected a default hash algorithm to be set. I sent a patch</a> upstream.</p>`

An infinite loop in plasmashell</h3> I regularly use the Activities</a> functionality in Plasma 6 and switch through my activities using Plasma’s built-in activity manager. A couple of days ago I managed to make plasmashell</code>, the provider for Plasma’s desktop and task bar, freeze - I had hit the “up arrow” key in the activity filter text box when there were no results visible. This was perfectly reproducible, so I went to investigate.</p> The cause of the issue was a do-while construct not handling a specific sentinel value, making it loop infinitely. For this one I also opened a merge request</a> upstream.</p>



musl and a curious Rust segfault
2024-10-02T18:42:07+02:00
About a week ago I noticed that fd(1)</code></a>, a
Rust-based alternative to find(1)</code></a>,
would suddenly segfault on my musl</a>-based server
system. Usually a segfault is nothing particularly special to my eyes, but this
one was different. Even just having fd(1)</code> attempt to print its help text was
enough to trigger it, and when I attempted to debug it with
gdb(1)</code></a>, I saw the following:</p>
(gdb) run
Starting program: /usr/bin/fd

Program received signal SIGSEGV, Segmentation fault.
memcpy () at ../src_musl/src/string/x86_64/memcpy.s:18
warning: 18	../src_musl/src/string/x86_64/memcpy.s: No such file or directory
(gdb) bt
#0  memcpy () at ../src_musl/src/string/x86_64/memcpy.s:18
#1  0x00007ffff7ab7177 in __copy_tls () at ../src_musl/src/env/__init_tls.c:66
#2  0x00007ffff7ab730d in static_init_tls () at ../src_musl/src/env/__init_tls.c:149
#3  0x00007ffff7aae89d in __init_libc () at ../src_musl/src/env/__libc_start_main.c:39
#4  0x00007ffff7aae9c0 in __libc_start_main () at ../src_musl/src/env/__libc_start_main.c:80
#5  0x00007ffff74107f6 in _start ()
</code></pre>
So… the segfault is in musl, not in fd</code>!?</p>
I immediately checked whether other basic programs on the system worked. They
did.</em> I checked when I last updated musl. A couple of months ago, so that can’t
be it.</em> I checked specifically whether another Rust-based program worked. It
did.</em></p>
fd(1)</code> had been updated pretty recently, and I remembered it working correctly
about a month ago, so maybe something specific to fd(1)</code>’s usage of Rust
triggered this segfault in musl? I wanted to make sure I could reproduce this in
a development environment, so I cloned the fd(1)</code> repository, built a debug
release, and ran it…</p>
It worked.</em> Huh!?</p>
I decided it was likely that portage</code></a>,
Gentoo’s package manager, was building the program differently, so I took care
to apply the same build flags to the development build. And what can I say:</p>
error: failed to run custom build command for `crossbeam-utils v0.8.20`

Caused by:
  process didn't exit successfully: `fd/target/[...]/build-script-build`
      (signal: 11, SIGSEGV: invalid memory reference)

</code></pre>
… it didn’t even get to build the fd</code> binary proper. A segfault again, too.
What on earth was going on? Why didn’t this also happen in the portage</code> build?</p>
Thankfully I now had a reproducer, so I did the only sensible thing and started
removing random build flags until I got fd</code> to build again. This was our
culprit:</p>
-Wl,-z,pack-relative-relocs
</code></pre>
Already pretty out of my depth considering the fact that I couldn’t fathom how
fd(1)</code> got musl to segfault on memcpy</code>, I now also found that a piece of the
puzzle required me to understand specific linker flags. Oof.</em></p>
Unsure what to do next I decided on a whim to compare the working and the
broken binary with readelf(1)</code>. The most obvious difference was that the
working binary had its .rela.dyn</code>
relocation</a> section
populated with entries whilst the broken one was missing .rela.dyn</code> but had
.relr.dyn</code> instead. At a loss, I stopped and went to do something else.</p>
The story would probably have ended here had I not mentioned this conundrum to
my partner</a> later in the day. We decided to have
another look at the binaries. After some discussion we determined that the
working binary was dynamically linked whilst the broken one wasn’t. The other
working Rust-based program, rg(1)</code></a>,
was also dynamically linked and had been built a while ago, so at some point
portage</code> must have stopped producing Rust executables that were dynamically
linked</strong>. Finally some progress!</p>
At this point we need some background. Early on, Rust decided to use the
x86_64-unknown-linux-musl</code> target to provide statically-linked binaries that
would run on a wide range of systems. Whilst support for dynamically linked
executables on musl systems was added back in
2017</a>, the default behaviour was
never changed, so Gentoo has to make sure to disable static linking by passing
the target-feature=-crt-static</code> flag.</p>
It does this in a system-wide fashion by setting an environment variable in
/etc/env.d</code></a>:</p>
$ cat /etc/env.d/50rust-bin-1.80.1
LDPATH="/usr/lib/rust/lib"
MANPATH="/usr/lib/rust/man"
CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_RUSTFLAGS="-C target-feature=-crt-static"
</code></pre>
This setting should therefore be picked up by portage</code> as well, but when I
examined its build environment it was simply not there. So finally we come to
the last piece of the puzzle: a recent
change</a>
in how RUSTFLAGS</code> are set within portage</code>. Here’s the important part:</p>
local -x CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS="-C strip=none -C linker=${LD_A[0]}"
[[ ${#LD_A[@]} -gt 1 ]] && local CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS+="$(printf -- ' -C link-arg=%s' "${LD_A[@]:1}")"
local CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS+=" ${RUSTFLAGS}"
</code></pre>
Quoth the bash(1)</code> manual:</p>

Local variables “shadow” variables with the same name declared at previous
scopes.  For instance, a local variable declared in a function hides a global
variable of the same name: references and assignments refer to the local
variable, leaving the global variable unmodified.</p>
</blockquote>
When previously the RUSTFLAGS</code> environment variable was only touched when
cross-compiling, it was now overridden. To confirm, I edited the file in
question to include the previous value, and both fd(1)</code> and rg(1)</code> worked
again. Success!</p>
This whole saga was also reported</a> to the
Gentoo bug tracker and promptly fixed. A project for another day is figuring out
exactly how a change from static linking to dynamic linking causes segfaults
like this, because I sure would love to know the details.</p>


KDE Plasma 6 and two bugs
2024-09-18T21:16:12+02:00
For the last couple of months I have been running sway</a> on
my main desktop system after having been forced away from
hikari</a> because of its practically halted
development and incompatibility with newer
wlroots</a> versions.</p>
I never felt completely satisfied with it and the whole experience was rather
joyless, so about a week ago I decided to give KDE Plasma
6</a> a try after a surprisingly
decent experience on the KDE Neon</a> live image.</p>
Whilst undoubtedly greater in its complexity and code size than sway, to me
Plasma 6 seems like one of the last decent desktop environments still remaining.
It’s incredibly customisable (but still comes with good defaults), looks nice
out of the box, and most importantly seems to care about providing a nicely
integrated and featureful experience. This even includes a companion app on
Android, KDE Connect</a>. It remains to be seen
whether it will fully convince me in the long run, but for now I am very
satisfied with it.</p>


		
	</a>
	KDE Plasma 6 with a few windows open</figcaption>
	</figure>
This last week was mostly spent learning about the desktop environment and
setting everything up exactly how I want it to be, but there were two notable
bugs to squash as well.</p>
The first one reared its ugly head once I enabled backwards-compatibility with
Qt5-based apps. I have a couple of such apps still, most prominently
Mumble</a> and Quassel IRC</a>.
Once the latter was built against the KFramework libraries, no more
notifications were shown…</p>
Fixing this ended up taking about two days, most of which were spent discovering
exactly how
KNotifications</a>
work. KDE provides apps with a tighter integration to the notification service,
allowing users to specify which types of notifications to show, and how.
Applications specify their notifications by shipping an <app>.notifyrc</code> file.
KDE ties this file to the application by matching its base name to the name
given to the application (usually through a call to
QCoreApplication::applicationName</code> or when creating
KAboutData</a>).</p>
It turns out that Quassel had recently been
patched</a>
to fix an issue where desktop environments did not show its icon correctly. This
required a call to setDesktopFileName</code> in KAboutData</code> to make environments
aware of the connection. However, Quassel’s application name was
changed in the same commit</a>,
severing its link with the name given through its quassel.notifyrc</code> file. This
seems to have been done in addition to the setDesktopFileName</code> call and was not
necessary to solve the issue the commit was trying to address.</p>
I prepared a pull request</a> fixing
this issue by reverting part of the offending commit.</p>


		
	</a>
	Glad to
have these back</figcaption>
	</figure>
The second bug I randomly came across whilst perusing journalctl</code> and seeing
the following error from Dolphin</a>, KDE’s file
manager:</p>
QString(View)::contains(): called on an invalid QRegularExpression object
(pattern is '\A(?:file:///home/wolf/[Z-A]/?)\z')
</code></pre>
Seeing this immediately made me wonder whether Dolphin plugs a URL straight into
a regular expression without escaping it, and the answer, of course,
is yes</a>.
I spent most of today’s afternoon hunting this issue down and preparing a merge
request</a> that fixes
it in an elegant way.</p>


Getting MPD to parse TIT1 in MP3 files
2022-02-13T18:25:11+01:00
I have a pretty extensive music library that I manage with MPD, the Music
Player Daemon</a>. For the longest time now I have also
been aware of beets</code></a>, another
management system for music libraries. I played around with it a few times but
never took the plunge to have it organize my entire collection.</p>
A few days ago, whilst looking up a particularly obscure recording, I ended up
finding it on MusicBrainz</a> and decided to give beets,
which integrates very tightly with that service, another serious try.</p>
Yesterday I finally completed a first rough import of my entire library (which
encompasses about 20,000 songs in 1400 albums). Given the integration with
MusicBrainz, I now try to map every album to a release in their database. If I
can’t find it there, I instead fall back to an old favourite of mine,
Discogs</a>. beets</code> will automatically update and
correct any tags once I select the right release.</p>
Whilst importing I decided that I should make more use of the “Grouping” tag as
a way to organize albums into an arbitrary group. This is useful if a series of
media features music that was composed by multiple artists. By matching on the
Haibane Renmei</em> grouping, for example, I can find all music that was made for
that show, without having to keep artist names in mind.</p>
“Grouping” seemed well-supported in MPD, but whilst updating some albums that I
(sadly) only have in MP3 format, I found that MPD would not add the grouping
information to its database.</p>
As per the ID3v2.4 standard</a>, the TIT1</code>
frame is used for this kind of information in MP3 files. Sure enough, that tag
was set correctly by beets</code>, and both mutagen-inspect</code> and ffprobe</code> found it.
MPD, however, even though
this PR</a> had been merged almost
3 years ago, refused to pick it up.</p>
After having the #mpd</code> IRC channel sanity-check my configuration, I
investigated some more. Perhaps my version of libid3tag</code> was outdated. It
wasn’t. Perhaps there were some encoding issues, but then why would other tags
from the same file work fine? Couldn’t be that either. I hooked up GDB and found
that
this line from the PR</a>
was never actually reached at all!</p>
I decided to look a bit closer at how exactly MPD reads tags. The specific
scan_id3_tag</code> function that the PR modified is only called in two places,
plugins/DsdLib.cxx</code> and (indirectly) in plugins/MadDecoderPlugin.cxx</code>. I had
neither of these decoders installed, so… MPD just never got to read anything.</p>
Yet how was I getting any</em> tags, then?</p>
After some spelunking in the decoder plugin folders and with the fact on my mind
that the only decoder I had actually compiled in was
FFmpeg</a>, something dawned on me. Perhaps it was FFmpeg
that was reading the tags.</p>
Indeed it was</a>.
Turns out that FFmpeg does all of the heavy lifting here, and MPD really just
asks it for any metadata and parses the ones it understands</strong>.</p>
MPD uses “grouping” as a cross-format identifier for grouping information. It
expects that particular string to be a key in the AVDictionary</code> returned by
FFmpeg
here</a>.
Crucially, FFmpeg
does not expose</a>
TIT1</code> as “grouping” in its metadata conversion table, having MPD drop TIT1</code> on
the floor like a hot potato.</p>
It is debatable where this particular bug should be fixed. I decided to send
a patch</a>
upstream to FFmpeg, given that more than just MPD can benefit from a fix there.
For the next poor soul I also prepared
a PR</a>
that clarifies how exactly MPD reads metadata.</p>