sfdmux segfaults on Linux and infinite loops on Windows

[ShadowOne333]

Trying to compile the latest commits of sfdmux on Linux goes without issues by using this modified build_linux.txt shell script I made for compilation on Linux, based directly from the mingw batch. (Simply rename it to build_linux.sh, the -Wno-* arguments can be removed, I simply added them to avoid getting the warning messages during compilation)

While the compilation goes without issues, trying to create an SFD file with it fails with a segmentation fault message, like this:

[1/4] dm08_01.sfd
	This is an output file.
[2/4] dm08_01.m1v
	This is an M1V file.
	Resolution: 640x480
	Framerate: 29.970
	Length: 00:01:26.000
	Length as double: 86.000000
	Frames: 2586
	Last frame: 0x3103dd5
	Size: 51475718
	Step: 0.003386360056702
	ID: 000001e0
[3/4] dm08_01E.adx
	This is an ADX file.
	Length: 86.287000
	Size: 3106638
	Step: 0.056693166885677
	ID: 000001c0
[4/4] dm08_01J.adx
	This is an ADX file.
	Length: 86.287000
	Size: 3106638
	Step: 0.056693166885677
	ID: 000001c1

Amount of files: 4
File done: 1
85.911955
File done: 2
87.250784
File done: 3
87.250784
Segmentation fault (core dumped)

Thinking the Linux compilation was a fluke, I moved over to 64bit Windows and tried running the same command used on Linux, but the SFD creation gets stuck on an infinite loop with a bunch of Unknown sync commands. It seems like the point of failure is the creation of the SFD header with the .exe from what I could tell.

For reference, here's the base files I am using for the SFD creation:
https://www.dropbox.com/scl/fo/oxq6b12cngcfayoj5ekba/h?dl=0&rlkey=8b3ztl6vjkc2g8iwe9sfws2vr

There's an M1V file (mpeg1video) and two WAV files, the two wav files I convert to ADX by using ffmpeg like listed in the ReadMe. The video file needs to be at a bitrate of 7822 kb/s, and the audio files need to be at 32 kHz with 288 kb/s bitrate in order for the final SFD to work properly in-game (Other M).

If there's anything specific that would be needed from my part, please let me know.

[ThisKwasior]

Current sfdmux isn't working correctly due to these major changes in previous commits.
I'm rewriting this tool (again), that's why i wrote sfdinfo - to test if my findings/research are correct.
Next commit will be the updated tool, sorry for delays on that.

[ShadowOne333]

Oh okay, sorry for the hasty issue report, I thought the recent changes did that.
I'll keep an eye on the other commits, and then I'll report back.

I'll most likely also update the Linux script for compiling, and probably also fix the warnings I'm getting on some of the C files so I can send a PR. Also, I will try to work on a proper Makefile if you want me to. I want to be useful instead of just nagging about stuff :P

[ShadowOne333]

I have this so far for the Makefile:
https://github.com/ShadowOne333/CryTools/blob/master/Makefile
I tested it both in a Linux (Gentoo) machine, and on Windows 7 with MinGW installed with just the base packages.
Let me know if it works on your end to create the .exe.

Is there a problem if all the executables use all the libraries inside /lib/? sfdmux uses them all, but I saw the rest use only some of those, not sure if including all the libraries in each executable would make any difference, but it would certainly help to clean up the Makefile.

I also modified some .c files to address some of the warnings I was getting regarding long long unsigned int. The last couple warnings I'm missing are one inside test_mpeg.c, where I don't know what to do, since it says something a long long unsigned integer with :33 and I'm not sure what this is (it's defined in mpeg.h like uint64_t last_scr : 33;):

   29 |                                 printf("\tSCR: %llu\n", frame.last_scr);
      |                                                ~~~^     ~~~~~~~~~~~~~~
      |                                                   |          |
      |                                                   |          long long unsigned int:33
      |                                                   long long unsigned int

And the last one is inside pathutils.c, which is the use of memccpy while the compiler suggests memcpy instead (the later removes the last argument of size):

  179 |         memccpy(dest->ptr, replace->ptr, 0, dest->size);
      |         ^~~~~~~
      |         memcpy

Once you confirm the new Makefile works on your end, and I know what to do with the two warnings above, I'll wait for the new commit to PR all the new changes for you to review.

[ShadowOne333]

Did the Makefile end up working on Windows through MinGW on your end?
If needed I can make adjustments to it (like having all libs included for all programs instead of just some), as well as fix those two last warning I mentioned to have a proper make that's compatible for Linux and Windows from the get go.

[ThisKwasior]

Sorry, I didn't test it. I've been occupied with other projects and wanna finish these before I can work on crytools again.
Once again - sorry for the wait

[ShadowOne333]

Ah that's fine, don't worry, I simply kept the doubt on whether or not the Makefile worked on your end.
Hope your other projects go smoothly. I'll await in the meantime and I'll be glad to continue helping out once you get back to CryTools, don't worry about the wait :)