https://bugs.winehq.org/show_bug.cgi?id=53711
Bug ID: 53711 Summary: Final Fantasy XI Crashes Product: Wine Version: 7.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: pandora.xero@gmail.com Distribution: ---
Created attachment 73136 --> https://bugs.winehq.org/attachment.cgi?id=73136 most recent backtrace, 20220920 122500 US Central.
I have multiple occurrences over the past several months (most of which I have saved the backtraces for) of the game crashing.
Symptoms include: Game crash on logout Occasional Game crash on zone Failure to load textures, or glitched textures loaded
I am unable to glean any information from the backtraces, primarily because I am not familiar with x86 assembly, but I have had issues like these for a while now. They mostly occur after switching between characters multiple times, or zoning a large number of times, but the most recent one (attached) was totally random as I was walking through a zone.
https://bugs.winehq.org/show_bug.cgi?id=53711
Chiitoo chiitoo@gentoo.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chiitoo@gentoo.org
--- Comment #1 from Chiitoo chiitoo@gentoo.org --- I have seen these as well, and have been trying to figure out more about the "running out of /something/" issue in particular (glitches textures looking a bit like running out of VRAM) for about half a year now. Discussed it quite a bit with zf via IRC as well, but we couldn't find anything conclusive so far.
That being said, it has been quite a long while now since I've seen any of this myself, that is, not the random sudden crash especially when logging out, nor the glitched textures when running out of something.
I've been using the 9999 version on Gentoo (git master), but looking at the dates, if the cause(s) would have been fixed, I believe the fixes should be in 7.17.
Of course it's possible the issue is actually caused by something outside of Wine, but I can't remember any longer what versions of mesa I have tried for example (I am running with amdgpu, using an RX5700XT), and currently have version 22.0.5 installed which isn't even in the main Gentoo repo any longer (there's a bug making VAAPI recording glitchy in later versions).
I'll see if these things will happen for me too still, and gather my old findings and include them. The random nature makes this particularly annoying, although waiting for the crash isn't really necessary for the "running out of something" issue (maybe the other crash is related though).
Thanks for reporting this since I never got to it still.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #2 from pandora.xero@gmail.com --- Created attachment 73141 --> https://bugs.winehq.org/attachment.cgi?id=73141 backtrace, 20220921 0900000 US Central Time
Symptoms - Game crashes to Black Screen on character logout. This backtrace appears to implicate wined3d/d3d8. This is after maybe 20 times switching characters.
https://bugs.winehq.org/show_bug.cgi?id=53711
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #3 from joaopa jeremielapuree@yahoo.fr --- Unless developers request it, backtrace is pretty useless. Please attach the full console output. And install debug symbols.
https://bugs.winehq.org/show_bug.cgi?id=53711
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #4 from Zeb Figura z.figura12@gmail.com --- (In reply to joaopa from comment #3)
Unless developers request it, backtrace is pretty useless. Please attach the full console output. And install debug symbols.
I wouldn't say it's useless, actually (and in some cases it can even be more informative than console output). Ideally we'd like both where applicable.
In this case I've already discussed the bug with Chiitoo, and the problem is probably virtual address space exhaustion, although I've already forgotten some of the details.
https://bugs.winehq.org/show_bug.cgi?id=53711
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Final Fantasy XI Crashes |Final Fantasy XI crashes | |randomly at multiple points
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #5 from pandora.xero@gmail.com --- (In reply to Zeb Figura from comment #4)
(In reply to joaopa from comment #3)
Unless developers request it, backtrace is pretty useless. Please attach the full console output. And install debug symbols.
I wouldn't say it's useless, actually (and in some cases it can even be more informative than console output). Ideally we'd like both where applicable.
In this case I've already discussed the bug with Chiitoo, and the problem is probably virtual address space exhaustion, although I've already forgotten some of the details.
considering all but one my backtraces seem to have a number over 0x78000000 on the top line (I'm guessing that's an address? I'm not sure how to read backtraces), physical address exhaustion would not surprise me. if I'm not mistaken, 32-bit x86 code restricts individual programs to no more than 2GB allocated. 0x78000000 is getting close enough to that boundary. I'm working on getting a 10TB HDD ready to handle all the console output, but for the time being I'm running the test again with just console output, and however many lines of scrollback I am afforded.
If this is a virtual address space exhaustion issue, I feel the best way to determine if it is a wine issue or a program issue would probably be to see if I get the same results with the same level of utilization on a Windows machine. If it encounters the same or similar problems on windows with the same use case, it may be an issue with the game itself.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #6 from Zeb Figura z.figura12@gmail.com --- (In reply to pandora.xero from comment #5)
(In reply to Zeb Figura from comment #4)
(In reply to joaopa from comment #3)
Unless developers request it, backtrace is pretty useless. Please attach the full console output. And install debug symbols.
I wouldn't say it's useless, actually (and in some cases it can even be more informative than console output). Ideally we'd like both where applicable.
In this case I've already discussed the bug with Chiitoo, and the problem is probably virtual address space exhaustion, although I've already forgotten some of the details.
considering all but one my backtraces seem to have a number over 0x78000000 on the top line (I'm guessing that's an address? I'm not sure how to read backtraces), physical address exhaustion would not surprise me. if I'm not mistaken, 32-bit x86 code restricts individual programs to no more than 2GB allocated. 0x78000000 is getting close enough to that boundary. I'm working on getting a 10TB HDD ready to handle all the console output, but for the time being I'm running the test again with just console output, and however many lines of scrollback I am afforded.
FWIW, in this case I wouldn't worry about getting full console output. Default console output may be helpful, but I think the cause is known.
If this is a virtual address space exhaustion issue, I feel the best way to determine if it is a wine issue or a program issue would probably be to see if I get the same results with the same level of utilization on a Windows machine. If it encounters the same or similar problems on windows with the same use case, it may be an issue with the game itself.
Sure. Although IIRC Chiitoo had reported this as a regression, right?
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #7 from Chiitoo chiitoo@gentoo.org --- (In reply to Zeb Figura from comment #6)
Sure. Although IIRC Chiitoo had reported this as a regression, right?
Yeah, it started happening... I think early this year, but in recent times I have not seen it (but I have not been super actively online in the game either).
I'm still waiting to get a crash here again, which is pretty weird since it was kind of consistent before, if very random...
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #8 from pandora.xero@gmail.com --- (In reply to Chiitoo from comment #7)
(In reply to Zeb Figura from comment #6)
Sure. Although IIRC Chiitoo had reported this as a regression, right?
Yeah, it started happening... I think early this year, but in recent times I have not seen it (but I have not been super actively online in the game either).
And it just so happens that I didn't start logging these things until earlier this year... first one I saved the backtrace for was 20220613 on wine-vanilla-7.10. That one was an addl instead of a movl, had a (0x7dc50c66) on the first line. I still don't know how to interpret all this backtrace output.
I'm still waiting to get a crash here again, which is pretty weird since it was kind of consistent before, if very random...
Like say, it seems to be something that only happens if you have an account with a ton of characters - and I've got 10 on my main account. 1 main, 7 for crafting, 2 for general storage. My post-JST-Midnight routine involves a whole lot of character swapping, so that's usually when it happens. As far as why it happens... no idea. But if it's virtual address space exhaustion (which I would count as "likely") there could be some lazy GC involved, though whether this is on wine's part or the software's part, I can't say at this point.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #9 from pandora.xero@gmail.com --- 20220925 - using 7.17, I managed to get 2.6TB of log output, with +relay on. The backtrace and the log on this one both seem to point to wined3d, but I"m not sure what to make of it. I'll be attaching the backtrace as well as about 1024 lines of output around the crash shortly.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #10 from pandora.xero@gmail.com --- Created attachment 73163 --> https://bugs.winehq.org/attachment.cgi?id=73163 20220925 backtrace
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #11 from pandora.xero@gmail.com --- Created attachment 73164 --> https://bugs.winehq.org/attachment.cgi?id=73164 20220925 log output - trimmed
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #12 from Zeb Figura z.figura12@gmail.com --- I hate to say it, but I don't think +relay is at all useful for this kind of bug. Nor would I even use the entire +d3d log from an hours-long session, probably :-/
One thing I had asked Chiitoo for was essentially a monitoring of adapter_adjust_mapped_memory(), to see if it was gradually increasing over some long period of time. I remember that he responded, but I've forgotten what the logs looked like by now.
Along the same lines it may make sense to e.g. simply watch the process VM use, via top(1) or /proc/<tid>/stat, or something like that.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #13 from pandora.xero@gmail.com --- (In reply to Zeb Figura from comment #12)
I hate to say it, but I don't think +relay is at all useful for this kind of bug. Nor would I even use the entire +d3d log from an hours-long session, probably :-/
One thing I had asked Chiitoo for was essentially a monitoring of adapter_adjust_mapped_memory(), to see if it was gradually increasing over some long period of time. I remember that he responded, but I've forgotten what the logs looked like by now.
Along the same lines it may make sense to e.g. simply watch the process VM use, via top(1) or /proc/<tid>/stat, or something like that.
This may be true... and indeed a trivial task. but if there is, for example, a memory leak, how do we know just by watching the VM use what's causing it?
The VM Use will tell us how much RAM the total process is using... but not necessarily what component of the process is using so much.
I'm going to run this game on Windows for a few days... no third-party software, just the game, and task manager on monitor 2. It doesn't make much sense to keep on testing if we don't have some sort of baseline to test against. And I'll be the first to admit my use case on the game is more than slightly niche.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #14 from Zeb Figura z.figura12@gmail.com --- (In reply to pandora.xero from comment #13)
This may be true... and indeed a trivial task. but if there is, for example, a memory leak, how do we know just by watching the VM use what's causing it?
The VM Use will tell us how much RAM the total process is using... but not necessarily what component of the process is using so much.
We don't, but I also don't remember if it was definitively confirmed that the crash is coming from a memory leak. It could be some very rare race, I guess.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #15 from pandora.xero@gmail.com --- (In reply to Zeb Figura from comment #14)
(In reply to pandora.xero from comment #13)
This may be true... and indeed a trivial task. but if there is, for example, a memory leak, how do we know just by watching the VM use what's causing it?
The VM Use will tell us how much RAM the total process is using... but not necessarily what component of the process is using so much.
We don't, but I also don't remember if it was definitively confirmed that the crash is coming from a memory leak. It could be some very rare race, I guess.
Ran it until it crashed - here's the output from top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 18065 xero 20 0 4174044 497084 94132 S 0.0 0.8 125:46.42 pol.exe
VIRT jumps about 20MB every time I switch characters.
My baseline on Windows only went as high as about 320MB Used - but I'm guessing that number only reflects the equivalent of the RES column here - and that was after much more activity, much more play time, and many more character changes.
I'm unsure as to what's causing VIRT to balloon in size like so. I don't know if this is a factor or not, but the system in question has no swap partition/file, and 64GB of RAM total.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #16 from Zeb Figura z.figura12@gmail.com --- (In reply to pandora.xero from comment #15)
Ran it until it crashed - here's the output from top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 18065 xero 20 0 4174044 497084 94132 S 0.0 0.8 125:46.42 pol.exe
VIRT jumps about 20MB every time I switch characters.
My baseline on Windows only went as high as about 320MB Used - but I'm guessing that number only reflects the equivalent of the RES column here - and that was after much more activity, much more play time, and many more character changes.
I'm unsure as to what's causing VIRT to balloon in size like so. I don't know if this is a factor or not, but the system in question has no swap partition/file, and 64GB of RAM total.
Hmm, interesting. That's a clear sign of a leak, but I'm not immediately sure where. Conveniently, it does mean that it's easier to debug this, because we don't actually need to wait until things crash, but can instead just switch characters a couple of times :-)
20 MB would *not* be consistent with wined3d chunk allocation, since those chunks are 64 MB in size. Of course, it could still be related to d3d, but it's less obvious how.
So here's something that would be helpful to try, if you would. Start wine with WINEDEBUG=+virtual,+pid,+timestamp (redirecting the output to a log file), then do this:
(1) cat /proc/<pid>/maps > maps1 (2) change characters
Repeat this a few times, copying maps into a new file every time; then tar everything up and attach it here.
The idea here is to figure out what's being mapped anew and where. If it's a file or GPU memory, it should be evident, and provide a good hint as to what's leaking it, and if it's anonymous, we should hopefully make it easier to narrow down in Wine where it's coming from.
Thanks!
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #17 from pandora.xero@gmail.com --- Created attachment 73173 --> https://bugs.winehq.org/attachment.cgi?id=73173 collection of log files and memory maps
The log file itself was somewhat large. This .tar.xz file contains: dir.md5 - md5sums of all other files - perhaps a sloppy way to generate a manifest, but it works. map[0-9] - cat /proc/[pid]/maps at various stages important timestamps.txt - output from the launch script, as well as timestamps from various places I deemed important enough to be notable. but timestamps after the 4th one are character logouts and logins. winelog.log - &> output from wine with all the WINEDEBUG channels requested.
It probably would have been better if I had made a script to slap a timestamp into a file, then a general description of its importance, then the 'cat /proc/[pid]/maps' output. I think I'll do that next time if more info is needed.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #18 from pandora.xero@gmail.com --- I have a couple scripts ready to go over the weekend
The first records the WINEDEBUG options and a timestamp to a file, then launches wine, with &> to another file.
The second records a timestamp to one file, memory maps to another, waits for user input, then records a timestamp to a third file and memory maps to a fourth.
I intend to start the game with the first script, launch the second script when I've selected my first character, and then when the game crashes, let the second script finish.
This should provide a baseline memory map, a memory map at the crash, a log with all the specified channels, and a timestamp for each.
I think the maps will be more useful than the logs, mostly because I'm predicting the logs will be anywhere from 200MB to 1GB. I predict the maps will also show the memory expansion much more clearly than what I have right now.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #19 from pandora.xero@gmail.com --- Created attachment 73186 --> https://bugs.winehq.org/attachment.cgi?id=73186 more log and map dumps
This .tar.xz contains: winelog.log - full log file +pid,+virtual,+timestamp backtrace.txt - backtrace from crash mapopen.map - memory map from just after my first character login mapcrash.map - memory map from time of crash maplaunch.stamp - contains timestamp for when wine was launched, as well as the WINEDEBUG channels. mapopen.stamp - contains timestamp for the first memory map mapcrash.stamp - contains timestamp for the memory map at time of crash
The log file is too large to post uncompressed - around 55MB. I'm not sure it'll be of much use, either, except for correlation purposes.
https://bugs.winehq.org/show_bug.cgi?id=53711
pandora.xero@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #73186|0 |1 is obsolete| |
--- Comment #20 from pandora.xero@gmail.com --- Created attachment 73187 --> https://bugs.winehq.org/attachment.cgi?id=73187 20220930 - maps, log, backtrace
(Correction to originally-uploaded file issued because incorrect file extension was causing the file type to be misidentified. No idea how I failed to catch this sooner.)
This .tar.xz contains: winelog.log - full log file +pid,+virtual,+timestamp backtrace.txt - backtrace from crash mapopen.map - memory map from just after my first character login mapcrash.map - memory map from time of crash maplaunch.stamp - contains timestamp for when wine was launched, as well as the WINEDEBUG channels. mapopen.stamp - contains timestamp for the first memory map mapcrash.stamp - contains timestamp for the memory map at time of crash
The log file is too large to post uncompressed - around 55MB. I'm not sure it'll be of much use, either, except for correlation purposes.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #21 from Zeb Figura z.figura12@gmail.com --- Hmm, the log from comment 17 doesn't quite match what you reported wrt the virtual memory size increasing by 20 MB each time. There are a couple increases but not enough for me to be sure of where they're coming from.
I think it's pretty clear that we're running out of memory, especially given the maps file from comment 20 at the time of the crash, but I'm still not confident of why. The amount of mapped GPU memory is 418 MiB, which is not so high as to be a smoking gun, but the rest of it is anonymous.
Here's what I can tell from analyzing the +virtual log and map files from comment 20:
* the low "reserved" area of 0 - 0x20000000 is not much fuller at crash time than it is at open time;
* also, NtAllocateVirtualMemory only ever returns memory inside that reserved area (with I think one exception, but that memory is freed);
* amount of mapped GPU memory (/dev/renderD128) is higher at crash time than open time, but not really so high as to be a smoking gun (418 MiB vs 342 MiB);
* amount of anonymous mapped memory in the non-reserved area (0x20000000 - 0x7f000000) is way higher at 'crash' time than 'open' time.
So I think that whatever memory is being leaked, is not being allocated by the Wine side. This doesn't necessarily mean that it's not Wine's fault it's being leaked (and I would probably assume it is Wine's fault), but it is useful information nonetheless.
I think this means we can rule out d3d memory; sysmem should go through NtAllocateVirtualMemory, and GPU memory *should* be DMA mapped. Unless radeonsi is ever going to give us anonymous mapped memory?
I'll have to think about how to narrow it down further, though.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #22 from pandora.xero@gmail.com --- (In reply to Zeb Figura from comment #21)
Hmm, the log from comment 17 doesn't quite match what you reported wrt the virtual memory size increasing by 20 MB each time. There are a couple increases but not enough for me to be sure of where they're coming from.
I think it's pretty clear that we're running out of memory, especially given the maps file from comment 20 at the time of the crash, but I'm still not confident of why. The amount of mapped GPU memory is 418 MiB, which is not so high as to be a smoking gun, but the rest of it is anonymous.
Here's what I can tell from analyzing the +virtual log and map files from comment 20:
- the low "reserved" area of 0 - 0x20000000 is not much fuller at crash time
than it is at open time;
- also, NtAllocateVirtualMemory only ever returns memory inside that
reserved area (with I think one exception, but that memory is freed);
- amount of mapped GPU memory (/dev/renderD128) is higher at crash time than
open time, but not really so high as to be a smoking gun (418 MiB vs 342 MiB);
- amount of anonymous mapped memory in the non-reserved area (0x20000000 -
0x7f000000) is way higher at 'crash' time than 'open' time.
So I think that whatever memory is being leaked, is not being allocated by the Wine side. This doesn't necessarily mean that it's not Wine's fault it's being leaked (and I would probably assume it is Wine's fault), but it is useful information nonetheless.
I think this means we can rule out d3d memory; sysmem should go through NtAllocateVirtualMemory, and GPU memory *should* be DMA mapped. Unless radeonsi is ever going to give us anonymous mapped memory?
I'll have to think about how to narrow it down further, though.
Well, whenever you have an idea, it seems all I need to make the game crash is about 5 or 6 hours managing inventory between all my characters.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #23 from pandora.xero@gmail.com --- Created attachment 73218 --> https://bugs.winehq.org/attachment.cgi?id=73218 Graphical Glitch Example
.tar.xz Unfortunately, I was just casually playing when this one came up, so I don't have logs. But this one shows a screenshot of what it might look like if the game is about to crash. I know if I see this kind of glitching, it's going to crash within just a couple screen transitions. I included the backtrace and the memory map, for whatever good that does, but my intent here is more to show what happens when the problem DOESN'T immediately cause a crash. SUPER-weird.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #24 from pandora.xero@gmail.com --- for some reason, this bug doesn't seem to be as much of an issue with a fresh win32 WINEPREFIX. I don't know if this is due to it being a fresh prefix, having something configured differently, or a difference between how wine handles things on win32 vs. win64 prefixes.
I'm going to be spinning up 2 fresh wineprefixes - one win64, one win32 - once 7.19 is released.
I'm going to attempt to eliminate as many variables as possible in setup. Everything from installation procedure to configuration of the game will be duplicated as precisely as possible.
If there's some difference in the configuration that's causing these issues on the current win64 prefix and not the current win32 prefix, some difference in how I installed the game, or some difference in how wine handles win32 vs. win64, this should be able to give us some indication.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #25 from pandora.xero@gmail.com --- My most recent testing has complicated my prior assumptions. in about 30 hours that I have had this game going, I have experienced perhaps a total of 200MB of Virtual Memory inflation. All told, I feel this level of memory inflation is "normal"
I'm working with three separate variables, though, and each is a binary decision, where I do one thing or do the other thing. obviously, this means I have 2^3 testing scenarios to work with.
The variables being worked with are: WINEARCH: win32 or win64 DirectX Runtime Supplied with Final Fantasy XI: Install or No Rendering resolution: Same as screen resolution or double.
The installation where I had issues was win64, no DX Runtime, and render resolution set to double. I'm testing win64, with DX runtime and render set to monitor resolution right now.
Given that I am seeing no issues with virtual memory inflation, my next step is to flip the render resolution to double. I should have some sort of update here around this time Tuesday. If the game crashes, I may have results even sooner.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #26 from pandora.xero@gmail.com --- after 48 hours, I have had no luck replicating the issue I was having. I'm going to go about this a slightly different way. I'm going to replicate EVERY factor I can think of from the install which was having issues. I'll report back by Thursday.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #27 from pandora.xero@gmail.com --- top - 09:41:37 up 14 days, 19:57, 3 users, load average: 1.92, 2.07, 1.98 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie %Cpu(s): 8.7 us, 1.0 sy, 0.0 ni, 90.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 64231.3 total, 8516.3 free, 2295.9 used, 53419.2 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 61294.7 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 11138 xero 20 0 3456708 495004 94056 S 113.0 0.8 3223:37 pol.exe
it's just. not. expanding. I'm going to check my old wineprefix. If I'm still having issues there, I'll assume it's something to do with a very specific configuration there. If not, then I'll assume whatever WAS wrong has righted itself
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #28 from pandora.xero@gmail.com --- output from the default WINEPREFIX
top - 10:29:29 up 14 days, 20:45, 3 users, load average: 0.78, 0.88, 1.02 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie %Cpu(s): 1.5 us, 0.7 sy, 0.0 ni, 97.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 64231.3 total, 8259.9 free, 2227.0 used, 53744.5 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 61363.9 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6612 xero 20 0 3381688 298204 93020 S 23.3 0.5 0:37.98 pol.exe
top - 12:55:43 up 14 days, 23:11, 3 users, load average: 0.96, 1.02, 1.00 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.0 sy, 0.0 ni, 99.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 64231.3 total, 7963.8 free, 2448.8 used, 53818.6 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 61141.4 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6612 xero 20 0 4127340 439764 93336 S 0.0 0.7 58:07.49 pol.exe
...as you can see, it didn't take long at all for me to crash the old WINEPREFIX. I think this may be something to do with cruft that was somehow left in from older wine versions. How that's possible, I have NO IDEA. But this install which has been in place since 7.7 does this, whereas my brand new 7.19 install using a fresh WINEPREFIX doesn't, regardless what I throw at it. I'm going to rm -rf this prefix, the mv the new prefix to ~/.wine - that should solve my problems.
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #29 from Chiitoo chiitoo@gentoo.org --- I haven't seen this in a long while myself now, or anything similar to it aside from 2 different(?) ones recently, which got fixed already (well, actually, just tracking one of them down still, but pretty sure it's different too).
Haven't heard from pandora.xero in a bit, but I don't think they have seen this in a while either. Permaybehaps?
https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #30 from Chiitoo chiitoo@gentoo.org --- While chasing the leak affecting debug builds [1], I noticed something very similar to this one when running with 'WINE_D3D_CONFIG=csmt=0'.
Pretty much every time I go from the launcher (PlayOnline Viewer) to the game, or from the character selection to and from the game, there is a split second flash of garbage graphics, sometimes parts of a video playing on another screen for example, and the VIRT size jumps up by about 20MB, which was also mentioned here in comment 15.
Eventually the game will crash in 'wined3d' with
err:d3d:wined3d_context_gl_create_wgl_ctx Failed to create a WGL context.
but due to the leak with '-g' or '-O0' optimisations I haven't been able to get a stack with symbols out of that one yet, though it does seem like another(?) leak.
Sometimes there is no proper Wine crash, but just an X11 error instead and the application is terminated with it.
1. https://bugs.winehq.org/show_bug.cgi?id=56530
-
WineHQ Bugzilla