Milkytracker 1.04 crash on Linux on start application

[termenti]

Here is output when started from text terminal on graphic desktop on X server: `"$ milkytracker Available Renderers: opengl opengles2 software Vendor : Mesa Renderer : NV117 Version : OpenGL ES 3.2 Mesa 23.1.4 SDL: Minimum window size set to 640x480. SDL: Using accelerated renderer. SDL: Renderer supports rendering to texture. 0 0 SDL: Using audio driver: pulseaudio SDL: Buffer size = 2048 samples (requested 2048) MIDI: scanning input ports: MIDI: 0. Midi Through:Midi Through Port-0 14:0 free(): double free detected in tcache 2

Crashed with signal 6 Please submit a bug report stating exactly what you were doing at the time of the crash, as well as the above signal number. Also note if it is possible to reproduce this crash.

A backup has been saved to /home/user/BACKUP00.XM

Przerwane (zrzut pamięci)"

"$ coredumpctl info PID: 5701 (milkytracker) UID: 1000 (user) GID: 1000 (user) Signal: 6 (ABRT) Timestamp: Tue 2023-07-25 20:18:31 CEST (2min 15s ago) Command Line: milkytracker Executable: /usr/bin/milkytracker Control Group: /user.slice/user-1000.slice/session-1.scope Unit: session-1.scope Slice: user-1000.slice Session: 1 Owner UID: 1000 (user) Boot ID: 155b573ec14a420caa6be0248684615d Machine ID: 4e6eb13c33544bc2bce3efeaf0d12478 Hostname: home Storage: none Message: Process 5701 (milkytracker) of user 1000 dumped core. $ coredumpctl dump PID: 5701 (milkytracker) UID: 1000 (user) GID: 1000 (user) Signal: 6 (ABRT) Timestamp: Tue 2023-07-25 20:18:31 CEST (2min 36s ago) Command Line: milkytracker Executable: /usr/bin/milkytracker Control Group: /user.slice/user-1000.slice/session-1.scope Unit: session-1.scope Slice: user-1000.slice Session: 1 Owner UID: 1000 (user) Boot ID: 155b573ec14a420caa6be0248684615d Machine ID: 4e6eb13c33544bc2bce3efeaf0d12478 Hostname: home Storage: none Message: Process 5701 (milkytracker) of user 1000 dumped core. Coredump entry has no core attached (neither internally in the journal nor externally on disk)."`

Previous version 1.03.00-3 was running good.

I tried to run it like this '$ NO_OPENGL=1 milkytracker' from bash as it is written in file /usr/share/doc/MilkyTracker/readme_unix, but it crash like earlier (NO_OPENGL=1 is ignored).

I don't know and can't find it working how to run it in different renderer: opengl, opengles2, software. I tried start in terminal: env NO_OPENGL=1 milkytracker env SDL_RENDER_DRIVER=software milkytracker env __GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 milkytracker __GLX_VENDOR_LIBRARY_NAME=mesa milkytracker env SDL_AUDIODRIVER=alsa milkytracker but it still crashes.

[SarahCosmosys]

I'm having the same issue on a fresh install of Arch Linux. It doesn't happen with the official AppImage for the latest release.

[SarahCosmosys]

Have you tried the AppImage from the github releases? What distro are you using? It might be an issue with distro packaging and not an issue with MilkyTracker itself.

[termenti]

I also use Arch Linux. You may have right that it may be distro packaging problem. I don't want to use software outside of packages, so I won't try AppImage, I just wait for bug fix.

Here is my thread on Arch forum: https://bbs.archlinux.org/viewtopic.php?id=287470

And thanks for response!

[liaminventions]

same thing happens to me... the appimage seems to work though.

[AlbeyAmakiir]

Same issue. Arch linux. Package crashes immediately on start. AppImage works fine.

[Penaz91]

Greetings, I'm having the same issue: Artix Linux (ArchLinux derivative).

Hoping to help a bit, I'm attaching my system information (inxi -GSC -xx) and the output of bt full from GDB after the crash.

Thank you!

inxi.txt

bt_full.txt

[denilsonsa]

After doing git bisect between v1.03.00 and v1.04.00, it seems the commit a8e76b08c0213c659751fa4bbd86a2d8ce54481f was the first one to introduce crashes. Although that one crashed with:

MIDI: scanning input ports:
MIDI:  0. Midi Through:Midi Through Port-0 14:0

Crashed with signal 4

Illegal instruction

Apparently, 7e9171488fc47ad2de646a4536794fda21e7303d fixed the issue. Which makes sense, as the first commit introduced a function that returns the number of ports but forgot to include the return statement, and this last commit is a one-line fix that adds the return value. This also explains the different error messages (either double free or illegal instruction).

[coderofsalvation]

indeed this was fixed.

[AlbeyAmakiir]

Will there be a bugfix release that includes this in the near future, since it makes at least the Arch package unusable?

[coderofsalvation]

Hi Albey. Like @denilsonsa said this was fixed by https://github.com/milkytracker/MilkyTracker/commit/7e9171488fc47ad2de646a4536794fda21e7303d Any idea why your Arch is not pointing to the latest release?

[AlbeyAmakiir]

You mean release 1.04.00? My arch is using that. It was built July 16th, before this bug was reported. If that is the release you mean, then maybe the fix only covered some cases?

[coderofsalvation]

So the timeline was basically this:

• 4 july: release
• 6 july: bugfix https://github.com/milkytracker/MilkyTracker/commit/7e9171488fc47ad2de646a4536794fda21e7303d
• releases were updated at 6 july

I can't really explain how arch would somehow build the 4th of july release on the 16th :(

Does the appimage and/or zip also produce exactly the same bug on your system?

[denilsonsa]

As a quick check:

• 1.04.00 is the latest release, with date: Jul 5, 2023, 11:00 AM GMT+2
• Commit fixing it has date: Jul 6, 2023, 2:38 PM GMT+2
• The list of commits for tag v1.04.00 doesn't include that commit (which, by the way, is the latest commit on master).

Thus, based on this, I'm assuming the latest release (1.04.00) doesn't contain the fix and thus is broken.

Also, please consider the exact date with a grain of salt. Each person living in a different timezone will potentially see a different date. That's why I'm including the full datetime in my reply just above.

---

releases were updated at 6 july

Well, not here. Maybe you fixed it but forgot to publish? I'm not sure.

Screenshot of the releases page


---

Regardless, maybe the best solution would be to tag and publish a new minor revision 1.04.01.

I don't want to prove anyone right or wrong, all I want is to find a solution. :) I appreciate your work in publishing and maintaining open-source projects! Thank you!

[coderofsalvation]

aha! Thanks for pointing that out. I guess the tag was off (I updated the github release only). I've moved tag is to the bugfix-commit.

[denilsonsa]

I haven't tested the release, but the github release still shows an earlier date (Jul 5). There is also a possibility that some people will get confused because the tag doesn't match the released code anymore (or the previously downloaded and packaged code).

So, maybe, just maybe, it might be easier/better to keep the tag pointing to the real release, and just create a new tag and a new release for 1.04.01. I believe it's also easier for any package maintainers, as they just need to bump their package version.

[coderofsalvation]

Hehe, its a bit confusing indeed :) The github release-section allows updating a release but does not change the date..this is where worlds drifted apart :)

So the 'real' release depends thru which lens we're looking at it:

• thru the lens of the repo, the (5 july) v1.04 git tag is the official one (with the bug)
• thru the lens of github release-section, v1.04 is the (updated at 6 july) release

The latter has been a win for (dissappointed) people downloading milkytracker thru the website. If you have other thoughts let me know, I'm a bit confused concerning the optimal way to 'hotfix' the latest release (for website AND maintainers). Perhaps I should indeed never 'hotfix' a release thru the github interface again. At the same time, sometimes bugs happen after word is already out there (v1.04 is out! see the GH release-link here' e.g.). A bit of a catch22 :/

[denilsonsa]

Perhaps I should indeed never 'hotfix' a release thru the github interface again. At the same time, sometimes bugs happen after word is already out there (v1.04 is out! see the GH release-link here' e.g.).

Perhaps the easiest (as in… less confusing and less ambiguous) would be to release a new minor revision, and edit the text for the (broken) release to ask people to look at the newer one.

Still, that's just my opinion.

[240-185]

Hello,

The package in Ubuntu 23.10 also points to this broken version. Where can I find the patched binary for it?

Searching all over the github to try find in vain the patched binary is very frustrating.

Hehe, its a bit confusing indeed :) The github release-section allows updating a release but does not change the date..this is where worlds drifted apart :)

Just release a new version FFS!

[coderofsalvation]

@240-185 well nice to meet you too!