http://bugs.winehq.org/show_bug.cgi?id=21618
Summary: EVE Online: Crashes when generating certain images Product: Wine Version: 1.1.38 Platform: x86 URL: http://www.eveonline.com OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: phoenix@mail.ru
Created an attachment (id=26088) --> (http://bugs.winehq.org/attachment.cgi?id=26088) Profile of the system which experienced crash
Wine 1.1.38 introduced a regression: it crashes when images are generated from models. This includes: 1) Icons which are shown when you locked anything (i crashed when locked Hawk Assault Frigate multiple times, then moved to test server and locked there station in Ned solar system): repro rate for listed objects was 100% 2) When clicking objects, eve also generates image and shows it in selected object pane (by default above overview pane). Although it crashed several times, repro rate was far from 100% Character image generation on login screen was smooth, no crashes at all.
Following commit was tracked down using bisect:
224043d6cf8b56e9ff2537358646700211d54d1f is the first bad commit commit 224043d6cf8b56e9ff2537358646700211d54d1f Author: Stefan Dösinger stefan@codeweavers.com Date: Thu Jan 28 20:51:06 2010 +0100
wined3d: Implement dynamic buffers with GL_ARB_map_buffer_range.
:040000 040000 1f55d5e837f1d9a7d2b4611f2de3e02dbcd8fafe c189de355870e1812adce96432f42a16967e2b2c M dlls
System specs are attached.
http://bugs.winehq.org/show_bug.cgi?id=21618
Anton Vorobyov phoenix@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #1 from Anton Vorobyov phoenix@mail.ru 2010-02-06 14:45:49 --- Adding stefan to CC list
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #2 from Anton Vorobyov phoenix@mail.ru 2010-02-06 14:52:42 --- Forgot to mention that you'll need to clean cache to make sure that image isn't pre-generated with earlier wine verions
http://bugs.winehq.org/show_bug.cgi?id=21618
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression
--- Comment #3 from Nikolay Sivov bunglehead@gmail.com 2010-02-06 14:57:33 --- Did you verify by reverting this commit?
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #4 from Anton Vorobyov phoenix@mail.ru 2010-02-06 15:22:10 --- (In reply to comment #3)
Did you verify by reverting this commit?
Yes, just finished compiling. No crashes, but images are replaced by solid black color.
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #5 from Anton Vorobyov phoenix@mail.ru 2010-02-06 15:31:55 --- Forgot to paste yet another important thingy - stderr message: --- wine: Unhandled page fault on read access to 0x00000000 at address 0x40ffbac (thread 0046), starting debugger...
http://bugs.winehq.org/show_bug.cgi?id=21618
olanys@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #6 from olanys@gmail.com 2010-02-06 16:23:17 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #7 from Austin English austinenglish@gmail.com 2010-02-06 16:50:14 --- (In reply to comment #5)
Forgot to paste yet another important thingy - stderr message:
wine: Unhandled page fault on read access to 0x00000000 at address 0x40ffbac (thread 0046), starting debugger...
Please attach _full_ output.
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #8 from Anton Vorobyov phoenix@mail.ru 2010-02-06 17:34:21 --- darkphoenix@Kreo:~/src/wine$ ./wine explorer /desktop=EVE,1280x800 "C:\Program Files\CCP\EVE (Singularity)\eve.exe" /server:singularity err:ole:CoGetClassObject class {9a5ea990-3034-4d6f-9128-01f3c61022bc} not registered err:ole:CoGetClassObject no class object {9a5ea990-3034-4d6f-9128-01f3c61022bc} could be created for context 0x1 fixme:heap:HeapSetInformation 0x8d9000 0 0x33fc6c 4 fixme:win:EnumDisplayDevicesW ((null),0,0x338ea0,0x00000000), stub! fixme:wtsapi:WTSRegisterSessionNotification Stub 0x3005a 0x00000000 fixme:imm:ImmDisableTextFrameService Stub fixme:imm:ImmReleaseContext (0x3005a, 0x15fae8): stub fixme:reg:GetNativeSystemInfo (0x33b718) using GetSystemInfo() fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #17: fixme:d3d_shader:print_glsl_info_log Vertex info fixme:d3d_shader:print_glsl_info_log ----------- fixme:d3d_shader:print_glsl_info_log warning: no vertex attribute is explicitly assigned to vertex attribute zero fixme:imm:NotifyIME NI_CLOSECANDIDATE fixme:d3d_draw:drawPrimitive Using software emulation because not all material properties could be tracked fixme:d3d:buffer_PreLoad Too many full buffer conversions, stopping converting fixme:imm:NotifyIME NI_CLOSECANDIDATE fixme:imm:NotifyIME NI_CLOSECANDIDATE fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0x14e3e100) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0x14e3e100) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0x14e3e1b8) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0x14e3e1b8) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0x14e3e270) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0x14e3e270) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0x14e3e308) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0x14e3e308) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0x14e3f3c8) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0x14e3f3c8) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0x14e3f888) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0x14e3f888) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0x14e3fa68) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0x14e3fa68) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0x14e3fb88) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0x14e3fb88) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0x14e3fc78) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0xfa971f0) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0xfa971f0) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0xfa972a8) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0xfa972a8) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0xf8f3bb0) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0xf8f3bb0) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0xf8f3c48) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0xf8f3c48) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0xf8f3ce0) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0xf8f3ce0) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0xf8f41a0) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0xf8f41a0) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0xfa984b0) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0xfa984b0) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0xfa985d0) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0xfa985d0) : pBox=(nil) stub fixme:d3d_surface:IWineD3DVolumeImpl_LockBox (0xfa986c0) : pBox=(nil) stub wine: Unhandled page fault on read access to 0x00000000 at address 0x40ffbac (thread 0021), starting debugger...
http://bugs.winehq.org/show_bug.cgi?id=21618
evanh evanh@clear.net.nz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |evanh@clear.net.nz
--- Comment #9 from evanh evanh@clear.net.nz 2010-02-06 21:22:23 --- Seems to be just ship icons for me. I get the black box on a show info and the crash occurs on target lock.
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #10 from evanh evanh@clear.net.nz 2010-02-07 01:20:41 --- Correction. Doesn't affect pilot info renders at all. But items and structures and ships selected in space or show info or in market listing all turn to black.
The crash is exclusive to the targeting function.
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #11 from evanh evanh@clear.net.nz 2010-02-07 03:17:29 --- More info: I can target an asteroid or canister with no crash. Neither have the black box icon, they appear to use a fixed icon that is not rendered like the rest.
http://bugs.winehq.org/show_bug.cgi?id=21618
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at
--- Comment #12 from Stefan Dösinger stefandoesinger@gmx.at 2010-02-07 09:04:44 --- can you check if glMapBufferRange in buffer.c, buffer_map() is returning NULL? A +d3d log and the glxinfo output would be helpful as well.
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #13 from Anton Vorobyov phoenix@mail.ru 2010-02-07 15:04:49 --- Created an attachment (id=26116) --> (http://bugs.winehq.org/attachment.cgi?id=26116) glxinfo output
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #14 from Anton Vorobyov phoenix@mail.ru 2010-02-07 15:12:27 --- Log is really huge, please tell me how to filter out unnecessary information if you don't neel all 800+ mb
As even compressed it exceeds 1mb i uploaded it to external FTP:
http://darkfenx.pochta.ru/tmp/wine_wd3d.7z
http://bugs.winehq.org/show_bug.cgi?id=21618
Karsten Elfenbein kelfe@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kelfe@gmx.de
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #15 from Anton Vorobyov phoenix@mail.ru 2010-02-07 15:16:01 --- (In reply to comment #12)
can you check if glMapBufferRange in buffer.c, buffer_map() is returning NULL?
I tried printing it right before that line, but such approach seems to be not very useful as eve crashes on startup:
printf("This is value returned by glMapBufferRange: %f\n", GL_EXTCALL(glMapBufferRange(This->buffer_type_hint, 0, This->resource.size, mapflags)));
I'm not a pro a c programming so don't have any other ideas how to check it.
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #16 from Stefan Dösinger stefandoesinger@gmx.at 2010-02-07 16:02:13 --- Created an attachment (id=26117) --> (http://bugs.winehq.org/attachment.cgi?id=26117) patch to debug the mapBufferRange address
Try the attached patch. It will print the address.
I tried to download your log, but I got a 404 error. I think the last 50(uncompressed) MB should be enough, and they should shrink to a bugzilla-uploadable size when you compress them with any compression program.
fyi: lrzip is a compression tool for logfiles, and achieves excellent results, although compression takes ages and consumes lots of memory. No need to use it though if you can compress the last 50 MBs well enough with gzip, bzip2 or others.
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #17 from Stefan Dösinger stefandoesinger@gmx.at 2010-02-07 16:14:24 --- Okay, now the download succeeded, and I found this in the logs:
trace:d3d:buffer_Map Returning memory at (nil) (base (nil), offset 0)
Which happens after a D3DLOCK_READONLY lock. I'll attach another debug patch. Can you give that a try and watch the err output? No special log flags required.
http://bugs.winehq.org/show_bug.cgi?id=21618
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #26117|0 |1 is obsolete| |
--- Comment #18 from Stefan Dösinger stefandoesinger@gmx.at 2010-02-07 16:19:05 --- Created an attachment (id=26118) --> (http://bugs.winehq.org/attachment.cgi?id=26118) 2nd debug patch
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #19 from Stefan Dösinger stefandoesinger@gmx.at 2010-02-07 16:26:23 --- I can imagine what the driver is complaining about: We're passing GL_MAP_READ_BIT | GL_MAP_FLUSH_EXPLICIT_BIT as map flags when the app passes D3DLOCK_READONLY, but flushing doesn't make much sense when you're not writing to the buffer.
The GL extension is pretty specific about this:
http://www.opengl.org/registry/specs/ARB/map_buffer_range.txt
MAP_FLUSH_EXPLICIT_BIT indicates that one or ... This flag may only be used in conjunction with MAP_WRITE_BIT
We do have a d3d test testing READONLY maps, but it only checks the D3D return value, and does not try to access the memory returned, so it doesn't catch the bug. Apparently there is no GL error raised, or I missed it in my testing, although the extension spec mandates that GL_INVALID_OPERATION shall be raised. There's a checkGLcall missing, but later checkGLcall calls should pick up the error.
Still, before I build a patch I'll wait for your test results with my earlier debug patch.
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #20 from Anton Vorobyov phoenix@mail.ru 2010-02-07 16:57:17 --- Created an attachment (id=26119) --> (http://bugs.winehq.org/attachment.cgi?id=26119) log generated with debug patch #2
Here's the log. I can't crash eve with this patch applied, it just shows black image (like after reverting commit) without any crashes.
http://bugs.winehq.org/show_bug.cgi?id=21618
octavian.voicu@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |octavian.voicu@gmail.com
--- Comment #21 from octavian.voicu@gmail.com 2010-02-07 17:30:55 --- Here's from Anton's log:
... err:d3d:buffer_Map Buffer map failed. Flags 00000011, size 1779240, buffer 19, type 00008892 fixme:d3d:buffer_Map >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from the failed buffer map @ buffer.c / 1120 err:d3d:buffer_Map Read write map succeeded fixme:d3d:buffer_Map Address returned by glMapBufferRange: 0xb0cff008 fixme:d3d:buffer_Unmap >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glFlushMappedBufferRange @ buffer.c / 1199 ...
This buffer_Map / buffer_Unmap sequence repeats 5 times in the log.
So the patch worked for buffer_Map, but I believe it needs to do the same thing for buffer_Unmap to prevent a memory leak. Hope this speeds things up a bit :)
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #22 from Stefan Dösinger stefandoesinger@gmx.at 2010-02-08 03:56:41 --- the gl unmap works just fine, its the manual flushing that doesn't work - because the 2nd map try(that finally works) is done without GL_MAP_FLUSH_EXPLICIT_BIT. The error doesn't cause any troubles, but still my debug patch is not the right way to fix it.
The proper thing to do is (a) not to record dirty areas when doing readonly maps, and (b) not to pass GL_MAP_FLUSH_EXPLICIT_BIT when doing readonly maps. That should fix both the crash and the unmap errors. I'll attach a patch later.
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #23 from Anton Vorobyov phoenix@mail.ru 2010-02-08 09:27:58 --- (In reply to comment #21)
This buffer_Map / buffer_Unmap sequence repeats 5 times in the log.
iirc I locked exactly 5 targets
http://bugs.winehq.org/show_bug.cgi?id=21618
Brian Bourke-Martin brianbourke75@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brianbourke75@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #24 from Stefan Dösinger stefandoesinger@gmx.at 2010-02-08 09:58:34 --- I sent 3 patches to wine-patches earlier today that should fix this bug.
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #25 from Anton Vorobyov phoenix@mail.ru 2010-02-08 12:59:56 --- I don't see any your commits among approved by wine maintainers today, so gonna check as soon as they arrive.
http://bugs.winehq.org/show_bug.cgi?id=21618
Brian execrable@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |execrable@gmail.com
--- Comment #26 from Brian execrable@gmail.com 2010-02-08 16:35:26 --- I just tried the latest git build, which appears to have Stefan's patches, and It still crashed as soon as I opened my assets tab and it tried to generate a ship icon.
I built it on ubuntu 9.10 x64, and had to use --without-mpg123, as it generates link errors on 64-bit *buntu.
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #27 from Stefan Dösinger stefandoesinger@gmx.at 2010-02-09 01:58:20 --- my patches aren't in yet: http://source.winehq.org/patches/
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #28 from Anton Vorobyov phoenix@mail.ru 2010-02-09 16:37:05 --- With these patches, crashes do not occur, but images are still not rendered (solid black square). Do you prefer me to create new bug entry on that or add info here?
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #29 from Brian execrable@gmail.com 2010-02-09 22:01:58 --- Stefan: Oh, I was looking at your other patches (58257-58259), which are the ones that apply to this bug? 57770-57773?
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #30 from Anton Vorobyov phoenix@mail.ru 2010-02-10 00:18:24 --- (In reply to comment #29)
Stefan: Oh, I was looking at your other patches (58257-58259), which are the ones that apply to this bug? 57770-57773?
His patches were in git as of yesterday
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #31 from Brian execrable@gmail.com 2010-02-10 01:06:36 --- (In reply to comment #30)
(In reply to comment #29)
Stefan: Oh, I was looking at your other patches (58257-58259), which are the ones that apply to this bug? 57770-57773?
His patches were in git as of yesterday
Right, nevermind, I was confused and looking at two different lists of patches.. at different times.
I updated my git checkout and with Stefan's patches it no longer crashes, and I even get ship Icons when I check the ships tab.
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #32 from Stefan Dösinger stefandoesinger@gmx.at 2010-02-10 08:06:47 --- So can we resolve the bug as fixed?
http://bugs.winehq.org/show_bug.cgi?id=21618
Anton Vorobyov phoenix@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #33 from Anton Vorobyov phoenix@mail.ru 2010-02-10 15:00:30 --- I guess yes. I'll open separate bug if any bugs with rendering still exist in current git.
http://bugs.winehq.org/show_bug.cgi?id=21618
--- Comment #34 from evanh evanh@clear.net.nz 2010-02-11 18:47:22 --- One report on the Eve forum of git code still producing black icons.
It looks like there is an open bug for it already - http://bugs.winehq.org/show_bug.cgi?id=21608
http://bugs.winehq.org/show_bug.cgi?id=21618
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #35 from Alexandre Julliard julliard@winehq.org 2010-02-19 12:32:29 --- Closing bugs fixed in 1.1.39.
-
wine-bugs＠winehq.org