Segfault when starting tutorial if resource/tut_list.txt has Unix-like line endings

[akien-mga]

Hi there,

I packaged 7kaa 2.14.5 for my distro locally (I maintain the 7kaa package for Mageia), but I'm getting a segfault when trying to play the tutorial.

Here is the gdb backtrace (I did not install all relevant debug symbols, but the backtrace looks quite good already):

Program received signal SIGSEGV, Segmentation fault.
0x0000000000486cb1 in NationBase::king_name(int) ()
(gdb) bt
#0  0x0000000000486cb1 in NationBase::king_name(int) ()
#1  0x00000000004631b8 in GameFile::write_game_header(File*) ()
#2  0x00000000004632ff in GameFile::save_game(char const*) ()
#3  0x0000000000477eed in GameFileArray::save_new_game(char const*) ()
#4  0x00000000004066a7 in extra_error_handler() ()
#5  0x000000000052f93e in Error::run(char const*, ...) ()
#6  0x000000000053260b in File::file_open(char const*, int, int) ()
#7  0x0000000000421f90 in FileTxt::FileTxt(char*) ()
#8  0x00000000004d66ee in Tutor::get_intro(int) ()
#9  0x00000000004d762d in Tutor::select_tutor(int) ()
#10 0x00000000004d69d9 in Tutor::select_run_tutor(int) ()
#11 0x0000000000457594 in Game::single_player_menu() ()
#12 0x0000000000457f3d in Game::run_main_menu_option(int) ()
#13 0x00000000004583a5 in Game::main_menu() ()
#14 0x0000000000404daf in main ()

I'm using the 2.14.5 source tarball, plus a8eaf0d to fix compile issues with -Werror=format-security.

[akien-mga]

I just tested and a clean build of the master branch does not trigger the issue, so either it's been fixed since, or it's due to some compilation option in my RPM build environment. I'll investigate.

[akien-mga]

After investigating some more and going back to the pristine 2.14.5 tarball, it seems that after installing 7kaa system-wide:

• It segfaults with: SKDATA=/usr/share/games/7kaa /usr/games/7kaa
• It works fine with: SKDATA=data /usr/games/7kaa // data from the source tarball

Looking at a diff between the system-installed and tarball data, there seems to be line ending differences, I'll investigate further.

[akien-mga]

So my issue seems indeed to come from the .sct files in scenario/ and scenari2/, and some .res and *.txt files in resources/. Those files use CRLF line endings in the source tree, while after they have been make installed and packaged, they seem to be using LF line endings which is the norm on Linux systems.

I'll have to investigate why RPM changes the line endings and if there's a way to prevent that. On the other hand 7kaa 2.14.4 was packaged fine, so I'm a bit puzzled at this new issue.

If there's a way on your end to support parsing those files both with DOS-like and Unix-like line endings, it would be great :)

[akien-mga]

It looks like switching only the resource/tut_list.txt file to DOS-like line endings (e.g. with the unix2dos command) fixes the segfault issue for me.

[the3dfxdude]

I cannot reproduce the situation of CRLF transforming to LF on a make install. This seems like an issue with your RPM process.

[akien-mga]

Yeah the issue seems to be triggered only when packaged via RPM. However, my build script is very straight-forward, so it seems that RPM itself is being too clever and force-changing the line endings of .txt files, see: http://svnweb.mageia.org/packages/cauldron/7kaa/current/SPECS/7kaa.spec?view=markup

I'll see if there's a possibility to prevent RPM from being too clever.

In the meantime, I suppose most RPM packagers will be affected. It's a regression in 2.14.5, as the previous versions were using binary .res files, so the line endings were not an issue. Do you think you could modify the new feature that reads data from .txt files to handle both DOS and Unix-like line endings properly?

[ralflang]

On 24.06.2015 19:13, Rémi Verschelde wrote:

Yeah the issue seems to be triggered only when packaged via RPM. However, my build script is very straight-forward, so it seems that RPM itself is being too clever and force-changing the line endings of .txt files, see: http://svnweb.mageia.org/packages/cauldron/7kaa/current/SPECS/7kaa.spec?view=markup

I'll see if there's a possibility to prevent RPM from being too clever.

In the meantime, I suppose most RPM packagers will be affected. It's a regression in 2.14.5, as the previous versions were using binary .res files, so the line endings were not an issue. Do you think you could modify the new feature that reads data from .txt files to handle both DOS and Unix-like line endings properly?

RPM or the packaging environment, like obs?

Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

[akien-mga]

RPM or the packaging environment, like obs?

It would be either upstream RPM or the Mageia buildsystem yes. I'm discussing the issue with fellow Mageia developers to try to see where it comes from. I've tried on both Mageia 4 and Mageia 5, so with:

• Mageia 4: RPM 4.11.1, rpm-mageia-setup [1] 1.197
• Mageia 5: RPM 4.12.0.1, rpm-mageia-setup 2.7

I've tried extracted the resource/tut_list.txt file from the RPM without installing it (using rpm2cpio), and it presents the same issue, so it's not an issue with the installation method (urpmi or rpm -i).

[1] http://gitweb.mageia.org/software/rpm/rpm-setup/

[ralflang]

On 24.06.2015 19:25, Rémi Verschelde wrote:

RPM or the packaging environment, like obs?

It would be either upstream RPM or the Mageia buildsystem yes. I'm discussing the issue with fellow Mageia developers to try to see where it comes from. I've tried on both Mageia 4 and Mageia 5, so with:

• Mageia 4: RPM 4.11.1, rpm-mageia-setup [1] 1.197
• Mageia 5: RPM 4.12.0.1, rpm-mageia-setup 2.7

I've tried extracted the resource/tut_list.txt file from the RPM without installing it (using rpm2cpio), and it presents the same issue, so it's not an issue with the installation method (urpmi or rpm -i).

Strange... I`m using an rpm-based build (openSUSE 13.2) and it just runs...

Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

[akien-mga]

Strange... I`m using an rpm-based build (openSUSE 13.2) and it just runs...

One of the Mageia devs pointed me to the culprit. It looks like this script is run automatically after each build: http://gitweb.mageia.org/software/rpm/spec-helper/tree/fix_eol

I'm not fluent in perl but it looks like there's a way to disable it :) Good to know that it's an issue/feature of Mageia and not of upstream RPM, that makes it simpler to fix.

[akien-mga]

For the reference, I was able to fix my issue with this changeset: http://svnweb.mageia.org/packages/cauldron/7kaa/current/SPECS/7kaa.spec?r1=842416&r2=842436 Thanks for the help :)

As it was a Mageia-specific issue (maybe OpenMandriva might be affected too if they still use those spec-helper scripts, but they'll find the solution here), I guess I can close this issue.

This request is still valid though:

Do you think you could modify the new feature that reads data from .txt files to handle both DOS and Unix-like line endings properly?

[the3dfxdude]

I'll think about the situation some. The files that were introduced here was only really to help generate pot files. It really isn't needed.

I know Perl, and I took a look at that script. That script is ill-advised and should not be modifying files on the fly. I would recommend that script should be pulled out of the build process altogether. If Mageia cares about having pristine packages, they should request upstream either to change the files for them, or request that the upstream make install do it for them for the target (UNIX lf-format) system. This should be done by a case-by-case basis, as you don't otherwise know what you are messing up.