Recettear Forum

My first several attemts to enter the Guild Hall's third floor resulted in the game crashing. There are a few error messages when you first enter the dungeon (More after applying the sound fix from the other thread), but the game can get past that. It was consistantly the third floor that caused the crash.

So, before posting, I decided to generate a debug log to see if I could find something obvious launching the game (not steam) through cxrun. Well...the game didn't crash, I got through the dungeon, and saved the game.

Afterwards I went back in with an old save launching from steam. Crashed on floor three.
Tried cxrun again, without creating a debug log. Success getting through the dungeon again.

Suffice to say...this is weird :)

Additionally - The treasure chest and dungeon exit on the top floor were not visible. After seeing that, if there are chests on previous floors, they are similarly invisible (although marked with an X on the map).

Hi again,

Ummm....bit strange.....probably reminds me a bit of the commandline option --workdir [$path]...

This would be the difference between;

~/cxgames/bin/wine --bottle some-bottle-name --cx-app somegame.exe

...and...

~/cxgames/bin/wine --bottle some-bottle-name --workdir "/path/to/game/exe/dir" --cx-app some-game.exe

There was an issue in CXx-9.0 where --workdir was being inadvertently dropped ; some win32
apps really need that specification to launch and work correctly...this would be the first
aspect I'd check here...

Cheers!

This bug seems fairly random...The next dungeon froze (as opposed to outright crashing) on the loading screen to the third floor twice. Then it worked without a problem. On the next dungeon run, it crashed again going to the third floor. The first of these three runs was launched through cxrun, the rest through the Steam interface (killing the last theory I guess)

Of note here (and the reason for posting again) might be that the second freeze created this lovely mess of text of my terminal that featured a backtrace and memory map, starting with this:

*** glibc detected *** d:\steam\steamapps\common\recettear\recettear.exe: double free or corruption (fasttop): 0x7a0c48c0 ***
======= Backtrace: =========
/lib32/libc.so.6(+0x6c711)[0xf74c2711]
/lib32/libc.so.6(+0x6dfb0)[0xf74c3fb0]
/lib32/libc.so.6(cfree+0x6d)[0xf74c709d]
/usr/lib32/libX11.so.6(+0x41baf)[0x7e3c6baf]
/usr/lib32/libX11.so.6(_XReply+0x106)[0x7e3c71e6]
/usr/lib32/libGL.so.1(+0x87c4f)[0x7e0f8c4f]
[0x80405004]
======= Memory map: ========

I have the whole thing saved if anyone actually wants it. If it matters for the libraries, this is a Gentoo system, with glibc-2.12.1-r1.

Hi,

Probably not glibc itself, snippets like the above never show anything of
worth, as the process context cannot be seen...perhaps X threw a rod or GLlib
became deranged. If you've got the whole log (just +seh,+trace,+ntdll ) gzip
it and upload it to the same place as before (same login). Make sure you have
the Steam community overlay stuff turned off in the Steam GUI as this might
still be causing issues.

What linux kernel version are you running?

Cheers!

I can get a full log up later today. I'm using Linux kernel 2.6.36-rc3. The bug was originally happening with Xorg Server 1.8 and NVidia driver 256.53; last night after upgrading to XOrg 1.9 and NVidia 260.19 the freeze was still happening.

(for what it's worth - now on 2.6.26-rc4)

notepad-recettear-crash.txt.gz and notepad-recettear-crash2.txt.gz are up. They look fairly similar to me, and from tailing the log as it was being generated, there was no new text added to the file after the error (in fact, there was no new text in teh log after launching the game)

• Trying again with Steam Overlay enabled made it so the error message didn't trigger, however the game still hanged at the loading screen. Hitting Shift-Tab to bring up teh Steam Community worked, but it couldn't be closed.

I've created a new bottle and I've been installing random junk into the bottle to try and make it work.

• I Ran the Steam C4P up until it actually installs Steam, jsut to get some baseline stuff installed
• This time the game crashed quickly until the sound fix was applied. Go figure.
• The game actually froze faster for a long time, after the first or second floors instead of the 4th (technically the 6th 7th and 9th, but the 1st 2nd and 4th that I visitted)
• .Net 2.0 and 3.0 didn't do anything
• The MS XML packages didn't do anything
• Installing C++ 2005 and 2008 got me back up to the point I'm at in the other bottle - the game freeze after somethign causes an error going from the 9th floor to the 10th.

Hi,

If you do any more debugging trying to catch the actual ingame
crash/lockup, you're going to need attach the debug to Steam.exe
and do it that way -- seems like the binary recettear.exe is some
kind of launcher stub or such, and so no useful chatter is being
returned from it. Seeing you report that this time it was quicker
to crash until the sound fix was used sort of raises suspicion
that the sound issue may be more troublesome/involved than first
thought -- perhaps that issue is ongoing in game.

Another thing we're battling here, is the rollout of Steam updates ;
there was one on each of the last couple of days, and when this sort
of thing happens...the games delivery platform itself is 'moving'...
it becomes increasingly difficult to eliminate those updates themselves
as being somehow at cause, or causing different behavior. If Steam
updates are rolling in, and you notice a marked change in the app's
behavior at the same time, you are faced with having to explain the
observation of that coincidence...welcome to the horrorshow that is
the steamapps debugging sandpit... 8)

There is a strategy to 'fix' (as in, snapshot) a Steam release at one
specific version release - a separate user account with Steam + the app
in question installed....and then put that Steam client into 'Offline'
mode. It changes your debugging runtime environment to a degree, in as
much any online Steam negotiations are out of the picture, but it can
be worth knowing whether that changes anything or not too. In any event,
this stops that Steam client from updating itself, and having it in
another user login (on your system) keeps it out of the way of normal
operations of the day to day kind.

Also note...wrt sound...that I -think- the next CXG release will incorporate
more sound related improvements, and so that's going to change this playing
field as well quite possibly when it comes to beta testing time...the crashing
or locking up might be something else though, but you'll have to try to catch
that in a log before we'll know either way.

Cheers!

Hurray for black box debugging :)

Well, going at this with +seh +tid +thread +x11drv +dsound +ntdll running Steam.exe, I "tail -f"ed the log into a different file around the crash (with probably an axtra 5 seconds worth of run time on either side) and found this neat looking section.

wine: Unhandled page fault on read access to 0x8872a33c at address 0x4a6591 (thread 0043), starting debugger...
0043:trace:seh:start_debugger Starting debugger "winedbg --auto 61 744"
0017:trace:seh:raise_exception code=c0000005 flags=0 addr=0x3f234763 ip=3f234763 tid=0017
0017:trace:seh:raise_exception  info[0]=00000000
0017:trace:seh:raise_exception  info[1]=01a30000
0017:trace:seh:raise_exception  eax=00000000 ebx=0000008c ecx=00000000 edx=00000000 esi=00000000 edi=01a30000
0017:trace:seh:raise_exception  ebp=00000000 esp=0033cb78 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010297
0017:trace:seh:call_vectored_handlers calling handler at 0x7e660f80 code=c0000005 flags=0
0017:trace:seh:call_vectored_handlers handler at 0x7e660f80 returned ffffffff
0017:trace:seh:raise_exception code=c0000005 flags=0 addr=0x3f234763 ip=3f234763 tid=0017
0017:trace:seh:raise_exception  info[0]=00000000
0017:trace:seh:raise_exception  info[1]=01a30000
0017:trace:seh:raise_exception  eax=00000000 ebx=00000054 ecx=00000000 edx=00000000 esi=00000000 edi=01a30000
0017:trace:seh:raise_exception  ebp=00000000 esp=0033cb78 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010297
0017:trace:seh:call_vectored_handlers calling handler at 0x7e660f80 code=c0000005 flags=0
0017:trace:seh:call_vectored_handlers handler at 0x7e660f80 returned ffffffff
0047:err:alsa:wine_snd_pcm_recover underrun occurred
0043:trace:seh:call_stack_handlers handler at 0x7bc86cc0 returned 1
Unhandled exception: page fault on read access to 0x8872a33c in 32-bit code (0x004a6591).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:004a6591 ESP:0e44e3f8 EBP:0e44e428 EFLAGS:00210292(  R- --  I S -A- - )
 EAX:7de306e0 EBX:0e44e503 ECX:8872a338 EDX:0a8f900c
 ESI:8872a338 EDI:0a8f9c60
Stack dump:
0x0e44e3f8:  0000000c 0050427d 0a8f9c60 0a8f9c64
0x0e44e408:  0e44e503 00000000 0a8f900c 0e44df7c
0x0e44e418:  0e44e5f8 0050ae3c 005251e0 00000000
0x0e44e428:  0e44e46c 004a7733 8872a338 0000000c
0x0e44e438:  0a7d95e7 004a658e 0a8f8280 00000000
0x0e44e448:  0e44e5b4 004c8cba 00000003 0a56d080
Backtrace:
=>0 0x004a6591 in recettear (+0xa6591) (0x0e44e428)
  1 0x004a7733 in recettear (+0xa7732) (0x0e44e46c)
  2 0x00402c6c in recettear (+0x2c6b) (0x0e44e5bc)
  3 0x00402932 in recettear (+0x2931) (0x0e44e604)
  4 0x00402b12 in recettear (+0x2b11) (0x0e44e650)
  5 0x004026cb in recettear (+0x26ca) (0x0e44e698)
  6 0x00403e41 in recettear (+0x3e40) (0x0e44e6b0)
  7 0x0047404c in recettear (+0x7404b) (0x0e44ea74)
  8 0x00452c29 in recettear (+0x52c28) (0x0e44ea88)
  9 0x7bc70780 call_thread_entry_point+0x6f() in ntdll (0x0e44eb58)
  10 0x7bc7a25f in ntdll (+0x6a25e) (0x0e44f398)
  11 0xf755bcf3 start_thread+0xd2() in libpthread.so.0 (0x0e44f498)
0x004a6591: pushl       0x4(%esi)
Modules:

There are a lot of modules

Backtrace:
=>0 0x004a6591 in recettear (+0xa6591) (0x0e44e428)
  1 0x004a7733 in recettear (+0xa7732) (0x0e44e46c)
  2 0x00402c6c in recettear (+0x2c6b) (0x0e44e5bc)
  3 0x00402932 in recettear (+0x2931) (0x0e44e604)
  4 0x00402b12 in recettear (+0x2b11) (0x0e44e650)
  5 0x004026cb in recettear (+0x26ca) (0x0e44e698)
  6 0x00403e41 in recettear (+0x3e40) (0x0e44e6b0)
  7 0x0047404c in recettear (+0x7404b) (0x0e44ea74)
  8 0x00452c29 in recettear (+0x52c28) (0x0e44ea88)
  9 0x7bc70780 call_thread_entry_point+0x6f() in ntdll (0x0e44eb58)
  10 0x7bc7a25f in ntdll (+0x6a25e) (0x0e44f398)
  11 0xf755bcf3 start_thread+0xd2() in libpthread.so.0 (0x0e44f498)

The whole file is available on request.

Hi,

Upload the entire logfile (gzipped) to the same location if you would,
as there's a need to see what happened leading up to that point...

Cheers!

It was uploaded as notepad-recettear-crash.txt1.gz (I apparently need to think of more original names :) )

According to emacs, the section I posted starts at line 197811, the first instance of "page fault" in the file (hooray memory).

...As a side note, now that I actually think about "page faults"...I do not have any swap space on this system. I could make some easily if needed, there are unused hard drives around here.

I've gone through 2 dungeons now (the original Trials plus a forest level), 5 levels, without a problem. In both dungeons I had no crashes and no glitches. You can see the sound thread for what setup changes I made to the game, but I basically only put in overrides for about a dozen sound/directx-related libraries, in order to get sound working. Oh, and it's the Steam version I've been playing.

Hi again,

Kevin, I take it from your avatar that you're using Mac? If you
would, can you please post your platform/OS{version}/videocard
specs here? I know there are some apps that have sound in linux
and not in OSX, and that disparity might cause some confusion - best
we spell it all out to avoid such 8)

Cheers!

Good point. I'm running CrossOver Games for Mac on a Quad-Core Mac Pro (MacPro3,1) with an aftermarket GeForce GTX 285 card installed (and the updated 10.6 drivers from nVidia) running OS X 10.6.4.

Groovy, thanks for that -- helps to better qualify your experience ;)

Cheers!

I'm going to install now from Steam and see if I can replicate this (and I want to try the DirectSound overrides as well).