Arx Libertatis Bug Tracker ~ [CLOSED] #243

Arx Libertatis Bug Tracker

CLOSED Crash report #243 - [BCBF656C] Unknown

Posted Apr 24, 2012 - updated Jul 05, 2013 Shortlink: http://arx.vg/243

Votes

This issue has been closed with status "Fixed" and resolution "RESOLVED".

Issue details

Type of issue

Crash report Unknown issue type
Status

Fixed

Status not determined
Assigned to

Not assigned to anyone
Progress
Type of bug

Not triaged
Likelihood

Not triaged
Effect

Not triaged
Posted by

donnek

Kevin Donnelly
Offline

This user was last seen online at Apr 26, 2012 - 13:35

Show user details

Close this menu
Owned by

Not owned by anyone
Estimated time

No time Not estimated
Time spent

370918 hours No time spent
Category

Not determined
Resolution

RESOLVED Not determined
Priority

Not determined
Reproducability

Not determined
Severity

Not determined
Targetted for

Not determined
OS

Not determined
Architecture

Not determined
Fixed in

Arx Libertatis 1.0.2Not determined

Issue description

Abnormal termination

GDB stack trace:

[Thread debugging using libthread_db enabled]
0x080a993b in _start ()
[Current thread is 1 (Thread 0xb5c87730 (LWP 5121))]
* 1 Thread 0xb5c87730 (LWP 5121)  0x080a993b in _start ()
 
Thread 1 (Thread 0xb5c87730 (LWP 5121)):
#0  0x080a993b in _start ()
No symbol table info available.

Steps to reproduce this issue

Launched the game from the Kubuntu entry in the Menu arx -u /home/kevin/data/games/ArxLibertatis

Show system-generated comments

Comment posted by

donnek

Apr 24, 08:00

A file was uploaded. crash.xml

This comment was attached:

arxcrash-5121-2646930522

Comment posted by

Daniel Scharrer

Apr 24, 08:21

Hi, could you please run arx from a terminal and attach the output? Or attach arx.log if any was written to the user directory.

"Abnormal termination" (SIGABRT) could mean that an assert was triggered (if arx was build in debug mode), in which case the assert message should have been logged.

It could also be caused by other things, but more information should still be available in console output.

If you installed arx-libertatis from the ppa, could you please also install the arx-libertatis-debug package so there will hopefully be more information in the GDB stack trace.

If you compiled from source yourself you could enable a debug build by passing -DCMAKE_BUILD_TYPE=Debug to cmake and then running make again.

Comment posted by

donnek

Apr 24, 09:46

I've done that, and used the crash reporter, but unfortunately it created a new bug-report (244) - sorry about that. I upgraded to the 1.0.1 package to see if that made any difference, but no. Thanks.

Comment posted by

Daniel Scharrer

Apr 24, 10:42

Thanks for the update.

I've done that, and used the crash reporter, but unfortunately it created a new bug-report (244) - sorry about that.

No problem - the crash reporter is just not smart enough to combine issues from different builds / versions.

Comment posted on behalf of

Daniel Scharrer

Apr 24, 11:28

The issue was updated with the following change(s):

The status has been updated, from New to Confirmed.
This issue's progression has been updated to 10 percent completed.

Comment posted on behalf of

Daniel Scharrer

Apr 24, 11:33

The issue was updated with the following change(s):

The status has been updated, from Confirmed to Being worked on.
The assignee has been changed, from Not assigned to Daniel Scharrer.
Information about the user working on this issue has been changed, from Not being worked on to Daniel Scharrer.

Comment posted on behalf of

Daniel Scharrer

Apr 24, 14:50

This issue has been updated with the latest changes from the code repository.CMakeLists.txt: Don't use -fwhole-program with GCC < 4.5 and Boost < 1.41. (fixes bug #243)

Comment posted on behalf of

Daniel Scharrer

Apr 24, 16:07

The issue was updated with the following change(s):

The status has been updated, from Being worked on to Ready for testing / QA.
Information about the user working on this issue has been changed, from Daniel Scharrer to Not being worked on.
Time spent on this issue, from No time spent to 5 hours.
The assignee has been changed, from Daniel Scharrer to Not assigned.

Comment posted by

Daniel Scharrer

Apr 24, 16:12

I've pushed a fix for this to the git repository and it will be part of the next release.

As this only affects a few users (you need GCC < 4.5 *and* Boost < 1.41 to trigger the bug, which is pretty much just Ubuntu Lucid users), this won't be getting it's own patch release.

I have however updated the lucid package in the ppa with the fix (version 1.0.1-0ppa2~lucid). Could you test it and post here if it fixes the crash for you so I can close this bug?

#10

Comment posted by

donnek

Apr 26, 13:35

Cool - thanks for that, Daniel. The game seems to launch fine now, so you can close the bug.

#11

Comment posted on behalf of

Daniel Scharrer

Apr 26, 14:42

The issue was updated with the following change(s):

This issue has been closed
The status has been updated, from Ready for testing / QA to Fixed.
This issue's progression has been updated to 100 percent completed.
The resolution has been updated, from Not determined to RESOLVED.

#12

Comment posted on behalf of

Daniel Scharrer

May 19, 02:22

This issue has been updated with the latest changes from the code repository.CMakeLists.txt: Don't use -fwhole-program with GCC < 4.5 and Boost < 1.41. (fixes bug #243)

#13

Comment posted on behalf of

Daniel Scharrer

May 24, 23:15

This issue has been updated with the latest changes from the code repository.

Don&#039;t use the -fwhole-program compiler flag
 
-fwhole-program can be used to tell the gcc that everything that
makes up the final program is included in the current command, which
allows it to use more aggressive optimizations. This can result in
smaller and faster code.
 
However, cmake always uses at least two commands to compile each
executable, even with the unity build: one for building the user code
and one for linking all libraries.
 
Using the -fwhole-program option here can cause the compiler to not
properly internalize some C++ objects (such as typeids) that are used
in both the user code and external libraries, resulting in unexpected
behavior.
 
From my tests, there is no measurable performance gain and the file size
reduction for the arx executable is &#039;only&#039; around 18%. I think the
potential problems outweigh those benefits, so -fwhole-program must go.
 
This only affects unity builds as -fwhole-program was only used for
those. Unity builds are still possible and recommended.
 
In the future we can look into using link-time optimizations, but those
are not stable enough in current gcc versions to be enabled by default.
Also, quick tests show no real benefits.
 
See crash report #245
See also commit 58aa3 and crash report #243

Comment visibility (whether to hide this comment for "regular users")

Comment

'''Daniel Scharrer wrote:'''
>This issue has been updated with the latest changes from the code
>repository.Don&#039;t use the -fwhole-program compiler
>flag -fwhole-program can be used to tell the gcc that everything thatmakes
>up the final program is included in the current command, whichallows it to
>use more aggressive optimizations. This can result insmaller and faster
>code. However, cmake always uses at least two commands to compile
>eachexecutable, even with the unity build: one for building the user
>codeand one for linking all libraries. Using the -fwhole-program option
>here can cause the compiler to notproperly internalize some C++ objects
>(such as typeids) that are usedin both the user code and external
>libraries, resulting in unexpectedbehavior. From my tests, there is no
>measurable performance gain and the file sizereduction for the arx
>executable is &#039;only&#039; around 18%. I think thepotential problems
>outweigh those benefits, so -fwhole-program must go. This only affects
>unity builds as -fwhole-program was only used forthose. Unity builds are
>still possible and recommended. In the future we can look into using
>link-time optimizations, but thoseare not stable enough in current gcc
>versions to be enabled by default.Also, quick tests show no real
>benefits. See crash report #245See also commit 58aa3 and crash report #243
>
>

To auto-link to an existing issue, write "issue", "bug", "ticket" or the issue type (like "bug report" or "enhancement") followed by the issue number (ex: "ticket #3" or "bug report MYPROJ-1"). Enclose sourcecode samples in <source></source> tags.
See more formatting tips in WikiFormatting.

Complete the name to prove that you are human: Arx (the original game by Arkane, not Arx Libertatis)
or cancel

#14

Comment posted on behalf of

Daniel Scharrer

Jun 30, 05:17

This issue has been updated with the latest changes from the code repository.

Don&#039;t use the -fwhole-program compiler flag
 
-fwhole-program can be used to tell the gcc that everything that
makes up the final program is included in the current command, which
allows it to use more aggressive optimizations. This can result in
smaller and faster code.
 
However, cmake always uses at least two commands to compile each
executable, even with the unity build: one for building the user code
and one for linking all libraries.
 
Using the -fwhole-program option here can cause the compiler to not
properly internalize some C++ objects (such as typeids) that are used
in both the user code and external libraries, resulting in unexpected
behavior.
 
From my tests, there is no measurable performance gain and the file size
reduction for the arx executable is &#039;only&#039; around 18%. I think the
potential problems outweigh those benefits, so -fwhole-program must go.
 
This only affects unity builds as -fwhole-program was only used for
those. Unity builds are still possible and recommended.
 
In the future we can look into using link-time optimizations, but those
are not stable enough in current gcc versions to be enabled by default.
Also, quick tests show no real benefits.
 
See crash report #245
See also commit 58aa3 and crash report #243

Comment visibility (whether to hide this comment for "regular users")

Comment

Complete the name to prove that you are human: Arx (the original game by Arkane, not Arx Libertatis)
or cancel

#15

Comment posted on behalf of

Daniel Scharrer

Jul 05, 19:44

The issue was updated with the following change(s):

The custom field Fixed in has been updated, from Unknown to Arx Libertatis 1.0.2.

58aa36d

Revision 58aa36db2aff24df3a300ccba2a27ab8168275d8 by

Daniel Scharrer

Apr 24, 14:44 - Preceeded by b4a3ae2a9a46cda1675893180b8f96c7e3a50505

Show more details

Log entry

CMakeLists.txt: Don't use -fwhole-program with GCC < 4.5 and Boost < 1.41. (fixes bug #243)

58aa36d

renderer_props_stack Revision 58aa36db2aff24df3a300ccba2a27ab8168275d8 by

Daniel Scharrer

Apr 24, 14:44 - Preceeded by b4a3ae2a9a46cda1675893180b8f96c7e3a50505

Show more details

Log entry

CMakeLists.txt: Don't use -fwhole-program with GCC < 4.5 and Boost < 1.41. (fixes bug #243)

64c2352

master Revision 64c2352cda48e90934aad41c5de74624ef0b5177 by

Daniel Scharrer

May 24, 22:01 - Preceeded by c979ef0861ba07c598f9946c1e90488c2ad5fc7a

Show more details

Log entry

Don't use the -fwhole-program compiler flag

-fwhole-program can be used to tell the gcc that everything that
makes up the final program is included in the current command, which
allows it to use more aggressive optimizations. This can result in
smaller and faster code.

However, cmake always uses at least two commands to compile each
executable, even with the unity build: one for building the user code
and one for linking all libraries.

Using the -fwhole-program option here can cause the compiler to not
properly internalize some C++ objects (such as typeids) that are used
in both the user code and external libraries, resulting in unexpected
behavior.

From my tests, there is no measurable performance gain and the file size
reduction for the arx executable is 'only' around 18%. I think the
potential problems outweigh those benefits, so -fwhole-program must go.

This only affects unity builds as -fwhole-program was only used for
those. Unity builds are still possible and recommended.

In the future we can look into using link-time optimizations, but those
are not stable enough in current gcc versions to be enabled by default.
Also, quick tests show no real benefits.

See crash report #245
See also commit 58aa3 and crash report #243

64c2352

renderer_stack Revision 64c2352cda48e90934aad41c5de74624ef0b5177 by

Daniel Scharrer

May 24, 22:01 - Preceeded by c979ef0861ba07c598f9946c1e90488c2ad5fc7a

Show more details

Log entry

Don't use the -fwhole-program compiler flag

-fwhole-program can be used to tell the gcc that everything that
makes up the final program is included in the current command, which
allows it to use more aggressive optimizations. This can result in
smaller and faster code.

However, cmake always uses at least two commands to compile each
executable, even with the unity build: one for building the user code
and one for linking all libraries.

Using the -fwhole-program option here can cause the compiler to not
properly internalize some C++ objects (such as typeids) that are used
in both the user code and external libraries, resulting in unexpected
behavior.

From my tests, there is no measurable performance gain and the file size
reduction for the arx executable is 'only' around 18%. I think the
potential problems outweigh those benefits, so -fwhole-program must go.

This only affects unity builds as -fwhole-program was only used for
those. Unity builds are still possible and recommended.

In the future we can look into using link-time optimizations, but those
are not stable enough in current gcc versions to be enabled by default.
Also, quick tests show no real benefits.

See crash report #245
See also commit 58aa3 and crash report #243

* Username
* Display name
The "display name" is the name shown to others
Real name
* E-mail address
* Confirm e-mail

Welcome to The Bug Genie

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Username
Password