http://bugs.winehq.org/show_bug.cgi?id=27439
Summary: Age of Pirates - City of Abandoned Ships crashes while entering the sea Product: Wine Version: 1.3.21 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: [email protected] ReportedBy: [email protected]
Created an attachment (id=35091) --> (http://bugs.winehq.org/attachment.cgi?id=35091) wine log while trying to enter the sea
Mostly every time, while trying to enter the sea from landing, game crashes. Some times it is possible to enter the sea, then go into the map mode and go to other island, but the game will crash on next try to enter the sea mode (encounters like storm or pirates, or harbor of other island).
http://bugs.winehq.org/show_bug.cgi?id=27439
Dan Kegel [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #1 from Dan Kegel [email protected] 2011-06-10 09:20:19 CDT --- Here's the key part of the log:
fixme:d3d:device_stream_info_from_declaration Missing vbo streams with unfixed colors or transformed position, expect problems fixme:d3d:resource_check_usage Unhandled usage flags 0x8. ... wine: Unhandled page fault on read access to 0x4d1f8c6b at address 0x681f2bb7 (thread 0021), starting debugger... ... Backtrace: =>0 0x681f2bb7 __GI_memcpy+0x27() in libc.so.6 (0x0033f940) 1 0x2003624a wined3d_buffer_preload+0x369() in wined3d (0x0033f940) 2 0x200380b5 wined3d_buffer_unmap+0x294() in wined3d (0x0033f9c0) 3 0x2016ad31 d3d8_vertexbuffer_Unlock+0x60() in d3d8 (0x0033f9f0) 0x681f2bb7 __GI_memcpy+0x27 in libc.so.6: movsb (%esi),%es:(%edi)
http://bugs.winehq.org/show_bug.cgi?id=27439
[email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #2 from [email protected] 2011-06-12 05:39:25 CDT --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=27439
joaopa [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #3 from joaopa [email protected] 2011-08-27 23:55:03 CDT --- still a bug in current wine, 1.3.27?
http://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #4 from Maxym Kit [email protected] 2011-08-29 16:17:47 CDT --- Yes, still a bug in 1.3.27.
http://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #5 from Maxym Kit [email protected] 2011-09-12 15:10:10 CDT --- I have some skills in programming and willing to help to resolve this issue, but I don't know from where to start. Can someone point me where to look and related to what this issue is?
http://bugs.winehq.org/show_bug.cgi?id=27439
Windom Earle [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #6 from Windom Earle [email protected] 2011-11-01 11:01:26 CDT --- Look like that crash occurs there in memcpy: http://source.winehq.org/source/dlls/wined3d/buffer.c?v=wine-1.3.31#L901
wine-1.3.31 wined3d buffer.c
... /* Now for each vertex in the buffer that needs conversion */ vertices = buffer->resource.size / buffer->stride;
data = HeapAlloc(GetProcessHeap(), 0, buffer->resource.size);
while(buffer->modified_areas) { buffer->modified_areas--; start = buffer->maps[buffer->modified_areas].offset; len = buffer->maps[buffer->modified_areas].size; end = start + len;
memcpy(data + start, buffer->resource.allocatedMemory + start, end - start); for (i = start / buffer->stride; i < min((end / buffer->stride) + 1, vertices); ++i) { for (j = 0; j < buffer->stride; ++j) { switch (buffer->conversion_map[j]) { case CONV_NONE: /* Done already */ j += 3; break; case CONV_D3DCOLOR: fixup_d3dcolor((DWORD *) (data + i * buffer->stride + j)); j += 3; break;
case CONV_POSITIONT: fixup_transformed_pos((float *) (data + i * buffer->stride + j)); j += 15; break; default: FIXME("Unimplemented conversion %d in shifted conversion\n", buffer->conversion_map[j]); } } } ...
The reason ... maybe HeapAlloc failed (its result isn't checked in this code)?
http://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #7 from Henri Verbeet [email protected] 2011-11-01 14:40:41 CDT --- (In reply to comment #6)
The reason ... maybe HeapAlloc failed (its result isn't checked in this code)?
Considering it fails on read access, it's probably more likely that either buffer->resource.allocatedMemory is invalid or start / end are wrong.
http://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #8 from Windom Earle [email protected] 2011-11-01 14:45:43 CDT --- Yes, I was wrong about HeapAlloc!
when crashed in my case:
data = 0x0d3fedb0, start = 0x3f3608da, !!! len = 0x3f0eafe9, !!! buffer->resource.allocatedMemory = 0x053a50d0
In all other, valid calls: start = 0x00000000 len < 0x00001000
Hmmm...
http://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #9 from Windom Earle [email protected] 2011-11-02 01:21:43 CDT --- ...Some additional trace log details for this crash: ... trace:d3d:wined3d_buffer_map buffer 0xf2c9d68, offset 0, size 912, data 0x32f9dc, flags 0 trace:d3d:wined3d_buffer_map Returning memory at 0xf2c9e30 (base 0xf2c9e30, offset 0). trace:d3d:wined3d_buffer_unmap buffer 0xf2c9d68. trace:d3d:wined3d_buffer_preload buffer 0xf2c9d68. trace:d3d:context_acquire device 0x1670b8, target (nil). trace:d3d:context_enter Entering context 0x17e090, level 1. wine: Unhandled page fault on read access to 0x4e62a712 at address 0x68c3bab0 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x4e62a712 in 32-bit code (0x68c3bab0). ...
http://bugs.winehq.org/show_bug.cgi?id=27439
Paweł Szymański [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
http://bugs.winehq.org/show_bug.cgi?id=27439
[email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #10 from [email protected] 2012-06-04 04:20:19 CDT --- It affects also Age of Pirates: Carribbean Tales (prequel to AoP2) and it is still an issue in 1.4. Crash on changing screens and/or modes (land/sea/map). Could it be fixed by anyone? Help of any programmer would be very appreciated. I can provide any logs needed.
http://bugs.winehq.org/show_bug.cgi?id=27439
Paul The Tall [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #11 from Paul The Tall [email protected] 2012-09-17 07:44:53 CDT --- Is is still there. It also accurs on Pirates on the caribean.
http://bugs.winehq.org/show_bug.cgi?id=27439
[email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
http://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #12 from [email protected] 2013-03-14 07:35:11 CDT --- Bump for the great justice
http://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #13 from [email protected] 2013-04-04 05:00:55 CDT --- Created attachment 44087 --> http://bugs.winehq.org/attachment.cgi?id=44087 Backtrace log on crashing (changing screens)
Still the same problem! Game works just great but crashes.
http://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #14 from Henri Verbeet [email protected] 2013-04-10 15:04:52 CDT --- I guess I lost track of this one.
(In reply to comment #8)
Yes, I was wrong about HeapAlloc!
when crashed in my case:
data = 0x0d3fedb0, start = 0x3f3608da, !!! len = 0x3f0eafe9, !!! buffer->resource.allocatedMemory = 0x053a50d0
Yeah, those start and len values look wrong. In principle you should be able to see a previous call to wined3d_buffer_map() with equivalent arguments in that case, but buffer_add_dirty_area() would probably have filtered those out, so it seems more likely that there's some kind of memory corruption going on. Perhaps a "+seh,+tid,warn+heap,+d3d8,+d3d" log can provide some more information.
http://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #15 from Paul The Tall [email protected] 2013-04-10 15:11:45 CDT --- yes please Henri, look into this one. This counts for All the age of Pirates game and Pirates of the Caribean. Thanks again!
http://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #16 from [email protected] 2013-04-10 16:21:46 CDT --- (In reply to comment #15)
yes please Henri, look into this one. This counts for All the age of Pirates game and Pirates of the Caribean. Thanks again!
Please upload debug log as Henri specified. It may turn out pretty big so compress it.
Run the game in clean wineprefix by: WINEDEBUG="+seh,+tid,warn+heap,+d3d8,+d3d" engine.exe
I am uploading mine in a minute.
http://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #17 from [email protected] 2013-04-10 16:48:59 CDT --- http://www.mediafire.com/?4s43iumor9vfvd6
This is a debug log with "+seh,+tid,warn+heap,+d3d8,+d3d" (too big to make an attachment to the post).
A game did not crash when changing screens but because of extremely CPU-heavy debugging I runned it at like 1 FPS.
The game crashed at the very end on quitting but I believe it is completely another bug we don't need to worry about now.
http://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #18 from Maxym Kit [email protected] 2013-04-11 16:22:15 CDT --- Created attachment 44148 --> http://bugs.winehq.org/attachment.cgi?id=44148 aop - city of abandoned ships crashed after entering the sea from world map
WINEDEBUG="+seh,+tid,warn+heap,+d3d8,+d3d" With WINEDEBUG enabled game allowed to enter the sea from city port, but then crashed on returning into sea mode from world map mode.
http://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #19 from Maksym Kit [email protected] 2013-10-01 18:38:50 CDT --- This bug still present in wine-1.7.3
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #20 from Austin English [email protected] --- This is your friendly reminder that there has been no bug activity for over a year. Is this still an issue in current (1.7.37 or newer) wine? If so, please attach the terminal output in 1.7.37 (see http://wiki.winehq.org/FAQ#get_log).
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #21 from Maksym Kit [email protected] --- Created attachment 50883 --> https://bugs.winehq.org/attachment.cgi?id=50883 wine-1.7.37 Run #1
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #22 from Maksym Kit [email protected] --- Created attachment 50884 --> https://bugs.winehq.org/attachment.cgi?id=50884 wine-1.7.37 Run #2
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #23 from Maksym Kit [email protected] --- Created attachment 50885 --> https://bugs.winehq.org/attachment.cgi?id=50885 wine-1.7.37 Run #3
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #24 from Maksym Kit [email protected] --- Created attachment 50886 --> https://bugs.winehq.org/attachment.cgi?id=50886 wine-1.7.37 Run #4
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #25 from Maksym Kit [email protected] --- Created attachment 50887 --> https://bugs.winehq.org/attachment.cgi?id=50887 wine-1.7.37 Run #5
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #26 from Maksym Kit [email protected] --- Created attachment 50888 --> https://bugs.winehq.org/attachment.cgi?id=50888 wine-1.7.37 Run #6, captured log
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #27 from Maksym Kit [email protected] --- Created attachment 50889 --> https://bugs.winehq.org/attachment.cgi?id=50889 wine-1.7.37 Run #6, console output
This stack trace appears just after log in attachment #50888 and wasn't redirected to it. Had to copy-paste it into a file.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #28 from Maksym Kit [email protected] --- Created attachment 50890 --> https://bugs.winehq.org/attachment.cgi?id=50890 wine-1.7.37 Run #7
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #29 from Maksym Kit [email protected] --- Added different stack traces, captured with $ wine engine.exe &> engine.log
After Run #3 I killed PulseAudio because application freezed often without producing stack trace and not showing crash dialog. That resulted in almost every subsequent run producing stack trace without app freeze.
https://bugs.winehq.org/show_bug.cgi?id=27439
Maksym Kit [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #50889|1 |0 is patch| |
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #30 from joaopa [email protected] --- Still a bug in current wine? If yes, is there a demo showing the problem?
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #31 from [email protected] --- Just tried the game with Wine 1.9.7 (32 bit) and yes, it still happens.
As far as I know there is no demo for any game in the series but GOG.com recently re-released Age of Pirates: Caribbean Tales under a different name:
https://www.gog.com/game/sea_dogs_caribbean_tales
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #32 from joaopa [email protected] --- Still a bug in current wine?
https://bugs.winehq.org/show_bug.cgi?id=27439
[email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #33 from [email protected] --- (In reply to joaopa from comment #32)
Still a bug in current wine?
If the GOG version of the game can be counted as valid, I can most certainly check...
https://bugs.winehq.org/show_bug.cgi?id=27439
Peter Kien [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #34 from Peter Kien [email protected] --- (In reply to joaopa from comment #32)
Still a bug in current wine?
Yes, it is. :)
Actually, the game seems to crash more frequently than in earlier versions of wine. ("Earlier" means versions before 2.0)
I've tried wine 2.0 and wine 2.3
https://bugs.winehq.org/show_bug.cgi?id=27439
Lukas Nygaard [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #35 from Lukas Nygaard [email protected] --- I play Pirates of the Caribbean, and this bug still consists. I don´t understand what´s going on. Can it be fixed by a patch or what am I supposed to do? I´d really like to make this game work as it is my favourite game.
- Lukas
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #36 from [email protected] --- (In reply to Lukas Nygaard from comment #35)
I play Pirates of the Caribbean, and this bug still consists. I don´t understand what´s going on. Can it be fixed by a patch or what am I supposed to do? I´d really like to make this game work as it is my favourite game.
- Lukas
It is a very specific bug with a specific DirectX 8 based graphics engine. You can help by convincing one of the Wine developers to work on it, and perhaps gifting them a copy of a game - one of the affected, for example one of Age of Pirates games, currently re-released on GOG as Sea Dogs games: https://www.gog.com/game/sea_dogs_caribbean_tales https://www.gog.com/game/sea_dogs_city_of_abandoned_ships
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #37 from Lukas Nygaard [email protected] --- OK, can you tell me how to contact the Wine developers? I will do as you say if you can tell me who I should write to.
- Lukas
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #38 from [email protected] --- (In reply to Lukas Nygaard from comment #37)
OK, can you tell me how to contact the Wine developers? I will do as you say if you can tell me who I should write to.
- Lukas
Last time I did it by entering the Wine IRC channel, but you can also use other ways: https://www.winehq.org/help
The best would be probably purchasing CrossOver to get the commercial customer support from CodeWeavers, the company behind Wine project.
However, none of these methods will be a 100% guarantee that someone will fix this bug. First of all, Wine developers set their own priorities, secondly, the bug might be problematic enough so that fixing it might not be trivial.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #39 from Henri Verbeet [email protected] --- We do occasionally read the bug tracker. IIRC the issue with this bug was that it appeared to be a memory corruption issue, which can be hard to debug remotely. Still, terminal output and a backtrace with current git would probably by good to have, in case the issue changed.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #40 from Lukas Nygaard [email protected] --- I have some logs. How can i share them with you?
(In reply to Henri Verbeet from comment #39)
We do occasionally read the bug tracker. IIRC the issue with this bug was that it appeared to be a memory corruption issue, which can be hard to debug remotely. Still, terminal output and a backtrace with current git would probably by good to have, in case the issue changed.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #41 from [email protected] --- (In reply to Lukas Nygaard from comment #40)
I have some logs. How can i share them with you?
(In reply to Henri Verbeet from comment #39)
We do occasionally read the bug tracker. IIRC the issue with this bug was that it appeared to be a memory corruption issue, which can be hard to debug remotely. Still, terminal output and a backtrace with current git would probably by good to have, in case the issue changed.
If the logs are less than 5 MB in size, you add them as attachments to this bug report. Just make sure to specify what Wine version they are from.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #42 from [email protected] --- (In reply to fjfrackiewicz from comment #41)
(In reply to Lukas Nygaard from comment #40)
I have some logs. How can i share them with you?
(In reply to Henri Verbeet from comment #39)
We do occasionally read the bug tracker. IIRC the issue with this bug was that it appeared to be a memory corruption issue, which can be hard to debug remotely. Still, terminal output and a backtrace with current git would probably by good to have, in case the issue changed.
If the logs are less than 5 MB in size, you add them as attachments to this bug report. Just make sure to specify what Wine version they are from.
Forgot to add: if the logs are larger than 5 MB, you can put them in a .zip file and add the zip files as attachments.
https://bugs.winehq.org/show_bug.cgi?id=27439
Józef Kucia [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #43 from Józef Kucia [email protected] --- Created attachment 57957 --> https://bugs.winehq.org/attachment.cgi?id=57957 Hack
The game most likely writes past the boundary of a mapped buffer memory. Please try the attached patch.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #44 from Lukas Nygaard [email protected] --- Where do I put it? In what kind of log?
- Lukas
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #45 from Lukas Nygaard [email protected] --- I mean, can I put that patch right into terminal? Or do I need to add it somewhere in wine?
- Lukas
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #46 from [email protected] --- (In reply to Lukas Nygaard from comment #45)
I mean, can I put that patch right into terminal? Or do I need to add it somewhere in wine?
- Lukas
You need to download the source code for Wine, patch it with the patch, and then compile that patched source code.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #47 from Lukas Nygaard [email protected] --- OK, so I paste the patch into the source code. But where can I download the source code? And what do you mean by compile.
- Lukas
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #48 from Józef Kucia [email protected] --- (In reply to Lukas Nygaard from comment #47)
OK, so I paste the patch into the source code. But where can I download the source code? And what do you mean by compile.
You should use "git apply" to apply the patch. The following links might be useful: https://wiki.winehq.org/Git_Wine_Tutorial https://wiki.winehq.org/Building_Wine
If you need more help please got to the forums: https://forum.winehq.org/, bugzilla is not the best place for such questions.
https://bugs.winehq.org/show_bug.cgi?id=27439
Gijs Vermeulen [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #49 from Gijs Vermeulen [email protected] --- (In reply to Józef Kucia from comment #43)
Created attachment 57957 [details] Hack
The game most likely writes past the boundary of a mapped buffer memory. Please try the attached patch.
For me the game didn't crash but just hanged/froze and didn't respond anymore. The attached patch fixed the problem for me on macOS 10.10.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #50 from Lukas Nygaard [email protected] --- Do you mean the patch fixed the problem completely? Or is it just somewhat fixed?
- Lukas
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #51 from Lukas Nygaard [email protected] --- (In reply to fjfrackiewicz from comment #46)
(In reply to Lukas Nygaard from comment #45)
I mean, can I put that patch right into terminal? Or do I need to add it somewhere in wine?
- Lukas
You need to download the source code for Wine, patch it with the patch, and then compile that patched source code.
But I'm using a tool called Porting Kit by Paul The Tall... What Should I do exactly? Is it still the wine sourcecode that needs to be replaced?
- Lukas
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #52 from Gijs Vermeulen [email protected] --- (In reply to Lukas Nygaard from comment #50)
Do you mean the patch fixed the problem completely? Or is it just somewhat fixed?
- Lukas
I was able to enter the sea and sail around for 5 minutes or so, didn't test further, but when I tried that with unpatched wine it froze when entering the sea.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #53 from Maksym Kit [email protected] --- Confirming that patch from comment #43 made the game more playable. I was able to do more than 50 tries to enter the sea without a crash while doing so on unpatched wine made game crash almost instantly.
I was testing on 32-bit wine, built from sources (wine-2.6 tag, 8dc23c59a0986fa41988c8120a2cfcff761ebaad) on Fedora 24 with nVidia drivers. Game has been launched at 1600x1200 with post-processing enabled and all graphics settings set to high with emulation of virtual desktop and cursor grab.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #54 from Lukas Nygaard [email protected] --- (In reply to Maksym Kit from comment #53)
Confirming that patch from comment #43 made the game more playable. I was able to do more than 50 tries to enter the sea without a crash while doing so on unpatched wine made game crash almost instantly.
I was testing on 32-bit wine, built from sources (wine-2.6 tag, 8dc23c59a0986fa41988c8120a2cfcff761ebaad) on Fedora 24 with nVidia drivers. Game has been launched at 1600x1200 with post-processing enabled and all graphics settings set to high with emulation of virtual desktop and cursor grab.
I still have no idea how to add the patch. But I'm glad it worked and that it is fixed!
- Lukas
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #55 from Lukas Nygaard [email protected] --- For me the game still crashes. It is the Pirates of the Caribbean game this affects mostly. I find it annoying and still hope it can be fixed.
- Lukas
https://bugs.winehq.org/show_bug.cgi?id=27439
Peter Kien [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|[email protected] |
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #56 from Lukas Nygaard [email protected] --- (In reply to Maksym Kit from comment #53)
Confirming that patch from comment #43 made the game more playable. I was able to do more than 50 tries to enter the sea without a crash while doing so on unpatched wine made game crash almost instantly.
I was testing on 32-bit wine, built from sources (wine-2.6 tag, 8dc23c59a0986fa41988c8120a2cfcff761ebaad) on Fedora 24 with nVidia drivers. Game has been launched at 1600x1200 with post-processing enabled and all graphics settings set to high with emulation of virtual desktop and cursor grab.
I have a crashlog that says Pirates of the Caribbean still doesn't work as it should...
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #57 from Lukas Nygaard [email protected] --- Created attachment 58467 --> https://bugs.winehq.org/attachment.cgi?id=58467 Backtrace - Pirates of the Caribbean crash
Here it is. Can it be fixed?
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #58 from joaopa [email protected] --- You need to update your version of wine. Currently; it is 2.9.10 And you need to install debug symbols. Your log is pretty useless.
https://bugs.winehq.org/show_bug.cgi?id=27439
[email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #59 from [email protected] --- (In reply to joaopa from comment #58)
You need to update your version of wine. Currently; it is 2.9.10 And you need to install debug symbols. Your log is pretty useless.
I agree what you said but I doubt it makes any difference what wine version you use the cause needs prober anaylyze and to my understand none has done it even there is workaround.
https://bugs.winehq.org/show_bug.cgi?id=27439
Gijs Vermeulen [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=27439
8472 [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #60 from joaopa [email protected] --- Does the bug still occur with wine-4.0-rc5? It is known to b a buggy game for intel graphic card https://www.moddb.com/mods/city-of-abandoned-ships-combined-mods/downloads/s... Does the mod help if the bug still occurs?
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #61 from Maksym Kit [email protected] --- Tested with wine-4.0 (Staging): the game still crashes when entering the sea or island from sea. Also tried the patch to be sure: it crashes with the patch too.
Tested on - Fedora 28: 4.19.13-200.fc28.x86_64 - using nVidia GeForce GTX 1060 (3GiB) and proprietary driver version 415.25 - using KDE Plasma 5.13.5, KDE Framework 5.53.0, XOrg - running AMD FX-8300.
https://bugs.winehq.org/show_bug.cgi?id=27439
[email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #62 from [email protected] --- Created attachment 65427 --> https://bugs.winehq.org/attachment.cgi?id=65427 logs
tested on wine 4.17 and it does crash. However I have Age of Pirates Caribbean Tales, I thought I will attach my log here since the known bug on WineHQ for Age of Pirates Caribbean Tales is this bug 27439
https://appdb.winehq.org/objectManager.php?sClass=version&iId=11320
However I have two logs. My first test was more successful then the second test. The first test I was able to enter the sea and get on my boat but the game crashes a few seconds after. The second test my game crashes when I tried to enter the sea
https://bugs.winehq.org/show_bug.cgi?id=27439
Kolya [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #63 from Kolya [email protected] --- This bug was fixed in the latest patch (1.7), so no more crashes at all! (except random crashes once in 5-6 hours connected with old engine problems)
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #64 from Maksym Kit [email protected] --- (In reply to Kolya from comment #63)
This bug was fixed in the latest patch (1.7), so no more crashes at all! (except random crashes once in 5-6 hours connected with old engine problems)
What is "latest patch (1.7)"? Is it a version of a patch for the game? I was sure that the latest available patch for game was of version 1.3.2 (Adventure Tales) and would like to know where that patch can be obtained.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #65 from Kolya [email protected] --- 1.7 is a version of Sea Dogs: To Each His Own. After release of latest addon to Sea Dogs: To Each His Own their memory leak bug was fixed (among other small bugfixes) It has the same engine as City of Abandoned Ships, so you can just try it (I mean engine.exe). Now it has "Silver" status at protondb (before this patch it has "borked" status)
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #66 from Kolya [email protected] --- Sea Dogs: To Each His Own was created by the same team who created Age of Pirates - City of Abandoned Ships: Adventure Tales and uses the same old engine
https://bugs.winehq.org/show_bug.cgi?id=27439
Gijs Vermeulen [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |49370
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #67 from Gijs Vermeulen [email protected] --- Still present with wine-5.12-197-gfdb3d9ae32. The hack from Comment #43 still works.
https://bugs.winehq.org/show_bug.cgi?id=27439 Bug 27439 depends on bug 49370, which changed state.
Bug 49370 Summary: Sea Dogs: City of Abandoned Ships (GOG) installer silently exits https://bugs.winehq.org/show_bug.cgi?id=49370
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #68 from joaopa [email protected] --- Does the bug still occur with wine-7.0-rc4?
https://bugs.winehq.org/show_bug.cgi?id=27439
Gijs Vermeulen [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #57957|0 |1 is obsolete| |
--- Comment #69 from Gijs Vermeulen [email protected] --- Created attachment 71540 --> https://bugs.winehq.org/attachment.cgi?id=71540 Rebased hack
Yes, still present with wine-7.0rc4. The attached rebased hack still works around.
https://bugs.winehq.org/show_bug.cgi?id=27439
Gijs Vermeulen [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #71540|0 |1 is obsolete| |
--- Comment #70 from Gijs Vermeulen [email protected] --- Created attachment 71541 --> https://bugs.winehq.org/attachment.cgi?id=71541 Rebased hack
(In reply to Gijs Vermeulen from comment #69)
Created attachment 71540 [details] Rebased hack
Attaching correct hack now.
https://bugs.winehq.org/show_bug.cgi?id=27439
kenoi [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]. | |au
--- Comment #71 from kenoi [email protected] --- Can someone please attach their compiled wine3d.dll.so that has the patch applied, along with their Wine version, so we don't all have to learn to build Wine just to fix a long-standing bug with one game?
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #72 from kenoi [email protected] --- *wined3d.dll.so
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #73 from kenoi [email protected] --- Found a workaround for Caribbean Tales:
In <Game Directory>/Program/battle_interface/BattleInterface.c, on line 91, comment out this line by placing two forward slashes in front of it:
//LayerAddObject(SEA_REALIZE,&BattleInterface,-1);
It will disable the rendering of the ship's HUD while sailing, but it will allow you to sail freely and stop the game from crashing when you enter sea mode.
The crash is due to a bad rendering implementation (involving a heap corruption with DX8Render ReleaseVertexBuffer) in the module battle_interface.dll in this game.
https://bugs.winehq.org/show_bug.cgi?id=27439
Olivier F. R. Dierick [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #74 from Olivier F. R. Dierick [email protected] --- (In reply to kenoi from comment #73)
The crash is due to a bad rendering implementation (involving a heap corruption with DX8Render ReleaseVertexBuffer) in the module battle_interface.dll in this game.
Hello,
A DirectX apitrace might be useful.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #75 from kenoi [email protected] --- (In reply to Olivier F. R. Dierick from comment #74)
Hello,
A DirectX apitrace might be useful.
Regards.
Appreciate the input. The source code for the game's engine (the DLL files and executable) is not available, so even if I can trace the call and what's going on exactly, I can do nothing to change it. Unless this tracer has a way to intercept and block calls, it's not going to be very useful here.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #76 from Olivier F. R. Dierick [email protected] --- (In reply to kenoi from comment #75)
Appreciate the input. The source code for the game's engine (the DLL files and executable) is not available, so even if I can trace the call and what's going on exactly, I can do nothing to change it. Unless this tracer has a way to intercept and block calls, it's not going to be very useful here.
Hello,
That's not the purpose of the apitrace.
It's purpose is to allow people that don't own the game to reproduce/diagnose the bug.
Someone with the game uses it to record the sequence of DirectX 8 operations from the working game on Windows. The apitrace is then shared with devs.
The recorded sequence of DX8 calls can replayed on Wine to check if crashes the same way as the game, without having to own the actual game.
If the crash can be reproduced, then the dev can locate where in the sequence of DX8 operations, and try fixes until the apitrace can be replayed successfully.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #77 from kenoi [email protected] --- (In reply to Olivier F. R. Dierick from comment #76)
Someone with the game uses it to record the sequence of DirectX 8 operations from the working game on Windows. The apitrace is then shared with devs.
The recorded sequence of DX8 calls can replayed on Wine to check if crashes the same way as the game, without having to own the actual game.
If the crash can be reproduced, then the dev can locate where in the sequence of DX8 operations, and try fixes until the apitrace can be replayed successfully.
The problem is not with Wine or its implementation of DirectX 8 here. Wine is actually doing the right thing terminating the application. The problem is a serious one with the Storm engine that these games use, where the programming of the engine reaches past available memory.
Wine is right to crash the game -- because by all right this is terrible programming, and Wine shouldn't let the software continue with it. This is why this bug has not been fixed in many-many years.
The problem is that neither side will budge: the developer of the games hasn't updated the games in a long-long time (they're no longer active), and the Wine team will not implement something that is less than perfect (understandably).
The only difference between Wine and Windows here is that Windows lets the program continue even when such memory breaches occur. This is why these games crash far less on actual Windows than they do in Wine.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #78 from Austin English [email protected] --- (In reply to kenoi from comment #77)
The problem is that neither side will budge: the developer of the games hasn't updated the games in a long-long time (they're no longer active), and the Wine team will not implement something that is less than perfect (understandably).
I don't see any developers saying this is a wontfix, rather that it's hard to debug. Unfortunately there are a lot of bugs, and not all get attention when there are a limited number of people with the skills to fix them.
An apitrace would improve the odds of it being fixed, as it gives a developer a way to test without needing the game.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #79 from kenoi [email protected] --- So the solution to this bug is presented here:
https://bugs.winehq.org/attachment.cgi?id=71541&action=diff
But it's not something that will ever make it into an official build of Wine. And very few people know how to custom build Wine (myself excluded, I tried and failed).
https://bugs.winehq.org/show_bug.cgi?id=27439
Zeb Figura [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #80 from Zeb Figura [email protected] --- If it really is a matter of writing past mapped memory bounds, then an apitrace won't help.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #81 from kenoi [email protected] ---
I don't see any developers saying this is a wontfix, rather that it's hard to debug.
That's just it: there's nothing to fix. Not unless you want to make Wine as clunky and bogged down with memory management as Windows is. It would be regression for the sake of compatibility. Which I'm sure goes against the technical principles of the Wine team.
This is a compromise between game compatibility and Wine's performance.
The fix is actually needed on the game engine end -- but that's not going to happen anytime soon either. I submitted a report to GOG, hoping that their technical team maybe able to have a look at fixing it (if they happen to have the source to the DLLs).
Until the game engine is fixed, all we can do is either custom compile Wine and, preferably, provide a custom binary for Wine that is easy to download and apply and works with these games, or use the workaround I posted and compromise some of the game's gameplay for stability.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #82 from kenoi [email protected] --- Worth noting, though, that this bug is not exclusive to these games. It will happen with any Windows software that reaches past memory using DirectX in Wine. The software will not be allowed to continue, it will crash.
This is a major difference in how Wine and Windows work.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #83 from Austin English [email protected] --- (In reply to kenoi from comment #79)
But it's not something that will ever make it into an official build of Wine. And very few people know how to custom build Wine (myself excluded, I tried and failed).
Frankly, if you're not a developer (and especially if you're not able to build wine), then you shouldn't make declarative statements about what wine's development policies are.
Wine's policy is to match windows behavior, even if it's not ideal. I'm not a wined3d developer, so I'll leave it to them to decide if this is a WONTFIX.
https://bugs.winehq.org/show_bug.cgi?id=27439
Gijs Vermeulen [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|[email protected] |
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #84 from kenoi [email protected] --- (In reply to Austin English from comment #83)
Frankly, if you're not a developer (and especially if you're not able to build wine), then you shouldn't make declarative statements about what wine's development policies are.
Wine's policy is to match windows behavior, even if it's not ideal. I'm not a wined3d developer, so I'll leave it to them to decide if this is a WONTFIX.
With all due respect, I would call a bug that hasn't been fixed in 11 years a WONTFIX!
I may not be a Wine developer, but that doesn't mean I'm not a software developer, and can't see the larger problem here. Would you implement a "fix" to Wine that compromises Wine's memory management just so faulty software could run on Wine? That makes the Wine server slow down like Windows does with use?
It goes against what Linux and Wine stand for by design. This is why this bug has not been fixed in all this time.
I'm all for hope, but not rooted in ignorance, in closing my eyes and wishing for something that will never come. We need to deal with this bug in another way than waiting for the Wine developers to implement a patch that compromises Wine's performance. We need to provide a means to an easy solution for users to fix the Storm engine's compatibility with Wine, without needing to compile Wine from the source.
That fix will either come by fixing the serious faults in the Storm engine (if someone has access to the source), or by providing a binary that users can download and copy/install to fix Wine's compatibility with this engine (at the cost of Wine's memory performance) on their computer.
I stand for being practical, not hopeless wishful thinking.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #85 from Olivier F. R. Dierick [email protected] --- (In reply to Zeb Figura from comment #80)
If it really is a matter of writing past mapped memory bounds, then an apitrace won't help.
Hello,
What if the out of bound writing results from bad expectations of the game related to DX operations? Wouldn't it be useful to understand what the game was trying to do at the time of the crash?
I would still find apitraces usefull: One from the game working on Windows, to confirm that the apitrace is not affected by those memory access issues; One from the game not working on Wine, to locate what the game was trying to do with memory in the sequence of DX operations.
I don't have any of the affected games. There is nothing much I can do for this bug. Some comments suggest that the issue relates to the game DX rendering engine, so I thought that apitraces could be used to check that and I suggested that.
(In reply to kenoi from comment #84)
I stand for being practical, not hopeless wishful thinking.
Really? With all due respect, you've come to the Wine bug tracker to rant about your opinion that the bug should not be fixed by the Wine project. How is that practical? Isn't that just trolling? If you're so persuaded of being right and want to be practical just go start your own Storm Engine fixing project and stop wasting other people's time with a pointless debate.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #86 from Olivier F. R. Dierick [email protected] --- (In reply to Olivier F. R. Dierick from comment #85)
is that practical? Isn't that just trolling? If you're so persuaded of being
*conviced
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #87 from Zeb Figura [email protected] --- (In reply to Olivier F. R. Dierick from comment #85)
(In reply to Zeb Figura from comment #80)
If it really is a matter of writing past mapped memory bounds, then an apitrace won't help.
Hello,
What if the out of bound writing results from bad expectations of the game related to DX operations? Wouldn't it be useful to understand what the game was trying to do at the time of the crash?
I would still find apitraces usefull: One from the game working on Windows, to confirm that the apitrace is not affected by those memory access issues; One from the game not working on Wine, to locate what the game was trying to do with memory in the sequence of DX operations.
As I understand, apitrace only records memory within the bounds of the actual map. It won't actually tell us whether the application is writing outside of the map bounds on Windows; the actual trace should presumably succeed either way.
https://bugs.winehq.org/show_bug.cgi?id=27439
--- Comment #88 from kenoi [email protected] --- (In reply to Olivier F. R. Dierick from comment #85)
Really? With all due respect, you've come to the Wine bug tracker to rant about your opinion that the bug should not be fixed by the Wine project. How is that practical? Isn't that just trolling?
Excuse me?! I've provided two solutions and one workaround/fix to this problem already. How many have you provided?
I don't see how seeking a practical solution to the problem and looking to solve it constitutes as trolling. Maybe we have very different definitions of what constitutes as useful.
Also, I was not "ranting" about how the bug "should not" be fixed, but explaining why it hasn't been and why it won't be in Wine.
The fact stands that this bug/issue hasn't been solved in 11 years.
(And this sort of discriminating, elitist attitude/culture here is part of the reason why it hasn't been solved, to be honest. It creates a rift between users and the Wine developers, and discourages teamwork and participation in solving the problem.)
If you're so convinced of being right and want to be practical just go start your own Storm Engine fixing project and stop wasting other people's time with a pointless debate.
We both know that this is impossible, since the source code to the game engine is not available. If you have a personal problem with me, this is NOT the place to vent your frustrations. This place is for solving this issue/bug with the games on Wine.
Just because you don't agree with my personal perspective or the solutions I've provided doesn't give you the right to call me a troll and discriminate against my "opinions" or person. I have just as much a right to contribute to solving this problem as anyone else who has contributed to this discussion.
https://bugs.winehq.org/show_bug.cgi?id=27439
2857 [email protected] changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]
--- Comment #89 from 2857 [email protected] --- Hello good people,
I just wanted to mention that there actually IS an open source of the Storm Engine available: https://github.com/storm-devs/storm-engine
Though it's archived now, there are dozens of forks and I believe it should be possible to run this on Linux natively.