Here is the debug report for a total calamity. Got two error messages I could click away. Then the game minimized. I clicked on it again, but now couldn't do squat. Couldn't change workspaces (I like to have the browser in one WS, and the game in another), and couldn't force-kill it (see above).

Not sure how familiar people are with the game, seeing as it's not on GOG, but this occurred while I was looking through the inventory of a vendor. Don't think it has crashed while doing that before, but it has crashed a few times while looking at my personal stash, so probably related to whatever goes wrong with that.

[06/06/18 02:03:03] - Running wine-3.8 PathOfExile.exe --garbage-generation 1 --waitforpreload (Working directory : /home/pangaea/.PlayOnLinux/wineprefix/PathofExile/drive_c/Program Files (x86)/Grinding Gear Games/Path of Exile)
p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so: /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so: cannot open shared object file: No such file or directory
p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 10 (X_UnmapWindow)
Resource id in failed request: 0x6000001
Serial number of failed request: 220
Current serial number in output stream: 223

I have added the garbage generation and preload command because some people said it would help.

O__o I see. That goes deeper than just Wine. DX 9 game really shouldn't be able to crash X like that. Seems more like a X/GPU driver bug. :(

Sidenote, winetricks usp10 is recommended to "fix unicode missing symbols".

Haven't seen crashes like that before, but it happens quite a few times now. Frustrating that it's so unstable and it's just a matter of time, not if. I've installed usp10 btw, but I still get some font issues. Plus "Could not creat thread", whatever that means. I've also installed riched20 and riched30.

One thing I saw in a guide (think it was on the wiki) was to install vcrun2015. It's not in POL though, so I've not been able to do it. I tried the winetricks command, but just got some error messages.

Others on the official forum has talked about Lutris and VXVK (I may have butchered that last bit), but they still report crashes and issues, so I'm not sure what's best. At least shadows work for me, which others have reported to be missing. Guess the game simply doesn't run all that well through wine, sadly :(

It's odd though. It works flawlessly as far as I can tell. Until it suddenly crashes, and even takes out X from time to time. So I hoped it was possible to fix whatever is wrong, so it works flawlessly ALL the time. I just don't know what the issue is, and don't have the knowledge to fix it anyway. Which is why I keep posting here about it. And the official forum, but nobody replies there.

That's very strange, back when I played regularly I went far into the game and it worked flawless, maybe a recent update changed that?

Does it happen in a specific area or randomly anywhere?

I've only played recently, so don't know how it was before. But right now it seems very random, or possibly tied to playing time. I can usually play for maybe 2-3 hours before it crashes. It doesn't crash in a particular area, or if there is one, it's generally in the "home" area, like Sarn Camp and such. What typically happens is the game crashes when trying to transfer from one area to another using a Waypoint. Or while I'm looking through the inventory while in 'camp'. But usually on area transfers.

This behaviour always makes me nervous on bigger quests, like when I had that run in the first Labyrinth. And I'm only in Act 5, and way later things will probably get much, much tougher, so it would be a right pain to have it crash every so often, and needing to redo large and difficult areas.

Difficult to pin down what is actually wrong given that the game runs flawlessly for hours, but the error messages correspond to what I see others write too: 2D art errors, font errors, and "Can not create thread" errors. Usually on area transfers.

At least there is a positive with this online-always malarky, in that everything must be recorded in real time. When it crashes, all my items are still there and suchlike, even if I sell something right before the crash.

Have you monitored Virtual Memory usage? 3 hrs seems more or less the time it takes to fill up to 4GB and goes puff.

this probably won't help with the crashes, but try and install wine via your distributions package manager, that should install all dependencies as well and get rid of the above error.
You can still continue to use the wine version from PoL.

Tried to install it, and was then told it would remove winehq-staging, which doesn't sound like a great idea :/ Afraid things will get more messed up, but please advice. Also, it would install wine 1.6, which is an ancient version by now.
Have played for maybe 2 hours now, and kept checking the memory usage via System Monitor. It kept rising, but not by extreme amounts. I only have 8GB, though. When the game crashed ("Bad allocation" error message this time) PathOfExile.exe used 3.0GiB, and total usage was 6.0GiB. I have a 1GB /swap but it's basically never used. 16KiB at the crash (and now a while after).

Looking at the log file this is recorded (timestamp indicates around 100 minutes of playtime, assuming it's the start of the session):

[06/07/18 20:55:35] - Running wine-3.8 PathOfExile.exe --garbage-generation 1 --waitforpreload (Working directory : /home/pangaea/.PlayOnLinux/wineprefix/PathofExile/drive_c/Program Files (x86)/Grinding Gear Games/Path of Exile)
p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so: /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so: cannot open shared object file: No such file or directory
p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory
mmap() failed: Cannot allocate memory
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Protocol error

mmap() failed: Cannot allocate memory
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Protocol error

mmap() failed: Cannot allocate memory
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Protocol error

mmap() failed: Cannot allocate memory
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Protocol error

This is an optional WINE dependencies, but I’ve never seen it used by any of the hundreds of Windows game I’ve tested.

(VAS) Virtual Address Space (also called Virtual Memory) is not to be confused with Physical Ram or Swap Space.

For example Witcher 3 on Linux allocates 45GB of VAS but consumes only 2.3GB of Physical Ram. With 64bit software this a non issue, with 32bit however each program is limited to 4GB and unfortunately in some games this limit is reached in a short amount of time. The next time you're playing, monitor the Virtual Memory, as soon as it hits 3.9GB get ready to expect a crash at any time.

A few other 32bit games are affected by this on Wine, for some it happens a few minutes in game, others may take hours (as is with PoE).

-------------------------
Research:

The old Guild Wars 2 32bit client was a hot topic about this, as it crashed a lot even on Windows and it has often been talked about that the problem boils down to Memory Fragmentation.

Someone explained this in simple terms: Sorry for the long post.

It's DXVK. Your card is DX12/Vulcan capable. I'd say it's worth a try. Even if the game crashes it might not take out X with it. I would make a separate prefix for it and use the 64-bit client if that's running.

Thank you for the explanation and clarification. Suspected I wasn't looking at the right thing, but didn't find an overview of VIRTUAL memory usage. Since then I've kept a tab on it with htop while playing, and you are 100% correct. Once virtual memory usage gets to 4GB (or slightly under), the game will crash. The reason this often occurs during area transfers is because the game needs to load more data, and gets over the line. Must be the same reason it sometimes crashes while in vendor or inventory, as it needs to load new item data.

Is there anything to be done about it?

Didn't think this would be a problem given that I'm playing the game in a 64-bit virtual drive, but maybe that doesn't matter. Is there some registry or other setting I can change to allow applications to use more than 4GB of virtual memory, or is this limitation elsewhere, like in the game itself or POL/wine?

Unfortunately not much at the moment and quite a few games are affected by it. All 32bit software have this limitation of 4GB Virtual Address Space, it's an architecture limitation so you can't do anything about that. You can sometimes delay the crash a bit longer by reducing the graphics details.

Maybe if Linux addresses the VAS more efficiently, that might solve the issue but I'm unaware how that can be accomplished.

Here's one explanation of what's going on here:

Every memory location has an address. (Well, technically, a memory location can have multiple addresses; one physical address and multiple virtual address, but as far as a single user-mode process is concerned, each memory location has only one.) The address is an integer, and at each address, one byte of memory can be found. Hence, to have a kilobyte, you would need around 1000 address, one for each byte in the kilobyte.

In a 32-bit system, each address is 32 bits (4 bytes) long; hence, the number of possible memory addresses is limited to how much can fit in 32 bits. Since each bit is a binary digit, there are 2^32 (about 4 billion) memory addresses available; hence, the process's virtual address space has at most about 4 billion addresses available; with each address locating one byte, this allows for at most 4GB of memory in the process's address space.

Note that the address space does not necessarily include data on disk; a program can avoid the address space limitation by saving data to disk and then later reload it when needed. (Note that files and disks can be mapped to memory; on UNIX and Linux, this is done via mmap(), and Windows has a similar feature.)

In a 64-bit system, each address is 64 bits (8 bytes) long, which allows for 2^64 bytes of addressable memory. That amount is huge; so huge, in fact, that 64-bit x86 CPUs don't actually implement all those bits on the address bus. In any case, going to 64 bit will, for practical purposes, get rid of any issues of running out of address space. (It also allows ASLR to be more effective, which is good for security.)