Arx Libertatis Bug Tracker ~ [CLOSED] #245 - [1CE529DF] __kernel

Arx Libertatis Bug Tracker

CLOSED Crash report #245 - [1CE529DF] __kernel_vsyscall ()

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

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

CrashBot

CrashBot
Offline

This user was last seen online at Mar 25, 2025 - 14:18

Show user details

Close this menu
Owned by

Not owned by anyone
Estimated time

No time Not estimated
Time spent

2 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]
[New Thread 0xa45edb70 (LWP 10865)]
[New Thread 0xa52e5b70 (LWP 10863)]
[New Thread 0xa5ae6b70 (LWP 10862)]
0x0809d5a8 in ?? ()
[Current thread is 1 (Thread 0xa6d926e0 (LWP 10860))]
  Id   Target Id         Frame 
  4    Thread 0xa5ae6b70 (LWP 10862) "arx" 0xa77f8424 in __kernel_vsyscall ()
  3    Thread 0xa52e5b70 (LWP 10863) "Sound Update" 0xa77f8424 in __kernel_vsyscall ()
  2    Thread 0xa45edb70 (LWP 10865) "Pathfinder" 0xa77f8424 in __kernel_vsyscall ()
* 1    Thread 0xa6d926e0 (LWP 10860) "arx" 0x0809d5a8 in ?? ()
 
Thread 4 (Thread 0xa5ae6b70 (LWP 10862)):
#0  0xa77f8424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xa72695e4 in poll () from /lib/libc.so.6
No symbol table info available.
#2  0xa6de6a01 in ?? () from /usr/lib/libasound.so.2
No symbol table info available.
#3  0xa6de6b33 in snd_pcm_wait () from /usr/lib/libasound.so.2
No symbol table info available.
#4  0xa759de49 in ?? () from /usr/lib/libopenal.so.1
No symbol table info available.
#5  0xa75821c2 in ?? () from /usr/lib/libopenal.so.1
No symbol table info available.
#6  0xa7618e12 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#7  0xa7273a5e in clone () from /lib/libc.so.6
No symbol table info available.
 
Thread 3 (Thread 0xa52e5b70 (LWP 10863)):
#0  0xa77f8424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xa7620c06 in nanosleep () from /lib/libpthread.so.0
No symbol table info available.
#2  0x08079087 in ?? ()
No symbol table info available.
#3  0x08266293 in SoundUpdateThread::run() ()
No symbol table info available.
#4  0x08078e3e in ?? ()
No symbol table info available.
#5  0xa7618e12 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#6  0xa7273a5e in clone () from /lib/libc.so.6
No symbol table info available.
 
Thread 2 (Thread 0xa45edb70 (LWP 10865)):
#0  0xa77f8424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xa7620c06 in nanosleep () from /lib/libpthread.so.0
No symbol table info available.
#2  0x08079087 in ?? ()
No symbol table info available.
#3  0x08129f89 in ?? ()
No symbol table info available.
#4  0x08078e3e in ?? ()
No symbol table info available.
#5  0xa7618e12 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#6  0xa7273a5e in clone () from /lib/libc.so.6
No symbol table info available.
 
Thread 1 (Thread 0xa6d926e0 (LWP 10860)):
#0  0x0809d5a8 in ?? ()
No symbol table info available.
#1  <signal handler called>
No symbol table info available.
#2  0xa77f8424 in __kernel_vsyscall ()
No symbol table info available.
#3  0xa71d12a1 in raise () from /lib/libc.so.6
No symbol table info available.
#4  0xa71d2aec in abort () from /lib/libc.so.6
No symbol table info available.
#5  0xaffdc050 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Steps to reproduce this issue

Compile debug version, complete demo and save in the last section, where goblin asks for a license. Compile release version, load save and place cursor on torch item in the inventory.

Show system-generated comments

Comment posted by

CrashBot

Apr 24, 15:29

A file was uploaded. arx.log

This comment was attached:

arxcrash-10860-2816373975

Comment posted by

CrashBot

Apr 24, 15:29

A file was uploaded. cfg.ini

This comment was attached:

arxcrash-10860-2816373975

Comment posted by

CrashBot

Apr 24, 15:29

A file was uploaded. crash.xml

This comment was attached:

arxcrash-10860-2816373975

Comment posted by

Daniel Scharrer

Apr 24, 15:42

If this is reproducible, could you please attach the save that causes this?

Does it still happen if you switch back to the debug version?

Comment posted by

Guest user

Apr 24, 15:53

Output is:

terminate called after throwing an instance of 'std::length_error'
what(): basic_string::_S_create

It crashes the same way if I point cursor on the first bone lying in first stage.

Does it still happen if you switch back to the debug version?

No. Only release version is affected.

Comment posted by

Guest user

Apr 24, 17:22

Works fine when building without unity-build.

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

Comment posted by

Daniel Scharrer

May 24, 23:17

I believe this is now fixed in the latest git version and the unity build should not be a problem anymore. The fix will be part of the next patch release (1.0.2)

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

This issue has been closed
The status has been updated, from New to Fixed.
This issue's progression has been updated to 100 percent completed.
The resolution has been updated, from Not determined to RESOLVED.
Time spent on this issue, from No time spent to 2 hours.

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

#10

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.

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?

Username
Password