If there's a better place to report bugs, let me know.

This bug affects versions 4.0.22 super and 4.0.21 super on Linux.

Do the following to reproduce:
1. Open 4coder in a directory with a project file and a binary file
2. Execute the long-form command "load project"

Expected behavior:
The files with extensions specified in the 'project.4coder' file will be loaded and available to search or switch to.

Actual behavior:
In build 4.0.22 super: 4coder crashes with a segmentation fault
In build 4.0.21 super: 4coder loads the binary file (which does not have an appropriate extension) then crashes if you try to execute the 'list_all_locations' command.

Comment:
I tested it with a binary executable and with a .png file, both cause the crash. It works if I have only text files and directories in the working directory (Edit2: although it does seem to open all files, not just the ones with appropriate extensions). In addition, simply opening the binary file and searching does not produce the crash. It only happens when using "load project"

Edit1: I have only used the customization API to rebind keys.

Thanks for the report, I'll begin taking a look tomorrow. This is a fine place to report bugs, but I will get to it faster if you can send it to the email [email protected]

Hi again cphinton.

I have been able to fix the crash (or at least the crash bug I discovered, I suspect it's the same one you're hitting).

But I can't reproduce your bugs with loading projects and getting the wrong files opened, so I think I will need more info from you. Could you email everything you can about how you launch 4coder and the folder in which the bug occurs? The more similar I can make my setup to yours the more likely I can find the bug.

Thanks for all your hard work! I sent an email with the details. And in case it's relevant, I forgot to mention that my project resides in an ext4 file-system. That's pretty standard, so I doubt it matters.

If that wasn't enough information to replicate it, and no one else seems to have the issue, it seems like it may not be worth pursuing much further. Especially if you fixed the crash, I can deal with a couple of extra loaded files. (Maybe someone can chime in?)

On a somewhat related note, I occasionally have some other crashes that I can't reproduce. Could (or would) you use a core dump if I provided one? I've never used one to debug personally, and maybe you need the same system for it to be useful anyways. Just wondering.

There are a few things you could do to help me debug crashes.

1. When it is crashing attach a debugger, look at where it crashed, get the call stack up, and take a screenshot. Even if it's just disassembly and function addresses they still let me narrow it down a bit. If you're building the custom code yourself you should even have enough debug symbols to get a pretty specific idea where it crashed in a lot of cases.

2. A core dump can also be useful. The only reason I don't default to asking for them is that they are generally large and therefore a pain to move around, but I can definitely learn stuff from that too.

3. If it's a big deal to you so you don't mind spending some time on it, try looking for a small, refined test case that clearly brings on the problem, with that kind of focused testing material, assuming it also causes the bug for me, I can usually solve the problem super rapidly.