Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug]: Three TestRunner cases fail on Linux at develop

Open
  • Is something wrong?
#401 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
42/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
cmake, cpp, linux
Domain
testing-qa

Research direction

The goal is TestRunner passing on Linux. Build examples/TestRunner (CMake, Release) and run the three cases to confirm. For (3) the cause is named: the test project lands under /tmp via juce::File::createTempFile (tracktion_Project.test.cpp:2393) where gio refuses to trash (juce_Files_linux.cpp:180); fix either the temp location or add a deleteFile() fallback at tracktion_ProjectItem.cpp:839. Cases (1) and (2) (tracktion_ClipLauncher.test.cpp:417 and :258) carry no root cause yet and need audio investigation. Done when all 340 cases pass.

Written by the indexing model from the issue text.

Description

Detailed steps on how to reproduce the bug

Build examples/TestRunner with its own CMakeLists (Release, GCC 14.2) and run it with no
arguments on an idle machine with an audio device present (ALSA → PipeWire 1.4.2):

[doctest] test cases:   340 |   337 passed | 3 failed | 0 skipped
[doctest] assertions: 19156 | 19151 passed | 5 failed |

This is on develop at 0d55ef0c. The same three fail on 98fe32df (the pin from the day
before), so it is not a recent regression, and they fail identically when run alone with
-tc="Clip launcher*,FolderBasedProject*" — so it is not interference from parallel load
either.

1. Clip launcher: launch with clip source offset (audio)

tracktion_ClipLauncher.test.cpp:417

CHECK_LT( getRMSLevel (output, tr (5.1, 11.0)), 0.005f ) is NOT correct!
  values: CHECK_LT( 0.063084, 0.005 )

The region that should be silent after the clip stops still carries about −24 dBFS.

2. Clip launcher: quantised launch and stop (audio)

tracktion_ClipLauncher.test.cpp:258

CHECK_GT( getToneMagnitude (output, range, frequency), isAudioTrack ? 0.5f : 0.05f ) is NOT correct!
3. FolderBasedProject: removeProjectItem → removes item and deletes source file

tracktion_Project.test.cpp:2393-2395

*** ERROR: /tmp/temp_43040129/remove_test2/audio2.wav  0 bytes
CHECK( project->removeProjectItem (ref, true) ) is NOT correct!   values: CHECK( false )
CHECK( project->getNumProjectItems() == 0 ) is NOT correct!
CHECK_FALSE( sourceFile.existsAsFile() ) is NOT correct!

This one has a definite Linux-specific cause, and it is not the file's size.
FolderBasedProject::removeProjectItem (tracktion_FolderBasedProject.cpp:449) returns
false when ProjectItem::deleteSourceFile() (tracktion_ProjectItem.cpp:839) fails to
File::moveToTrash() the file. On Linux moveToTrash() is g_file_trash from libgio
(juce_Files_linux.cpp:180), and the test creates its project under
juce::File::createTempFile ({}), i.e. under /tmp, which is tmpfs on most distributions.
gio refuses to trash there:

$ gio trash /tmp/x.wav
gio: file:///tmp/x.wav: Trashing on system internal mounts is not supported

So the subcase fails on any Linux where the temp directory is a separate, system-internal
mount, while it passes on macOS and Windows. The 0 bytes line above is just the diagnostic
dump deleteSourceFile() prints in its if (! ok) branch after the trash attempt has
already failed. The sibling subcase (removes item without deleting source file,
del = false) never reaches moveToTrash and passes.

What is the expected behaviour?

TestRunner passes on Linux, so that a downstream project can use it as a smoke test after
changing its submodule pin. Right now three pre-existing failures have to be memorised and
subtracted by hand — they are indistinguishable from breakage the update itself caused.

For (3) either side would do: the test could create its project somewhere that supports a
trash (or delete the file directly and assert on that), or deleteSourceFile() could fall
back to deleteFile() when the platform reports that trashing is unavailable — though that
turns a recoverable delete into a permanent one, so it is your call.

Not blocking us directly: we use neither the clip launcher nor folder-based projects.

Unit test to reproduce the error?

The failing tests are already in the tree — see the file and line references above.

Operating systems

Linux

What versions of the operating systems?

Debian 13 (trixie), kernel 6.16, GCC 14.2

Architectures

Intel/AMD 64-bit

Testing on the develop branch

The bug is present on the develop branch (0d55ef0c).

Code of Conduct
  • I agree to follow the Code of Conduct
Dominant language
C++
Stars
1.5k
Forks
222
Avg merge
15h 44m
Merged PRs (30d)
33

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Tracktion/tracktion_engine

All issues in Tracktion/tracktion_engine

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.