Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux Bits for 1.02 #201

Merged
merged 18 commits into from Jan 28, 2023
Merged

Linux Bits for 1.02 #201

merged 18 commits into from Jan 28, 2023

Conversation

mlauss2
Copy link
Contributor

@mlauss2 mlauss2 commented Jan 21, 2023

(this supersedes #188 )

Linux Bits for TFE:

  • crash fixes found during testing
  • compile fixes for newer gcc/clang compilers
  • CMake build system (it's possible to build distro packages with this, I have a Gentoo ebuild for this branch).
  • missing code for Linux compatibilty, also 32bit.
    • The linux pieces have additional code to deal with the few cases of relative path usage in the TFE Codebase (for Fonts, Shaders, UI_Text ..) since having those installed in the same directory as the main executable does not fly with most linux distros. Instead, the implementation adds "system paths" to look for them in. This is a noop on windows (i.e. nothing should change for windows: put everything in one folder).

Big thanks to Matthew Gilmore, I took a few patches from your initial port, and all the testers
who commented on #176

Source build tested with gcc-11, gcc-12, gcc-13 and clang-15 and VC++ on x64, as well as i686 and mips32el.

@spacekomet
Copy link

Hey, what did you do with the Music? It's a lot more full and richer now. :)
Thanks for your effort to improve the linux port.

However, in the TFE Sound menu, I can see and select only one midi device.
In the previous linux version, together with the latest midi patch #171 I was able to select all of them (I basically have just the fluidsynth and the dummy midi device).

There is also this annoyance still with the browse functionality in the TFE Game menu. For me (Manjaro, KDE Plasma) nothing happens, when the browse button is pressed.

@mlauss2
Copy link
Contributor Author

mlauss2 commented Jan 21, 2023

Hey, what did you do with the Music? It's a lot more full and richer now. :) Thanks for your effort to improve the linux port.

However, in the TFE Sound menu, I can see and select only one midi device. In the previous linux version, together with the latest midi patch #171 I was able to select all of them (I basically have just the fluidsynth and the dummy midi device).

Try my "linux3-audio-next" branch. You can switch midi devices on the fly there, I regularely test with timidity and fluidsynth side by side (timidity sounds much better, tbh).

There is also this annoyance still with the browse functionality in the TFE Game menu. For me (Manjaro, KDE Plasma) nothing happens, when the browse button is pressed.

Huh, the version of Portable File Dialogs shipped with TFE probably doesn't know how to handle this on Manjaro.
Do you have "zenity" installed? I think this is used as a last-resort option if the DE cannot be identified.

@spacekomet
Copy link

With the same soundfont timidity indeed sounds slightly better (btw: I simply running it with -iA parameters)
I installed zenity and now I get the popup to browse for DF installation, thanks. Don't remember if it was mentioned somewhere as a dependency.

And with linux3-audio-next I'm able to change the audio ports, great.

I should mention also there is this old annoying shader issue, which it seems I'm the only one having it. Workaround for me is, to change the fraq files in Shaders folder (walls, sprites and quad), otherwise I get green walls, stormtroopers and also rocketlauncher and fist weapons. Not really related to the linux port, more to my hardware it seems.

@mlauss2
Copy link
Contributor Author

mlauss2 commented Jan 21, 2023

With the same soundfont timidity indeed sounds slightly better (btw: I simply running it with -iA parameters) I installed zenity and now I get the popup to browse for DF installation, thanks. Don't remember if it was mentioned somewhere as a dependency.

I had to read the the code to get this information. It should be mentioned in the README that either "zenity" or KDE are required for file dialogs as a runtime dependency once TFE has official linux support.

And with linux3-audio-next I'm able to change the audio ports, great.

Excellent,

I should mention also there is this old annoying shader issue, which it seems I'm the only one having it. Workaround for me is, to change the fraq files in Shaders folder (walls, sprites and quad), otherwise I get green walls, stormtroopers and also rocketlauncher and fist weapons. Not really related to the linux port, more to my hardware it seems.

This looks like an issue with mesa driver for GT7 and older hardware. I suggest you open a bugreport on Mesa and give as much information as possible (I do have a Haswell (GT7.5) machine to test on, and it works well there).

@SeongGino
Copy link

Seems the same situation as the last PR is still happening with this branch on my system, so I can't really say much by virtue of it not even exiting with a message.

@Agetian
Copy link

Agetian commented Jan 22, 2023

Happy to see a renewed branch!
This branch (both the standard one and the audio-next one) work fine on my Linux Mint 21.1, I was able to successfully compile using CMake with no issues.
@SeongGino Does the game provide any console output for you when it tries to start? The only time I got similar behavior (with the game providing no GUI output whatsoever and just closing immediately without getting to the main menu) is if the executable is in the wrong directory (in my experience, it has to be in the same directory where the "UI_Text" and "Mods" folder are).

@SeongGino
Copy link

SeongGino commented Jan 22, 2023

@Agetian executable tfelnx is being run directly in the build directory (which has symlinks to necessary UI_Text, etc.). Like described, nothing, not even a blip.
2023_01-22-004404

As mentioned in previous PR to this one, the program output worked before in the first Linux draft PR.
(Because I can anticipate this being asked; Arch Linux, kernel 6.1.2, Plasma 5.26.5)

@mlauss2
Copy link
Contributor Author

mlauss2 commented Jan 22, 2023

@Agetian executable tfelnx is being run directly in the build directory (which has symlinks to necessary UI_Text, etc.). Like described, nothing, not even a blip. 2023_01-22-004404

As mentioned in previous PR to this one, the program output worked before in the first Linux draft PR.

That is strange, it means it's already erroring out somewhere in the first 10 lines if main().
run it as "strace -o tfe.txt ./tfelnx" and post the tfe.txt file somewhere.

@mlauss2
Copy link
Contributor Author

mlauss2 commented Jan 22, 2023

@Agetian executable tfelnx is being run directly in the build directory (which has symlinks to necessary UI_Text, etc.). Like described, nothing, not even a blip. 2023_01-22-004404

As mentioned in previous PR to this one, the program output worked before in the first Linux draft PR.

please apply the following patch so we can narrow it down a bit:

diff --git a/TheForceEngine/TFE_FileSystem/paths-posix.cpp b/TheForceEngine/TFE_FileSystem/paths-posix.cpp
index fd92141d..e1001446 100644
--- a/TheForceEngine/TFE_FileSystem/paths-posix.cpp
+++ b/TheForceEngine/TFE_FileSystem/paths-posix.cpp
@@ -58,7 +58,7 @@ namespace TFE_Paths
 
                if (!home) {
                        // whoa, how did that happen?
-                       TFE_System::logWrite(LOG_ERROR, "paths", "$HOME is undefined! Defaulting to /tmp");
+//                     TFE_System::logWrite(LOG_ERROR, "paths", "$HOME is undefined! Defaulting to /tmp");
                        home = strdup("/tmp");
                }
 
diff --git a/TheForceEngine/main.cpp b/TheForceEngine/main.cpp
index 66df02dd..946d28a4 100644
--- a/TheForceEngine/main.cpp
+++ b/TheForceEngine/main.cpp
@@ -513,11 +513,16 @@ int main(int argc, char* argv[])
        TFE_CrashHandler::setThreadExceptionHandlers();
        #endif
 
+printf("1\n");
        // Paths
        bool pathsSet = true;
+printf("2\n");
        pathsSet &= TFE_Paths::setProgramPath();
+printf("3 %b\n", pathsSet);
        pathsSet &= TFE_Paths::setProgramDataPath("TheForceEngine");
+printf("4 %b\n", pathsSet);
        pathsSet &= TFE_Paths::setUserDocumentsPath("TheForceEngine");
+printf("5 %b\n", pathsSet);
        TFE_System::logOpen("the_force_engine_log.txt");
        TFE_System::logWrite(LOG_MSG, "Main", "The Force Engine %s", c_gitVersion);
        if (!pathsSet)
@@ -525,6 +530,7 @@ int main(int argc, char* argv[])
                TFE_System::logWrite(LOG_ERROR, "Main", "Cannot set paths.");
                return PROGRAM_ERROR;
        }
+printf("6\n");
 
        // Before loading settings, read in the Input key lists.
        if (!TFE_Input::loadKeyNames("UI_Text/KeyText.txt"))

@SeongGino
Copy link

SeongGino commented Jan 22, 2023

tfe.txt

So I think I found the issue, at the very bottom of the output:

read(3, "\"libraryfolders\"\n{\n\t\"0\"\n\t{\n\t\t\"pa"..., 8191) = 3733
close(3)                                = 0
newfstatat(AT_FDCWD, "C:/Program Files (x86)/Steam/steamapps/common/outlaws/", 0x7ffd79e67150, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "C:/Program Files/Steam/steamapps/common/outlaws/", 0x7ffd79e67150, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "C:/Program Files (x86)/GOG.com/outlaws/", 0x7ffd79e67150, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "C:/GOG Games/outlaws/", 0x7ffd79e67150, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "D:/Program Files (x86)/Steam/steamapps/common/outlaws/", 0x7ffd79e67150, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "D:/Program Files/Steam/steamapps/common/outlaws/", 0x7ffd79e67150, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "D:/Program Files (x86)/GOG.com/outlaws/", 0x7ffd79e67150, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "D:/GOG Games/outlaws/", 0x7ffd79e67150, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/seong/home/seong/.local/share/TheForceEngine/settings.ini", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/seong/home/seong/.local/share/TheForceEngine", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/seong/home/seong/.local/share/TheForceEngine/settings.ini", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/seong/home/seong/.local/share/TheForceEngine", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
getpid()                                = 29082
getpid()                                = 29082
exit_group(1)                           = ?
+++ exited with 1 +++

For some reason, it's parsing the local data directory as /home/username/home/username/.local/share/TheForceEngine. I made a home folder inside my user's home directory, then seong, and so on. Launched it again, and now it's booting.
(Tried with the linux3-audio-next branch, was crashing, so am using the linux3 branch now and it is in fact working and I can get to the menu)

FWIW, I had put these exports in my ~/.bash_profile for some applications to use XDG paths:

# Set XDG aliases
export XDG_DATA_HOME=$HOME/.local/share
export XDG_CONFIG_HOME=$HOME/.config
export XDG_STATE_HOME=$HOME/.local/state
export XDG_CACHE_HOME=$HOME/.cache

So just as a test, I blanked out just the first one as so:

$ export XDG_DATA_HOME=

then removed the redundant nested home-inside-/home, launched tfelnx, and sure enough it boots fine now.

So I'm guessing somewhere the code is defaulting on $HOME and then also adding the value of XDG_DATA_HOME, which is why it's making that weird nested home-in-/home when the value's defined. No other app on my system has issues finding files, so that's the only conclusion I can come up with.

EDIT: With the variable disabled, the main files are being dumped into ~/TheForceEngine and imgui.ini in current working directory:

[seong@HighlyResponsive test]$ tfelnx
[Main] The Force Engine 
v1.02.000-6-g779b9745

[Paths] Program Path: "/home/seong/test/"
[Paths] Program Data: "/home/seong/TheForceEngine/"
[Paths] User Documents: "/home/seong/TheForceEngine/"
[Paths] Source Data: ""
[Startup] TFE_System::init

Sorry about all that, I'm too caught up in work at the moment to followup on things as much as I'd like.

@mlauss2
Copy link
Contributor Author

mlauss2 commented Jan 22, 2023 via email

@SeongGino
Copy link

SeongGino commented Jan 22, 2023

Just my $0.02, I'm not really aware of any big distros that deviate from ~/.local/share for user data so that would cover pretty much every "average user" usecase - if it somehow does use a different directory, then it's safe to assume it's a niche edgecase distribution and/or is being run by an advanced user, and can declare/use TFE_DATA_HOME instead.
Might be ugly, but I'm also not the one writing this.
Unless someone else who's more knowledgeable can chime in or contribute any better ideas.

EDIT: seems that declaring TFE_DATA_HOME seems to cause the same problem as having a XDG_DATA_HOME, at least atm.

@mlauss2
Copy link
Contributor Author

mlauss2 commented Jan 22, 2023

EDIT: With the variable disabled, the main files are being dumped into ~/TheForceEngine and imgui.ini in current working directory:

Yeah you need to really unexport XDG_DATA_DIR; even an empy XDG_DATA_DIR will change behavior.
I'll just remove that part again and go with ~/.local/share//

As for imgui.ini.. I don't want to touch imgui code, but I think a chdir() to ~/.local/share/ at app startup should suffice.
I'll add a patch soon.

@mlauss2
Copy link
Contributor Author

mlauss2 commented Jan 22, 2023

EDIT: seems that declaring TFE_DATA_HOME seems to cause the same problem as having a XDG_DATA_HOME, at least atm.

That is by design: if you want to store your TFE Data somewhere else (or, maybe, have a second "profile") then set this to a relative path (i.e. export TFE_DATA_HOME=/p1 will expand to /home/user/p1/TheForceEngine/).

Please pull the branch again and give it a test, it should fix your 2 issues.

@mlauss2
Copy link
Contributor Author

mlauss2 commented Jan 22, 2023 via email

@SeongGino
Copy link

SeongGino commented Jan 22, 2023

Yeah you need to really unexport XDG_DATA_DIR

TIL export -n exists.

Anyways, pulled in the branch fresh and built, does seem to resolve my original issue.

That is by design: if you want to store your TFE Data somewhere else (or, maybe, have a second "profile") then set this to a relative path (i.e. export TFE_DATA_HOME=/p1 will expand to /home/user/p1/TheForceEngine/).

I think that was my problem: I was not aware that the relative directory needs a backslash for this variable. Usually having a backslash at the start of a variable denotes that it's an absolute path (because out-of-context, it sounds like you're telling it to start from / (root)).
I did in fact try this on the new build as well:

TFE_DATA_HOME=/TheForceEngineExplicit tfelnx

And it makes said folder in current working directory. Maybe consider clarifying this (either don't require a backslash for relative path, or documentation)?

@SeongGino
Copy link

Can you narrow down where? Or provide me with a log and backtrace? Thanks! Your setup seems to be quite good at finding all the corner cases :)

I will take that as a compliment!
Switched to linux3-audio-next branch here.

Console output:

[seong@HighlyResponsive build]$ ./tfelnx 
[Main] The Force Engine 
v1.02.000-6-g779b9745

[Audio] TFE_AudioSystem::startup()
[Audio] TFE_AudioDevice::startup() RtAudio 5.2.0
[MidiPlayer] TFE_MidiPlayer::startup()
[MIDI Device] TFE_MidiDevice::startup() RtMidi 5.0.0
[Paths] Program Path: "/home/seong/TheForceEngine/build/"
[Paths] Program Data: "/home/seong/.local/share/TheForceEngine/"
[Paths] User Documents: "/home/seong/.local/share/TheForceEngine/"
[Paths] Source Data: ""
[Startup] TFE_System::init
[Display] Fullscreen enabled.
[Display] Vertical Sync enabled.
[RenderBackend] OpenGL Device Tier: 3
[Startup] TFE_AudioSystem::init
Segmentation fault (core dumped)

tfe's log (~/.local/share/TheForceEngine): the_force_engine_log.txt

stack trace: tfe.txt

@spacekomet
Copy link

I'm having a bug in mod Dark tide 2 #203 . I'm not sure, if this is only related to the linux port, my hardware or it's a general problem. Perhaps someone can confirm?

@mlauss2
Copy link
Contributor Author

mlauss2 commented Jan 23, 2023

Nah I meant:
make a debug build:
cmake -DCMAKE_BUILD_TYPE=debug /path/to/tfe-source
and run the binary under gdb:
gdb ./tfelnx
type "r" to run it, when the segv occurs, type "bt" in gdb.

@mlauss2
Copy link
Contributor Author

mlauss2 commented Jan 23, 2023

I'm having a bug in mod Dark tide 2 #203 . I'm not sure, if this is only related to the linux port, my hardware or it's a general problem. Perhaps someone can confirm?

It doesn't happen with software rendering, I'm inclined to believe its a general (non-linux-related) bug, or even a bug in the map itself.

@mlauss2
Copy link
Contributor Author

mlauss2 commented Jan 23, 2023

I think that was my problem: I was not aware that the relative directory needs a backslash for this variable. Usually having a backslash at the start of a variable denotes that it's an absolute path (because out-of-context, it sounds like you're telling it to start from / (root)). I did in fact try this on the new build as well:

TFE_DATA_HOME=/TheForceEngineExplicit tfelnx

You are right, that was completely counterintuitive. I fixed this up now: an absolute path is now handled as an absolute path, while a relative path is now handled relative to the current directory. If "TFE_DATA_HOME" is set and not blank, the path information in it will be used without the added "TheForceEngine". Give it a try please.

@mlauss2
Copy link
Contributor Author

mlauss2 commented Jan 23, 2023

Can you narrow down where? Or provide me with a log and backtrace? Thanks! Your setup seems to be quite good at finding all the corner cases :)

I will take that as a compliment! Switched to linux3-audio-next branch here.

It was intended that way.

[Startup] TFE_AudioSystem::init
Segmentation fault (core dumped)

So somewhere in usable api detection. I pushed a tentative workaround to the branch, please repull and test.

On startup, screenCapture will cause random crashed because
of uninitialized m_capures member.

Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
When freeing items with allocator_free, at some point all
members of the Allocator become ALLOC_INVALID_PTR, then
allcator_getHead crashes due to trying to derefence an invalid
Allocator::head pointer.

Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
The GobMemoryArchive does not define an ARCHIVE_GOB type anywhere.
To fix this, add a new constructor to the base class to set the
archive type at instantiation time.
This fixes a crash on Linux with Mods (quitting while running a
mod, or loading a savegame away from a mod, where the memory gob
freeing causes a crash).

Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
TFE sends 3 bytes for every MIDI message; however there are
some, among them PROGRAM CHANGE (to define instrument to use),
which only have 1 argument byte instead of 2.
The Linux ALSA midi parser gets confused by the 3rd byte.
So adhere to MIDI and only send 2 byte messages for PROGRAM CHANGE.
(there are other midi messages with only 2 bytes, but TFE doesn't
use them).

This fixes the piano-only output on Linux.

Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
There are 2 BeginChild() that are close with End(), fix that.

Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
gcc and clang complain about the 2nd parameter to ImSetSoundTrigger();
Fix with a reinterpret_cast<>

Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
clang-15 stops build with this error:
TheForceEngine/TFE_Jedi/IMuse/imDigitalSound.cpp:61:13: error: copying variable of type 'atomic_s32' (aka 'atomic<int>') invokes deleted constructor
        atomic_s32 s_digitalPause = 0;

Remove the explicit initialization.

Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
mlauss2 and others added 11 commits January 23, 2023 21:19
- _strlwr()/_strupr() are Windows CRT only, roll our own and use them
  throughout the codebase.
- replace the windows-oly *_s() string functions with portable
  equivalents
Windows and Linux/Posix have different opinions on the length of
"(unsigned) long" and other C types on 64bit:  Windows compilers
keep 32bit and 64bit identical, while they differ on POSIX.

Work around this by using the explicitly sized types, and letting
the compiler sort it out.
gcc-13 is picky about preprocessor macros and missing arguments
in place of VA_ARGS.

Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
unlike previous versions, gcc-13 does no longer implicitly include
a lot of c++ header files.  Add them to the files that need them.

Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Fixes fullscreen on Linux Window managers.
GCC complains about an invalid explicit specialization outside
a namespace scope:
filestream.h:67:19: error: explicit specialization in non-namespace scope 'class FileStream'

Work around by explicitly implementing the template.

Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Implement missing pieces for Linux support:
- CMake buildsystem
- posix/linux specific file- and pathhandling bits.
  this implementation also takes case-sensitivity of
  unix filesystems into account.
- add infrastructure to look up system files (shaders, doc,
  fonts, ...) independently from the main binary (for distro
  packaging).
- fix up the linux thread implementation.
- fix up 32bit target build.
- crash handler skeleton.
- can look for game data files in local Steam installation on
  multiple libraries.
  (GOG linux games do not leave trails about their installation
   paths in any central location, so gog detection is missing).

based partly on previous work by Matthew Gilmore.

Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
On some Linux DEs, the native file dialog does a case sensitive
search for file extensions.  Add the uppercase extensions
LAB and GOB as well to fix at least Gnome/GTK file dialogs being
unable to select the DARK.GOB file.

Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
@SeongGino
Copy link

Nah I meant: make a debug build: cmake -DCMAKE_BUILD_TYPE=debug /path/to/tfe-source and run the binary under gdb: gdb ./tfelnx type "r" to run it, when the segv occurs, type "bt" in gdb.

Sorry for the wait.

Backtrace says:

Thread 1 "tfelnx" received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76
76              VPCMPEQ (%rdi), %ymm0, %ymm1
(gdb) bt
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76
#1  0x00007ffff7a3ac37 in ?? () from /usr/lib/librtaudio.so.6
#2  0x00007ffff6f6cde5 in context_get_sink_info_callback (pd=pd@entry=0x555556914450, command=command@entry=2, 
    tag=tag@entry=3, t=t@entry=0x555556313aa0, userdata=userdata@entry=0x55555692a410)
    at ../pulseaudio/src/pulse/introspect.c:268
#3  0x00007ffff6cf5e62 in run_action (pd=0x555556914450, r=0x555556308f60, command=2, ts=0x555556313aa0)
    at ../pulseaudio/src/pulsecore/pdispatch.c:291
#4  0x00007ffff6cf709c in pa_pdispatch_run (pd=0x555556914450, packet=packet@entry=0x55555631e130, 
    ancil_data=ancil_data@entry=0x555556914418, userdata=userdata@entry=0x55555691a310)
    at ../pulseaudio/src/pulsecore/pdispatch.c:344
#5  0x00007ffff6f66244 in pstream_packet_callback (p=<optimized out>, packet=0x55555631e130, ancil_data=0x555556914418, 
    userdata=0x55555691a310) at ../pulseaudio/src/pulse/context.c:364
#6  0x00007ffff6cfbf85 in do_read (p=p@entry=0x555556914180, re=re@entry=0x555556914300)
    at ../pulseaudio/src/pulsecore/pstream.c:1023
#7  0x00007ffff6cfce1f in do_pstream_read_write (p=0x555556914180) at ../pulseaudio/src/pulsecore/pstream.c:261
#8  0x00007ffff6f79dd8 in dispatch_pollfds (m=0x555556918d90) at ../pulseaudio/src/pulse/mainloop.c:676
#9  pa_mainloop_dispatch (m=m@entry=0x555556918d90) at ../pulseaudio/src/pulse/mainloop.c:917
#10 0x00007ffff6f7a43b in pa_mainloop_iterate (m=m@entry=0x555556918d90, block=block@entry=1, 
    retval=retval@entry=0x7fffffffca6c) at ../pulseaudio/src/pulse/mainloop.c:948
#11 0x00007ffff6f7a4e1 in pa_mainloop_run (m=0x555556918d90, retval=0x7fffffffca6c) at ../pulseaudio/src/pulse/mainloop.c:963
#12 0x00007ffff7a32f77 in ?? () from /usr/lib/librtaudio.so.6
#13 0x00007ffff7a336e9 in ?? () from /usr/lib/librtaudio.so.6
#14 0x0000555555590396 in RtAudio::getDeviceCount (this=0x5555567ecbe0) at /usr/include/rtaudio/RtAudio.h:857
#15 TFE_AudioDevice::audApiAutoselect () at /home/seong/TheForceEngine/TheForceEngine/TFE_Audio/audioDevice.cpp:89
#16 TFE_AudioDevice::init (audioFrameSize=audioFrameSize@entry=256, deviceId=deviceId@entry=0, useNullDevice=useNullDevice@entry=false, apiIdx=<optimized out>) at /home/seong/TheForceEngine/TheForceEngine/TFE_Audio/audioDevice.cpp:118
#17 0x00005555555918c2 in TFE_Audio::init (useNullDevice=<optimized out>, outputId=0) at /home/seong/TheForceEngine/TheForceEngine/TFE_Audio/audioSystem.cpp:105
#18 0x00005555556ce068 in main (argc=1, argv=0x7fffffffd798) at /home/seong/TheForceEngine/TheForceEngine/main.cpp:632

@mlauss2
Copy link
Contributor Author

mlauss2 commented Jan 26, 2023

Oh cool:
what does "info registers" show for rdi and ymm0/1 registers?
RtAudio or PulseAudio have a problem here, maybe a null pointer fed to strlen() or the input string pointer is not properly 16-byte aligned.
Either way, not a problem with TFE per se, but your libraries.

@mlauss2
Copy link
Contributor Author

mlauss2 commented Jan 26, 2023

Could you please try this little test program? It's a distilled version of what is in your backtrace.
If it also segfaults, I suggest you open a bug report to your distro. If not, then, hmm, I have no idea yet :)

https://gist.github.com/mlauss2/8a7be0f6c8bc15693fdff6330b4c71bc

@SeongGino
Copy link

SeongGino commented Jan 27, 2023

$ ./rtatest
trying 4: Jack
num ports: 9
trying 2: Pulse
[1]    19111 segmentation fault (core dumped)  ./rtatest

Would it be pertinent to mention that I'm using PipeWire and not normal PulseAudio? Because this is Arch otherwise, and that'd be a pretty glaring incompatibility to have with such a major distro (FWIW, Arch + PW is a combination also found on Steam Deck). I also wouldn't know where to report this to, aha.

@mlauss2
Copy link
Contributor Author

mlauss2 commented Jan 27, 2023

$ ./rtatest
trying 4: Jack
num ports: 9
trying 2: Pulse
[1]    19111 segmentation fault (core dumped)  ./rtatest

Would it be pertinent to mention that I'm using PipeWire and not normal PulseAudio? Because this is Arch otherwise, and that'd be a pretty glaring incompatibility to have with such a major distro (FWIW, Arch + PW is a combination also found on Steam Deck). I also wouldn't know where to report this to, aha.

I too run pipewire + libpulse and don't see your problem (bluetooth headset, displayport audio and analog audio devices). Does Arch not have a bugtracker? Run the test program under gdb, attach it and the backtrace to the bugreport and maybe they can find out what they are doing differently.

in the meantime, edit the TheForceEngine/settings.init file, under the [Sound] section add "audioApiId=1" to force ALSA.

@SeongGino
Copy link

I too run pipewire + libpulse and don't see your problem (bluetooth headset, displayport audio and analog audio devices). Does Arch not have a bugtracker? Run the test program under gdb, attach it and the backtrace to the bugreport and maybe they can find out what they are doing differently.

Unfortunately this is something that is simply beyond my capabilities that I'm unable to do myself for the time being.

FWIW, the workaround of forcing audio backend does work with the audio-next branch (1 was JACK, which didn't actually seem to work; 3 was ALSA. Selecting Pulse and restarting does indeed cause segfaults on next launch).

@mlauss2
Copy link
Contributor Author

mlauss2 commented Jan 28, 2023

I too run pipewire + libpulse and don't see your problem (bluetooth headset, displayport audio and analog audio devices). Does Arch not have a bugtracker? Run the test program under gdb, attach it and the backtrace to the bugreport and maybe they can find out what they are doing differently.

Unfortunately this is something that is simply beyond my capabilities that I'm unable to do myself for the time being.

Oh too bad, though. I'm going to try to install Arch and see if I can reproduce it locally.

FWIW, the workaround of forcing audio backend does work with the audio-next branch (1 was JACK, which didn't actually seem to work; 3 was ALSA. Selecting Pulse and restarting does indeed cause segfaults on next launch).

I'll change the setting from an integer to a string, so that you can write "alsa" as setting which is much more intuitive.
Thanks for testing in any case!

@luciusDXL luciusDXL merged commit 356d433 into luciusDXL:master Jan 28, 2023
@mlauss2 mlauss2 deleted the linux3 branch January 29, 2023 07:04
@mlauss2 mlauss2 restored the linux3 branch January 29, 2023 07:04
@mlauss2 mlauss2 deleted the linux3 branch February 3, 2023 20:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants