Created attachment 1144758 [details]
File: backtrace

Created attachment 1144759 [details]
File: cgroup

Created attachment 1144760 [details]
File: core_backtrace

Created attachment 1144761 [details]
File: dso_list

Created attachment 1144762 [details]
File: environ

Created attachment 1144763 [details]
File: exploitable

Created attachment 1144764 [details]
File: limits

Created attachment 1144765 [details]
File: maps

Created attachment 1144766 [details]
File: mountinfo

Created attachment 1144767 [details]
File: namespaces

Created attachment 1144768 [details]
File: open_fds

Created attachment 1144769 [details]
File: proc_pid_status

Created attachment 1144770 [details]
File: var_log_messages

Similar problem has been detected:

Start story mode, get SIGSEGV.

reporter:       libreport-2.6.4
backtrace_rating: 4
cmdline:        supertux2
crash_function: lisp::Lisp::get_lisp
executable:     /usr/bin/supertux2
global_pid:     18570
kernel:         4.5.0-302.fc24.x86_64
package:        supertux-0.4.0-4.fc24
reason:         supertux2 killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            1000

confirmed on my machine as well.
When I start from the commandline, and choose story mode I get a segmentation fault:

>supertux2
[SQUIRREL] [DEBUG] Underground state initialized
Segmentation fault (core dumped)
>

on the other hand when I choose "contrib levels" the game seems to work fine, but still suffers from the other unsolved bug #1295185 and will not save its progress.

Affected software version: supertux-0.4.0-4.fc24.x86_64

The problem appears to be triggered by level files like /usr/share/supertux2/levels/bonus3/hanging\ roof.stl, which contains this:

    (particles-clouds
    )
    (particles-clouds
    )

The empty body of the particles-clouds forms triggers the bug.  Probably the easiest fix is to patch Sector::parse() in src/supertux/sector.cpp.  The line that reads:

  GameObjectPtr object = parse_object(token, *(iter.lisp()));

should instead do something like this:

  Reader *reader = iter.lisp();
  if (reader) {
    GameObjectPtr object = parse_object(token, *reader);
    if (object) {
      ...
    }
  }

Warning: I have not actually tried this.  This approach may well cause some other bug to be triggered.

Created attachment 1185351 [details]
Patch to fix crash with empty Lisp expressions

That approach seems to work.  I went through a couple of the formerly problematic levels with no trouble using the attached patch.  I will attach the spec file I used, too, for reference.

Created attachment 1185352 [details]
Modified spec file for previous patch and bundling squirrel

(In reply to Jerry James from comment #17)
> Created attachment 1185351 [details]
> Patch to fix crash with empty Lisp expressions

This does not seem to be the correct patch.

Created attachment 1185575 [details]
Patch to fix crash with empty Lisp expressions

Oops, no that's the patch just above the correct one in the file chooser.  I must have clicked a little bit too high.  Try this one instead.

Similar problem has been detected:

run supertux2
setup joystick
run history game mode
then I got these strange crash, have no crashes with these game long play on ubuntu.

reporter:       libreport-2.7.2
backtrace_rating: 4
cmdline:        supertux2
crash_function: lisp::Lisp::get_lisp
executable:     /usr/bin/supertux2
global_pid:     1714
kernel:         4.6.4-301.fc24.x86_64
package:        supertux-0.4.0-4.fc24
pkg_fingerprint: 73BD E983 81B4 6521
pkg_vendor:     Fedora Project
reason:         supertux2 killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            1000

(In reply to Jerry James from comment #20)
> Created attachment 1185575 [details]
> Patch to fix crash with empty Lisp expressions
> 
> Oops, no that's the patch just above the correct one in the file chooser.  I
> must have clicked a little bit too high.  Try this one instead.

Thanks! Looking at the upstream git repository, the code in question has changed a bit, so I have no idea if the patch is still relevant to upstream. Are the levels with the empty Lisp expressions definitely wrong, or is it the parsing that is broken (or both)? It would be good to have a plan on fixing the upstream levels and/or code if it is still broken in git.

(In reply to David King from comment #22)
> Thanks! Looking at the upstream git repository, the code in question has
> changed a bit, so I have no idea if the patch is still relevant to upstream.
> Are the levels with the empty Lisp expressions definitely wrong, or is it
> the parsing that is broken (or both)? It would be good to have a plan on
> fixing the upstream levels and/or code if it is still broken in git.

My feeling is that even if the level files are bad, the code still shouldn't crash, so I'm going to go with the parsing being broken.  As for how relevant this patch is to upstream, I'm afraid that I simply don't know.  I just ran supertux under a debugger to see what the problem was, and this seemed to me to be the simplest fix for the current code base.  Upstream may have different views on the matter, or may have already addressed the issue in some other way.

*** Bug 1366823 has been marked as a duplicate of this bug. ***

*** Bug 1325398 has been marked as a duplicate of this bug. ***

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.