Author Topic: GOG/Linux version of Quest for Infamy crashes on Debian testing  (Read 6725 times)

0 Members and 1 Guest are viewing this topic.

shmerl

  • Lackey
  • **
  • Posts: 57
  • Liked: 13
    • View Profile
GOG/Linux version of Quest for Infamy crashes on Debian testing
« on: October 13, 2014, 12:47:34 AM »
Hi.

I recently bought Quest for Infamy from GOG, and trying to run the Linux version on current Debian testing (x86_64). The game keeps crashing with segfault after choosing "Prelude" or "Start" in the first menu.

Here is the tail of the AGS output:

Code: [Select]
AGS: Room change requested to room 315
AGS: Unloading room 309
AGS: Loading room 315
AGS: Room change requested to room 302
AGS: Unloading room 315
AGS: Loading room 302
AGS: Room change requested to room 340
AGS: Unloading room 302
AGS: Loading room 340

Shutting down Allegro due to signal #11
Segmentation fault

And here is the game run with gdb:

Code: [Select]
Program received signal SIGSEGV, Segmentation fault.
 __lll_unlock_elision (lock=0x1f1e910, private=0) at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
 29 ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c: No such file or directory.
 (gdb) bt
 #0 __lll_unlock_elision (lock=0x1f1e910, private=0) at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
 #1 0x0000000000531acc in SOUNDCLIP::~SOUNDCLIP() ()
 #2 0x000000000052d4e1 in stop_and_destroy_channel_ex(int, bool) ()

What can be the problem and how can I help debugging it?

My configuration:
OS: Debian testing Linux (x86_64)
Kernel: 3.16.3-2
Video driver: Nvidia closed driver 343.22.
DE: KDE 4.14
Audio: PulseAudio.

Corresponding thread on GOG forum: https://www.gog.com/forum/quest_for_infamy/problems_with_the_linux_version_of_quest_for_infamy

Kaldire

  • Testers
  • Mastermind
  • *****
  • Posts: 1572
  • Liked: 357
  • Gender: Male
  • Learn to live,Learn to love,Learn to love to live!
    • https://www.facebook.com/NewFunFansKaldire
    • View Profile
Re: GOG/Linux version of Quest for Infamy crashes on Debian testing
« Reply #1 on: October 13, 2014, 05:13:55 AM »
sounds like a memory stepping issue which happens in linux
have you tried to debug it or check it out

try valgrind, or gdb to find out where the problem is. Remember to compile and link with the -g switch

"It really helps to use a windowed mode in your game so you can switch focus back to the terminal with the debugger. If the game runs after 'r', and it doesn't crash, it's probably because the debugger zeros out uninitialized variables, etc. It's fairly difficult to find out then. If it does crash, you can use 'b' to find out whodunnit. If it runs normally without crashing, try to quit the game (while the game window has focus)"

 :)

pm me if ya need any further assistance  im not up to par on my newest or every ver of linux but i do know thats a memory issue usually

oh and try this

use bitmaps instead of video bitmaps, using buffering.
"Larger than life and twice as natural!"

s_d

  • Most Excellent KS Backer
  • Senior Villain
  • ****
  • Posts: 297
  • Liked: 58
    • View Profile
Re: GOG/Linux version of Quest for Infamy crashes on Debian testing
« Reply #2 on: October 13, 2014, 09:34:03 AM »
I recently bought Quest for Infamy from GOG, and trying to run the Linux version of current Debian testing (x86_64). The game keeps crashing with segfault after choosing "Prelude" or "Start" in the first menu.

Thanks for the detailed report! I'm sorry about the crash... it was tested on Testing, but of course things change, and more work needs to be done.  I'll take a look and try to get a test build out to you.
"Any statements made by this fan of Infamous Quests is his own personal opinion and in no way reflects the opinions of Infamous Quests. Any official statements made about Infamous Quests by this fan will be clearly identified as bullshit."

shmerl

  • Lackey
  • **
  • Posts: 57
  • Liked: 13
    • View Profile
Re: GOG/Linux version of Quest for Infamy crashes on Debian testing
« Reply #3 on: October 13, 2014, 10:56:48 AM »
Thanks for the detailed report! I'm sorry about the crash... it was tested on Testing, but of course things change, and more work needs to be done.  I'll take a look and try to get a test build out to you.

Thanks. As some recommended, I built ags from the current source, but how can I run the game with it?

:)

pm me if ya need any further assistance  im not up to par on my newest or every ver of linux but i do know thats a memory issue usually

oh and try this

use bitmaps instead of video bitmaps, using buffering.

I'm completely new to the game and AGS, and didn't know about the later until today :) So most of what you said just went over my head. I guess you meant AGS itself? Or the game itself is open source and one can compile it?

shmerl

  • Lackey
  • **
  • Posts: 57
  • Liked: 13
    • View Profile
Re: GOG/Linux version of Quest for Infamy crashes on Debian testing
« Reply #4 on: October 13, 2014, 11:26:01 PM »
I built AGS with -O0 and run the game with it from gdb. Here is a more detailed backtrace:

Code: [Select]
Program received signal SIGSEGV, Segmentation fault.
__lll_unlock_elision (lock=0x979970, private=0) at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
29      ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c: No such file or directory.
(gdb) bt
#0  __lll_unlock_elision (lock=0x979970, private=0) at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
#1  0x0000000000562968 in AGS::Engine::PThreadMutex::Unlock (this=0x979968) at ../Engine/util/mutex_pthread.h:47
#2  0x00000000005628d5 in AGS::Engine::PThreadMutex::~PThreadMutex (this=0x979968, __in_chrg=<optimized out>) at ../Engine/util/mutex_pthread.h:36
#3  0x00000000005675b3 in SOUNDCLIP::~SOUNDCLIP (this=0x979910, __in_chrg=<optimized out>) at media/audio/soundclip.cpp:73
#4  0x000000000056495e in stop_and_destroy_channel_ex (chid=3, resetLegacyMusicSettings=true) at media/audio/audio.cpp:499
#5  0x0000000000564a22 in stop_and_destroy_channel (chid=3) at media/audio/audio.cpp:521
#6  0x0000000000563e01 in find_free_audio_channel (clip=0x153c070, priority=50, interruptEqualPriority=true) at media/audio/audio.cpp:202
#7  0x00000000005646de in play_audio_clip (clip=0x153c070, priority=50, repeat=0, fromOffset=0, queueIfNoChannel=false) at media/audio/audio.cpp:435
#8  0x0000000000521d25 in AudioClip_Play (clip=0x153c070, priority=31998, repeat=31998) at ac/audioclip.cpp:57
#9  0x0000000000564797 in play_audio_clip_by_index (audioClipIndex=321) at media/audio/audio.cpp:452
#10 0x00000000005366b5 in CheckViewFrame (view=646, loop=0, frame=10) at ac/viewframe.cpp:154
#11 0x00000000004cf8ff in RoomObject::UpdateCyclingView (this=0x8e3048 <troom+8>) at ac/roomobject.cpp:76
#12 0x000000000055a56c in update_cycling_views () at main/udpate.cpp:199
#13 0x000000000055b301 in update_stuff () at main/udpate.cpp:463
#14 0x000000000055dd0b in game_loop_do_update () at main/game_run.cpp:543
#15 0x000000000055e13f in mainloop (checkControls=true, extraBitmap=0x0, extraX=0, extraY=0) at main/game_run.cpp:711
#16 0x000000000055e4ac in main_game_loop () at main/game_run.cpp:840
#17 0x000000000055e5a4 in do_main_cycle (untilwhat=2, daaa=9077320) at main/game_run.cpp:885
#18 0x00000000004f793e in scrWait (nloops=120) at ac/global_game.cpp:924
#19 0x000000000050ce02 in Sc_scrWait (params=0x7fffffffd2d0, param_count=1) at ac/global_api.cpp:2175
#20 0x000000000057425e in ccInstance::Run (this=0x1ef4b10, curpc=31) at script/cc_instance.cpp:1174
#21 0x0000000000571c68 in ccInstance::CallScriptFunction (this=0x1ef4b10, funcname=0x968500 <scfunctionname> "room_AfterFadeIn", numargs=0, params=0x0) at script/cc_instance.cpp:368
#22 0x0000000000574cc4 in ccInstance::RunScriptFunctionIfExists (this=0x1ef4b10, tsname=0x968500 <scfunctionname> "room_AfterFadeIn", numParam=0, params=0x0) at script/cc_instance.cpp:1390
#23 0x0000000000574e2f in ccInstance::RunTextScript (this=0x1ef4b10, tsname=0x1fd4db0 "room_AfterFadeIn") at script/cc_instance.cpp:1435
#24 0x000000000056da43 in run_interaction_script (nint=0x1f1d900, evnt=7, chkAny=-1, isInv=0) at script/script.cpp:227
#25 0x00000000004d4860 in process_event (evp=0x7fffffffdd84) at ac/event.cpp:208
#26 0x00000000004d523c in processallevents (numev=6, evlist=0x8a7940 <event>) at ac/event.cpp:404
#27 0x00000000004d527f in update_events () at ac/event.cpp:414
#28 0x000000000055de8e in game_loop_update_events () at main/game_run.cpp:600
#29 0x000000000055e16c in mainloop (checkControls=true, extraBitmap=0x0, extraX=0, extraY=0) at main/game_run.cpp:721
#30 0x000000000055e4ac in main_game_loop () at main/game_run.cpp:840
#31 0x000000000055b5e2 in do_play_game () at main/game_start.cpp:141
#32 0x000000000055b6c0 in initialize_start_and_play_game (override_start_room=0, loadSaveGameOnStartup=0x0) at main/game_start.cpp:182
#33 0x0000000000554cd2 in initialize_engine (argc=2, argv=0x7fffffffe0d8) at main/engine.cpp:1463
#34 0x0000000000560384 in main (argc=2, argv=0x7fffffffe0d8) at main/main.cpp:492

shmerl

  • Lackey
  • **
  • Posts: 57
  • Liked: 13
    • View Profile
Re: GOG/Linux version of Quest for Infamy crashes on Debian testing
« Reply #5 on: October 13, 2014, 11:34:57 PM »
Similar issues reported:

https://bugzilla.novell.com/show_bug.cgi?id=853311
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750792
https://bugzilla.redhat.com/show_bug.cgi?id=1059418

The problem is exposed with new glibc and it's processor specific (happens on Haswell CPUs or later I guess, i.e. those which have TSX instructions: https://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions).

My processor is Haswell, so it makes sense that it's affected.

shmerl

  • Lackey
  • **
  • Posts: 57
  • Liked: 13
    • View Profile
Re: GOG/Linux version of Quest for Infamy crashes on Debian testing
« Reply #6 on: October 14, 2014, 12:11:28 AM »
I made a rough workaround. The problem is in AGS when it unlocks a mutex which wasn't locked (that's invalid behavior really that crashes with new glibc on CPUs with TSX).

Here is a patch:

Code: [Select]
diff --git a/Engine/util/mutex_pthread.h b/Engine/util/mutex_pthread.h
index c211dc4..ef04ace 100644
--- a/Engine/util/mutex_pthread.h
+++ b/Engine/util/mutex_pthread.h
@@ -27,28 +27,36 @@ class PThreadMutex : public BaseMutex
 {
 public:
   inline PThreadMutex()
+  :
+   lock_last(false)
   {
     pthread_mutex_init(&_mutex, NULL);
   }
 
   inline ~PThreadMutex()
   {
-    Unlock();
+    // Shmerl: to prevent invalid unlocking (which segfaults on CPUs with TSX, like Haswell).
+    if (lock_last) Unlock();
     pthread_mutex_destroy(&_mutex);
   }
 
   inline void Lock()
   {
     pthread_mutex_lock(&_mutex);
+    lock_last = true;
   }
 
   inline void Unlock()
   {
     pthread_mutex_unlock(&_mutex);
+    lock_last = false;
   }
 
 private:
   pthread_mutex_t _mutex;
+  // Shmerl: Rough workaround - indicates what method was called last for the destructor
+  // Not strictly thread consistent, but should be enough for the destructor case
+  bool lock_last;
 };
 
 typedef PThreadMutex Mutex;

The fix isn't really good for the engine itself, since it uses a variable which isn't bound to the mutex. So if some other thread messes it up, it can theoretically become inconsistent. But it's enough for the Quest for Infamy case. More properly it should probably check if mutex is not in the unlocked state before unlocking it. I'm not an expert on pthreads really, but there might be a way to do it.

I'll file a bug to the AGS bugtracker about this.

UPDATE: Bug report: https://github.com/adventuregamestudio/ags/issues/195

shmerl

  • Lackey
  • **
  • Posts: 57
  • Liked: 13
    • View Profile
Re: GOG/Linux version of Quest for Infamy crashes on Debian testing
« Reply #7 on: October 15, 2014, 03:03:30 PM »