"Stack smashing detected" preventing startup on LinuxMint

[Tinksmum]

Describe the bug

Program does not start, when attempted start from command line this message results:

norm@Roger:$ flatpak run com.dosbox_x.DOSBox-X
LOG: Early LOG Init complete
LOG: DOSBox-X's working directory: /home/norm
LOG: Logging init: beginning logging proper. This is the end of the early init logging
LOG: Logging: No logfile was given. All further logging will be discarded.
LOG: DOSBox-X version 2023.09.01 (Linux SDL2)
LOG: SDL: version 2.28.2, Video x11, Audio pulseaudio)
LOG: Host keyboard layout is now ()
LOG: Mapper keyboard layout is now ()
LOG: SDL2 reports desktop display mode 1600 x 900
LOG: The default output for the video system: opengl
*** stack smashing detected ***: terminated
norm@Roger:$

Steps to reproduce the behaviour

Download DOSBox-X Release 2023.09.01 (executable) from GitHub repository
This file : com.dosbox_x.DOSBox-X.flatpakref
Expand, using Archive Manager
Open terminal, type "flatpak run com.dosbox_x.DOSBox-X"

Clicking the dosbox-x icon in the start menu or on the panel causes the icon to dim momentarily but you don't get the explanation.

Expected behavior

Prior to release 2023.09.01, clicking the icon in the start menu or on the panel made dosbox-x open and offer me the option of mounting a directory as the drive letter of my choice. In other words, it just opened and ran.

What operating system(s) this bug have occurred on?

Linux Mint 21.2 Kernel 5.15.0-84

What version(s) of DOSBox-X have this bug?

Release 2023.09.01 Can't find the version number

Used configuration

The most recent config files I have are from February 8, 2021. As I have not been able to get the application open, I expect the configuration is default.

Output log

In the startup sequence it reports no logfile found, System can not find one after the fact either. No file described as "log" exists for today.

Additional information

Prior to this release, DOSBox-X has worked very well on my system. Emulation is accurate and the print to .png file is the best. On some programs it had even started working in color (in the release just before this one).

I have read all issues since 9/1 when the troublesome release came out. One user complained of crash on startup but that was on the Windows port. To the best I can determine, this is the first such problem on Linux reported since the 9/1 release where my problem began.

Thanks in advance for your patience with a noob!

Have you checked that no similar bug report(s) exist?

• I have searched and didn't find any similar bug report.

Code of Conduct & Contributing Guidelines

• I agree to follow the code of conduct and the contributing guidelines.

[joncampbell123]

That would mean some kind of stack/buffer overrun is occurring. Maybe something with OpenGL?

Does it happen if you use output=surface?

[Tinksmum]

I don't know how to do that. Is is added to a part of the run command?

[Torinde]

You can do it by editing the .conf file or by selecting from the menu:

[Tinksmum]

I can't get that far. I can click the icon which puffs up a little and nothing further happens. Alternately, I can type the program name into the terminal where I get a lot of information then my stacks blow up. I never do see the dosbox window. Looking for a way to get around this stack business.

The perfect solution would be to get back the May 1 build where everything worked fine but I can only find the source files and I'm not having much luck with the instructions that come with that, either.

Thanks to both of you folks for responding to my concern. Really miss the program and if I can't find the previous version in "ready to wear" I'll just wait for the next version and hope for better luck.

[Tinksmum]

I did find the setting in the config file, set to "output=surface" same result. I notice that the terminal still reports "The default output for the video system: opengl" even though I specified "surface" when I edited the conf file. I did a document-wide search for "output" and found no other points where it could be changed. Is there a special process by which edits must be made or saved that improves communication with the system?

[maron2000]

While searching for what is wrong, you may want to downgrade your installation to an old one.
https://docs.flathub.org/docs/for-users/downgrading

Edit: Issue #3994 has some practical examples

[Tinksmum]

Thank you Maron2000! While, as you say, I still have the problem to solve (a great learning experience, to be sure) at least I am back in business with the program, which for my purposes is far superior to the other major virtualizers out there albeit, for the moment not the "latest and greatest" of it's line. NB: itsfoss.com has an excellent article on this issue as well.
'

[normikoto]

At least in my case I was able to avoid the error by setting output=surface in my config.

The error seemed to occur when I was booting Windows 95 in Dosbox-X.

Edit: did more testing and it seems like if you install in an older DOSBox-X version like 2023.09.01 it will work normally after updating, but installing with the latest version doesn't work even when setting output=surface.

[johnsirett]

This is affecting Windows 98 install for me... the stack smashing crash consistently occurs when Win98 setup 'goes graphical' after copying setup files.

I'm on Arch Linux, on the Flatpak version, and downgrading to the 2023.09.01 build fixes this for me. Clearly a regression.

[mattcaron]

This is not unique to Flatpack. On Ubuntu 22.04, having compiled v2023.10.06 by hand, I can reproduce the same issue.

To quickly test, start win98se (and possibly others) setup with setup.exe /is (to skip scandisk). It happens as soon as it is finished copying files.

Later this week, I intend to:

1. verify that v2023.09.01 works
2. Run git bisect between the two referenced versions to see if I can nail down the breaking change.

Unfortunately, that takes much compilation time, so it will take me awhile to do so.

[maron2000]

@mattcaron Regarding win98 setup, there is already a graphical palette issue (#4577) with the 2023.10.06 release, so you may want to at first test the latest commit.
As you can see in the mentioned issue, it can be rebooted and can proceed to entering the user information on Windows VS build.

[mattcaron]

@maron2000 Yeah, my brother tripped over #4577 on Windows. My intention was to try it on Linux and see if the issue was here was well, and try to find the cause of that one as well - but I didn't get that far.

Good point on trying to reproduce it on master. Currently compiling 77b9b7a. Will report back.

[mattcaron]

No longer crashes on 77b9b7a30ed186ae0023f3beadd704184cb8d4d8. That is, it gets to the setup screen successfully with output set to either surface or opengl (did not test other options).

The palette issue described in #4577 also seems to not affect this build (though I'm not sure if this is platform specific or not). I will comment there as well, for completeness.

Is doing a git bisect to find out what commit actually fixed it valuable research, or do you already have a good idea as to what fixed it? (I'm not familiar with this codebase, so someone more familiar might say "oh, yeah, I bet it's this change and it's not worth digging in to".)

[maron2000]

I personally can't test Linux Mint so I'm not sure but PR #4505 is likely to be the cause of this issue, and PR #4524 fixed it.

[maron2000]

I see that this issue originaly posted on late September, but the PR #4505 I mentioned above is dated October so there should be some other causes to crash on Linux Mint.