[Bug 45335] Morita i-Dixel CT imaging software 'OneVolumeViewer' crashes when opening volume files (broken application, working directory must be short path)

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=45335

Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW

--- Comment #10 from Anastasius Focht <focht at 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

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.