https://bugs.winehq.org/show_bug.cgi?id=54034
Bug ID: 54034 Summary: Treasure Adventure World: a deluge of wine bugs Product: Wine Version: 7.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: galtgendo@o2.pl Distribution: ---
There are quite a few bugs here.
1. 'Type 1' cutscene player fails silently, 'Type 2' crashes.
2. Text on inventory screen is drawn at a wrong position.
3. Game crashes due to gfx running out of vms shortly after exiting and reentering first room.
3b. The modal error dialogs related to those crashes appear *under* the game window.
(going by proton database, things at least somewhat worked somewhere in the past, but that no longer the case)
https://bugs.winehq.org/show_bug.cgi?id=54034
--- Comment #1 from Rafał Mużyło galtgendo@o2.pl --- Created attachment 73599 --> https://bugs.winehq.org/attachment.cgi?id=73599 patch for problem 2
Problem 2 seems to have a simple solution.
I'm not sure it's a correct one, but in this context it works.
https://bugs.winehq.org/show_bug.cgi?id=54034
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be
--- Comment #2 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
Please make this bug about issue 2 and report the others in separate bugs. The chance to get the attention of experts in each domain will be greater.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=54034
--- Comment #3 from Rafał Mużyło galtgendo@o2.pl --- (In reply to Olivier F. R. Dierick from comment #2)
Please make this bug about issue 2 and report the others in separate bugs. The chance to get the attention of experts in each domain will be greater.
TBH, meh...
While I haven't checked it yet, one of those two cutscene players failed to work with a strange message about being unable to load gst-plugins-libav. At that point I haven't noticed the vms exhaustion problem, but thinking about it now, I strongly suspect that was the problem - though likely not the sole problem.
As such, I've got a bad feeling that the only real hope for a fix will be 32-on-64 lifting the vms limit. Though it would be nice to be wrong about that. Cause besides vms, memory consumption is also a bit high for a game of this size. Perhaps implementing box filter (D3DX_FILTER_BOX) would help with that.
...and as for the modal dialogs, while I don't recall the bug number, IIRC there's already a general bug about wine mishandling those in some of the cases.
https://bugs.winehq.org/show_bug.cgi?id=54034
--- Comment #4 from Rafał Mużyło galtgendo@o2.pl --- Created attachment 73617 --> https://bugs.winehq.org/attachment.cgi?id=73617 second version of first patch
Now, this one is untested (and I'm unsure how to properly test this), but if my understanding of set_states helper is correct, this should be correct too.
If I'm wrong, that most likely means more calls in set_states need to be put under the second flag.
https://bugs.winehq.org/show_bug.cgi?id=54034
--- Comment #5 from Rafał Mużyło galtgendo@o2.pl --- It seems Zeb has made significant progress with OpenGL memory management, cause now you can play for quite awhile before you get flooded by GL_OUT_OF_MEMORY glitches.
But once they do..., well, it's time to restart the game.
https://bugs.winehq.org/show_bug.cgi?id=54034
--- Comment #6 from Rafał Mużyło galtgendo@o2.pl --- ...yet, besides those oom crashes, there's another one, very rare (happening only upon picking up journal pages), yet very odd one - it happens within the executable (which - given the author went with 'embed everything *and* the kitchen sink' route - tells nothing in particular), gdb prints nothing of use in the backtrace, it's simply a segfault...
From what I've seen on the youtube videos, nothing particular happens at the time crash does (see - for example - https://www.youtube.com/watch?v=8iKS4UxTBzc&list=PLVmM0UVcquYKBU8v-OGoJ4... bit past 27min mark) - the crash happens as the pickup notification is supposed to change to showing the page's content.
https://bugs.winehq.org/show_bug.cgi?id=54034
--- Comment #7 from Rafał Mużyło galtgendo@o2.pl --- ...I think I'm going to sulk now, cause this doesn't make sense...
The crash indeed happens as the content of the page is supposed to be displayed, but something is extremely fishy here.
The game gets its translation from what is basically an ini file (parsed by GetPrivateProfileString). The keys for the journal are in 'page_scroll05' section, named 'line<num>'. AFAICT, the parsing succeeds, yet if the line is about 530 chars long (key included) there's a crash, but with 529 chars things work fine...
Given the embedded '\n' in the string, that's suspiciously close to 512, yet it might be just circumstantial...
For this to be an oom crash, the number is a bit too consistent, yet I've got no idea what else could that be...
https://bugs.winehq.org/show_bug.cgi?id=54034
--- Comment #8 from Rafał Mużyło galtgendo@o2.pl --- The engine of this game is apparently Construct Classic (or perhaps a slightly modified variant) and is sort of open source. Yet that doesn't really help.
Putting overrides on the used d3dx9 libraries doesn't help (apparently ID3DXFont::DrawText is used to output text). However, there's something interesting in the d3dx channel - just before the crash, there seems to be some trash in the pString argument of the call...
https://bugs.winehq.org/show_bug.cgi?id=54034
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Treasure Adventure World: a |Treasure Adventure World |deluge of wine bugs |leaks memory (gfx ?) CC| |z.figura12@gmail.com
--- Comment #9 from Rafał Mużyło galtgendo@o2.pl --- OK, as this is going nowhere, let's try to soft reboot this bug.
Summary:
- initial report (for the most part) seems to fall into 'odd things that happen in low memory conditions' category
- however, the low memory is caused by the game and while it's not as bad as it was when the bug was initially reported, it's still seems to be too high for this kind of game (sysreq-wise) and seems to behave like a leak (grows with time); I strongly suspect it's a gfx resource leak
- I'm all but certain, that the patch from comment 1 (for a minor issue unrelated to the leak) is correct; the version from comment 4 is syntactically better, but its other part is an unbound guesstimate
- I have no idea what the crash described in comment 6 is; it's not related to the leak (can be reproduced shortly after restart, as long as you have a close checkpoint), behaves like a buffer overflow, but the buffer seems to contain garbage at the time of the crash (could this be some wine internal buffer limit for one of the functions underpinning ID3DXFont::DrawText ?)
https://bugs.winehq.org/show_bug.cgi?id=54034
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |d3d
--- Comment #10 from Rafał Mużyło galtgendo@o2.pl --- OK, so one of my guesses was correct.
Therefore, moving this bug fully into graphics - d3d for now, perhaps wined3d later on.
That odd crash was indeed sort of a buffer overflow and one caused by an internal wine limit, but moving that to a new bug, as it's purely user32.
https://bugs.winehq.org/show_bug.cgi?id=54034
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|z.figura12@gmail.com | Component|d3d |-unknown
https://bugs.winehq.org/show_bug.cgi?id=54034
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Treasure Adventure World |Treasure Adventure World, |leaks memory (gfx ?) |text on inventory screen is | |in the wrong place Component|-unknown |d3d-util
--- Comment #11 from Matteo Bruni matteo.mystral@gmail.com --- This bug is quite a mess. I think it would be helpful to focus on the d3dx9 sprite issues here and leave the crashes to separate bugs (assuming those are still happening).
https://bugs.winehq.org/show_bug.cgi?id=54034
--- Comment #12 from Rafał Mużyło galtgendo@o2.pl --- TBH, I haven't tested the memleak in quite awhile, even though I expect it to still be a problem.
The crash was moved into bug 55960, which was marked as a dupe of bug 48559, which is still pending, though the patch there fixes the crashes as my buffer size hack did.