[Bug 46716] New: utherverse client : crash when loading and installing
https://bugs.winehq.org/show_bug.cgi?id=46716 Bug ID: 46716 Summary: utherverse client : crash when loading and installing Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: www.max87(a)yahoo.fr Distribution: --- Created attachment 63684 --> https://bugs.winehq.org/attachment.cgi?id=63684 report generate by wine on the crash When i lunch the application client Uhterverse i got a bug report from wine and the loading of the client is stopped I tryed a reinstall of the client and it done the same a bug appared but the installation finished -- 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.
https://bugs.winehq.org/show_bug.cgi?id=46716 --- Comment #1 from Nikolay Sivov <bunglehead(a)gmail.com> --- Is there a public trial version of this application that I can test? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=46716 Louis Lenders <xerox.xerox2000x(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xerox.xerox2000x(a)gmail.com --- Comment #2 from Louis Lenders <xerox.xerox2000x(a)gmail.com> --- (In reply to Nikolay Sivov from comment #1)
Is there a public trial version of this application that I can test?
https://www.utherverse.com/download/?trq=creep3ddlbutton I can confirm the bug the app ships it`s own xmllite and when set to native the crash is gone -- 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.
https://bugs.winehq.org/show_bug.cgi?id=46716 Louis Lenders <xerox.xerox2000x(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://www.utherverse.com/ | |download/?trq=creep3ddlbutt | |on Status|UNCONFIRMED |NEW Keywords| |download Ever confirmed|0 |1 --- Comment #3 from Louis Lenders <xerox.xerox2000x(a)gmail.com> --- confirming the crash -- 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.
https://bugs.winehq.org/show_bug.cgi?id=46716 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |4.0 Component|-unknown |xmllite --- Comment #4 from Nikolay Sivov <bunglehead(a)gmail.com> --- This is related to UTF-16 input handling I think, after some fixing crashes stopped, but it still fails to read the stream correctly. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=46716 Anastasius Focht <focht@gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|utherverse client : crash |Multiple applications crash |when loading and installing |or hang with UTF-16 XML > 8 | |KiB in builtin xmllite | |(Utherverse client, cdb | |10.0.17763) CC| |focht@gmx.net URL|https://www.utherverse.com/ |https://web.archive.org/web |download/?trq=creep3ddlbutt |/20190217102119id_/https:// |on |www.utherverse.com/GetDownl | |oad.ashx?did=1390 --- Comment #5 from Anastasius Focht <focht@gmx.net> --- Hello folks, confirming. I found this bug while revisiting the Windows 10 SDK 10.0.17763 tools (bug 50230 and friends): 'cdb' from Debugging Tools for Windows 10.0.17763 hangs on startup. It seems to be the same underlying issue: builtin xmllite doesn't consume its raw input buffer for UTF-16 streams. I also found a stable link from archive.org of OP's app, the offline installer from one week before the report: https://web.archive.org/web/20190217102119id_/https://www.utherverse.com/Get... $ sha1sum VWWSetup.exe c42cc828c744b0d574a4ec1f5c0703cb60ae39f4 VWWSetup.exe $ sha256sum VWWSetup.exe 07eed67a1ddd1354497a6763ed89bf3e9276b7d919c3cef18a05098c5fadb8f8 VWWSetup.exe It still ships its own 'xmllite.dll', hence 'native' works around it (comment #2). Unfortunately neither this client nor the current one from the vendor gets far enough nowadays to reach the original crash site (server side changed, client crashes earlier for unrelated reasons). The backtrace from comment #0 matches though: the faulting memcpy() copies exactly one raw chunk (0x1ffc = 8188 bytes) to a destination computed from the doubled 'written' marker of the UTF-16 buffer. The cdb case is easy to reproduce. Use a trivial crashing test program, cdb needs native debug engine DLLs (builtin dbgeng is a stub): --- snip --- $ WINEDEBUG=+xmllite,+process WINEDLLOVERRIDES="dbgeng,dbghelp,dbgcore,dbgmodel=n" \ wine ./cdb.exe -g -G -c ".ecxr;kn;q" crash.exe ... CommandLine: crash.exe ... 017c:trace:process:CreateProcessInternalW started process pid 01b0 tid 01b4 ... 017c:trace:xmllite:readerinput_growraw written=0, alloc=8192, requested=8188, read=8188, ret=0 017c:trace:xmllite:reader_parse_nextnode detected encoding L"UTF-16", 0. 017c:trace:xmllite:readerinput_switchencoding switching to cp 1200 017c:trace:xmllite:reader_parse_qname ncname L"AutoVisualizer" ... 017c:trace:xmllite:reader_parse_comment L"MFVideoFormat_RGB32" ... 017c:trace:xmllite:readerinput_growraw written=8188, alloc=8192, requested=0, read=0, ret=0 ... 017c:trace:xmllite:reader_parse_comment L"MFVideoFormat_RGB32" ... --- snip --- The debuggee is created but cdb never processes the initial debug event. Its main thread spins in dbgeng parsing 'Visualizers\Windows.Media.natvis' (20737 bytes, handed to xmllite as UTF-16). The same comment is parsed over and over again until the process is killed. Every reader_more() call appends the whole raw buffer again to the UTF-16 buffer since the raw buffer is never shrunk. Once it's full (written=8188, alloc=8192) readerinput_growraw() requests 0 bytes and never grows it. UTF-8 input is fine. Commit https://gitlab.winehq.org/wine/wine/-/commit/a49a2abff103193fae9cc26ebca2d69... ("xmllite/reader: Use correct byte length when updating utf16 buffer contents marker.") fixed the crash part in Wine 7.13 but the raw buffer handling for the UTF-16 case still lacks the counterpart of the MultiByte path. The UTF-16 branch of reader_more() never had the readerinput_shrinkraw() call the MultiByte branch has. https://gitlab.winehq.org/wine/wine/-/blob/59416cf58482d97371d17207ddbfd4d6c... --- snip --- 1063 static HRESULT reader_more(xmlreader *reader) 1064 { ... 1080 /* just copy for UTF-16 case */ 1081 if (cp == 1200) 1082 { 1083 readerinput_grow(readerinput, len); 1084 memcpy(dest->data + dest->written, src->data + src->cur, len); 1085 dest->written += len; 1086 } 1087 else 1088 { ... 1095 /* get rid of processed data */ 1096 readerinput_shrinkraw(readerinput, len); 1097 } --- snip --- Maybe readerinput_shrinkraw() should be done in the UTF-16 case as well? With that change, cdb works: it starts the debuggee, stops at the access violation and shows the stack. $ wine --version wine-11.19-91-g59416cf5848 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.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla