Hello,

I am losing my mind! I had a native file dialog working well, then I made some changes and broke it. Now, I cannot get it working again.

I followed the example: ex_native_filechooser.c, and had a pretty good system working before I screwed it up.

I'm not sure if something is wrong with my development environment, because I'm sure the below code should work. The below gives me a segfault, should it?

What error message do you get? If you only changed code, you could try just undoing your changes. Or use a versioning system like Git to keep track of what you have done. Et cetera.

Unfortunately for me, I have not developed good version control habits. I had thought I had made a commit when I had the dialog working, but I went back through commits and I couldn't find a state where it was working. I guess I had got it working, then broke it before making any commits...

When I step through the code, it segfaults at al_show_native_file_dialog()

All I get when I run the above code is the display being created, then crashing with Segmentation fault (core dumped)

I have just figured out how to find the core dump and look at it with gdb and here is the stack frame (I have no idea what to make of this):

I'm starting to think there is something wrong with either my build setup, my OS, or something else because I just tried to build the native file chooser example and it also segfaults.

EDIT: I discovered something! If I run the example with sudo, it works! So I guess this isn't an Allegro5 issue, and more of a Linux problem I'm having.

Anyone able to assist me with figuring out why my applications suddenly need to be run with sudo?

Are you trying to write files in protected locations? They will fail to open.

I don't think I was trying to open something that would need special permissions, just my home dir. The native file dialog example also segfaulted.

Ok, it looks like I don't get a segfault if I run the example from the terminal. Or from the bash terminal in vscode. I only get a segfault when I press the launch button, which I guess launches the app with cmake?

So maybe it's an issue I'm having with vscode.

First thing to do is check return values of functions that can fail.

If a resource like an image fails to load it will be null and access will seg fault that way too.

It probably had an error trying to load an unsupported png file.

A hunch: you're using relative paths to load a file (e.g., PNG as an ALLEGRO_BITMAP) and when running from the terminal, the relative path resolves correctly. But when running from VS Code, your working directory is not the same as the terminal, and so the relative path resolves differently to a file that does not exist, resulting in a crash.

Example:

al_load_bitmap("foo/bar.png")
// If your working directory is ~/project, then this will resolve to ~/project/foo/bar.png
// But if your relative directory is /usr/bin, this will resolve to /usr/bin/foo/bar.png -- which probably isn't correct!

You probably have to configure your run target in VS Code to have the project's base path as your working directory.

(If this isn't the case - apologies! Like I said, it's just a hunch).

I added a line to check for the return values of the display and the filechooser, and both are not null.

I'm not sure about how to go about the libpng error, as I am not loading any images.

This is my current code that I am trying to debug:

Backtrace for this code:

#0  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:240
#1  0x00007ffff60b079d in  () at /lib/x86_64-linux-gnu/libpng16.so.16
#2  0x00007ffff60a0538 in  () at /lib/x86_64-linux-gnu/libpng16.so.16
#3  0x00007ffff60a09d8 in  () at /lib/x86_64-linux-gnu/libpng16.so.16
#4  0x00007ffff60a0cbb in  () at /lib/x86_64-linux-gnu/libpng16.so.16
#5  0x00007ffff60a0eab in png_process_data () at /lib/x86_64-linux-gnu/libpng16.so.16
#6  0x00007fffdc550cd9 in  () at /snap/code/93/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
#7  0x00007ffff6b8e281 in  () at /lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
#8  0x00007ffff6b8eb15 in gdk_pixbuf_loader_close () at /lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
#9  0x00007ffff6b8b233 in  () at /lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
#10 0x00007ffff6b8c2c1 in gdk_pixbuf_new_from_stream () at /lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
#11 0x00007ffff76f257f in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0

Successfully prints the selected file to the terminal when run from terminal, crashes when run from vscode.

Could the native file dialog be using relative paths internally, which would make Erin's suggestion make sense?

EDIT:

I think cmake has something to do with this? If I launch the program using the "Run and Debug" window in vscode, it does not segfault. Just when I do ./test in the CMake/Launch terminal, and when I press the Launch button at the bottom. Hmmmmmmmmmmm.

Try calling al_get_current_directory after al_init, and see what it returns. Does it vary depending on how you run the program?

It does not vary, when it runs properly and when it seg faults it spits out /home/aksel/dev/test/build

I should add that I have reinstalled vscode, and cmake, to no avail.

Ok, so it's different between when it works, and when it doesn't? I think that's the clue here, then

This is a common issue, it's about what the working folder is. If you load files from a relative path, which you probably should do for a game, you have to set what the basis of that path is. Someone else will tell you how, I hope

No it does not vary.

Ok, sorry. Someone that is more familiar with Linux will have to answer, then.

I think the issue is within my configuration of vscode-cmake-tools. It only seg faults when run using cmake run in vscode. I have posted a question of stackexchange, as this appears (at least to me) to not be a programming issue per se.

Cool, maybe you could link to the SE issue? I'm on there, and I'm sure many others here are too.

Here is the SE question: https://stackoverflow.com/questions/71832657/segfault-only-occurs-when-pressing-launch-debug-button-from-vscode

Thanks all for trying to help by the way.

No problem, hope you figure it out.

Oddly this wouldn’t run for me until I set the patterns argument to *.*

But then setting it back to NULL allowed it run again……so now Im confused!!

I'm not sure if this was already addressed: did you check the permissions on your working directory? Who's the owner/group?

If your toolchain is creating/writing to that directory (it looks like it), be sure to check after your build.

I've checked my repo folder and the build folder and both are me/me for group and owner.

I'm still pretty new to Linux there could be something obvious I'm not seeing.

I run into the same problem as you when compiling and running - but I found that you are using auto

- and to my naivety thought that it was a c++ only keyword - so, I renamed the source to .cpp, and compiled it using g++.

This does make it work.

Either that, or if you must use C, make that auto fc instead a ALLEGRO_FILECHOOSER *fc =

(edit) Oh, you had another example - in that second case I guess you are running into problems with permissions like the rest of the people here have said. (/edit)