https://bugs.winehq.org/show_bug.cgi?id=45335
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEW
--- Comment #10 from Anastasius Focht focht@gmx.net --- Hello folks,
--- quote --- So is the path issue still relevant or what does this mean? --- quote ---
hard to tell. Although the internal debug/dev setting works around the true cause should be found as this works out of the box on Windows without any registry tweaks (OP didn't specify which path he used).
Since you've tested this earlier on some Windows VM:
--- quote --- Does it work when you download it and run it on a windows machine? It doesn't work on my VM, at least - gives me a Runtime-Error. --- quote ---
Could you try to put the app in some short path and re-check? Extract the .zip to 'C:\onevolumeviewer' or another drive (rename/remove top-level directory 'Andriy Pavlovych Kniazyuk_20180115171449.SL').
The working path length problem already makes me think there are multiple separate bugs present. Maybe there is a cascading-type bug where a partial/improper initialization of app data results in more issues that are normally hidden.
With the initial opengl crash I've managed to get something usable by debugging with native (winedbg backtrace is not usable, stack/frame corruption).
--- snip --- Wine-gdb> bt #0 osmesa_st_framebuffer_flush_front (stctx=0x7bd8b350, stfbi=0x7bd92720, statt=ST_ATTACHMENT_FRONT_LEFT) at osmesa.c:311 #1 0x7a2b1763 in st_manager_flush_frontbuffer (st=0x7bd8b350) at state_tracker/st_manager.c:1097 #2 0x7a28092c in st_glFinish (ctx=0x7aa66750) at state_tracker/st_cb_flush.c:106 #3 0x7a0c6c34 in _mesa_Finish () at main/context.c:1863 #4 0x7a8b10ab in glFinish () at /home/focht/projects/wine/mainline-src/dlls/opengl32/opengl_norm.c:638 #5 0x10052513 in ?? () #6 0x1004f90b in ?? () #7 0x1007b4ec in ?? () #8 0xff6af8e4 in ?? () #9 0x00000000 in ?? ()
Wine-gdb> si 0x7a516c6d in osmesa_st_framebuffer_flush_front (stctx=0x7bd8b350, stfbi=0x7bd92720, statt=ST_ATTACHMENT_FRONT_LEFT) at osmesa.c:345 345 in osmesa.c
Wine-gdb> si 0x7a516d2a 368 in osmesa.c Wine-gdb> si memcpy (__len=4, __src=0x67177280, __dest=0x2600000) at /usr/include/bits/string_fortified.h:34 warning: Source file is more recent than executable. 34 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); --- snip ---
Essentially the user provided image buffer memory (0x2600000) is no longer valid here. The app has multiple threads that do GL calls. Each thread uses 'wglMakeCurrent' to bind its context to the mapped buffer(s) (represented by DIB).
It seems there is a cross-thread passing of DIBs. One thread passes the pixel buffer from a DIB to some engine thread which in turn passes the buffer to GL using 'wglMakeCurrent'. It makes a rather long sequence of GL calls between 'wglMakeCurrent' and 'glFinish'. One of the threads re-creates DIBs while destroying old ones, leading to underlying pixel buffer of DIB being freed. At the point of 'glFinish' which ought to flush the front buffer, the mapped memory location is gone (DIB pixel buffer freed), causing 'memcpy' to page fault. Not sure yet where the problem is. There is also a skinning library 'XTPSkinManager' (Xtreme ToolkitPro) involved which hooks several API, including GDI32 ones. It could be another source of problems here.
Regards