http://bugs.winehq.org/show_bug.cgi?id=26016
Summary: xmllite installer crashes about 1 in 30 runs Product: Wine Version: 1.3.13 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: dank@kegel.com
While running the regression test for winetricks-alpha, I noticed that installing xmllite crashed like this:
fixme:wintrust:CryptCATGetCatAttrInfo 0x13e700, L"SPLevel" wine: Unhandled page fault on read access to 0xffffffff at address 0x68a4875f (thread 0013), starting debugger... Backtrace: =>0 0x68a4875f SetupCommitFileQueueW+0x3cf(owner=(nil), handle=0x1414f0, handler=0x68a49040, context=0x33bcdc) [include/wine/unicode.h:200] in setupapi (0x0033bcec) 1 0x68a49031 SetupCommitFileQueueA+0x40(owner=(nil), queue=0x1414f0, handler=0x103be4b, context=0x33c228) [dlls/setupapi/queue.c:879] in setupapi (0x0033f384) 0x68a4875f SetupCommitFileQueueW+0x3cf [include/wine/unicode.h:200] in setupapi: cmpw $0,0x0(%edx)
I ran the installer in a loop to try to reproduce, and on the 34th run, I got a different crash at about the same place:
fixme:wintrust:CryptCATGetCatAttrInfo 0x1c8ba8, L"SPLevel" err:setupapi:SetupDefaultQueueCallbackA copy error 3 "c:\e64013c352a7bbb4a28da0908ecc09\SP2QFE\xmllite.dll" -> "c:\windows\$hf_mig$\KB915865\SP2QFE\xmllite.dll" fixme:setupapi:pSetupGetGlobalFlags stub fixme:setupapi:pSetupGetGlobalFlags stub wine: Unhandled page fault on read access to 0xffffffff at address 0x68c72252 (thread 003f), starting debugger... Backtrace: =>0 0x68c72252 StringTableDestroy+0x42(hStringTable=0x13ed98) [dlls/setupapi/stringtable.c:177] in setupapi (0x0033f384) 0x68c72252 StringTableDestroy+0x42 [dlls/setupapi/stringtable.c:177] in setupapi: movl 0x0(%edx,%edi,1),%edx
I ran it again in a loop with WINEDEBUG=warn+heap,+setupapi, and on the 28th, 111th, and 114th runs, saw the error:
... fixme:advapi:RegisterEventSourceW (L"",L"NtServicePack"): stub fixme:advapi:ReportEventA (0xcafe4242,0x0004,0x0000,0x400e1119,0x120df8,0x0002,0x00000000,0x34bcb8,(nil)): stub fixme:advapi:ReportEventW (0xcafe4242,0x0004,0x0000,0x400e1119,0x120df8,0x0002,0x00000000,0x118f90,(nil)): stub fixme:advapi:DeregisterEventSource (0xcafe4242) stub err:heap:HEAP_ValidateInUseArena Heap 0x110000: block 0x137420 tail overwritten at 0x137430 (byte 0/32 == 0xff) 28
http://bugs.winehq.org/show_bug.cgi?id=26016
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, Installer
http://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #1 from Dan Kegel dank@kegel.com 2011-02-09 08:38:02 CST --- I'm starting to see a StringTableDestroy crash while installing ie8, too, rather more reliably.
http://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #2 from Dan Kegel dank@kegel.com 2013-06-16 18:50:41 CDT --- Saw the StringTableDestroy crash again with wine-1.6-rc1.
http://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #3 from Dan Kegel dank@kegel.com 2013-07-23 08:52:24 CDT --- The StringTableDestroy crash mappened again on third run of ie7 installer without WINEDEBUG=warn+heap, on wine-1.6.
http://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #4 from Nikolay Sivov bunglehead@gmail.com 2013-07-23 10:01:22 CDT --- String table should be implemented as a real handle table, that was quick test shows. I'll take a look if I can make a draft patch for that.
http://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #5 from Dan Kegel dank@kegel.com 2013-07-23 11:48:18 CDT --- Without WINEDEBUG=warn+heap, I see a crash (usually a heap corruption crash) with StringTableDestroy in the stack trace in 28 out of 150 runs (and some other crash in 9 out of the 150 runs).
With WINEDEBUG=warn+heap, I see only two crashes out of 54 runs, both in SetupFindFirstLineW.
I opened bug 34120 for the heap corruption before your reply. Looking forward to your patch.
http://bugs.winehq.org/show_bug.cgi?id=26016
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #6 from Nikolay Sivov bunglehead@gmail.com 2013-07-24 03:12:43 CDT --- Actually I was wrong. It was a way heap allocation works that confused me, actually table are allocated on heap and are plain pointers, not handles of any kind. I was able to figure out basic structure of it:
--- struct stringtable { void *data; /* pointer to actual string data */ DWORD offset; /* offset where data actually starts */ DWORD allocated; /* allocated byte size 'data' points to */ DWORD unk[3]; LCID lcid; /* thread LCID, it's store on allocation and probably used to compare */ } ---
Returned string ids are offsets from 'data' pointer to actual string data. I didn't try to see what happens with extra data.
So unless there's an indication that installer uses internal structure for something it looks like a general heap corruption.
http://bugs.winehq.org/show_bug.cgi?id=26016
Qian Hong fracting@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #7 from Austin English austinenglish@gmail.com --- Created attachment 47907 --> https://bugs.winehq.org/attachment.cgi?id=47907 backtrace in git
Still in wine-1.7.15-107-gf3488d0. On my gentoo machine, it's crashing in crypt32 (Jacek's changes from a few months ago):
Backtrace: =>0 0x7e98e933 Context_AddRef+0x33(context=0x1848e0) [/home/austin/wine-git/dlls/crypt32/context.c:86] in crypt32 (0x0033ae98) 1 0x7e9cac85 MemStore_enumContext+0x54(store=<is not available>, list=0x139768, prev=0x1bb120) [/home/austin/wine-git/dlls/crypt32/store.c:197] in crypt32 (0x0033aeb8) 2 0x7e9c2c7d ProvStore_enumCert+0x1c(store=0x1adf58, prev=0x1bb120) [/home/austin/wine-git/dlls/crypt32/provstore.c:114] in crypt32 (0x0033aed8) 3 0x7e98d796 CRYPT_CollectionAdvanceEnum+0x65(store=<is not available>, storeEntry=0x1394b0, contextFuncs=0x7e9edd10, prev=0x14d060) [/home/austin/wine-git/dlls/crypt32/collectionstore.c:165] in crypt32 (0x0033af28) 4 0x7e98dbb3 Collection_enumCert+0x52(store=0x139390, prev=0x14d060) [/home/austin/wine-git/dlls/crypt32/collectionstore.c:237] in crypt32 (0x0033af68) 5 0x7e98d796 CRYPT_CollectionAdvanceEnum+0x65(store=<is not available>, storeEntry=0x148178, contextFuncs=0x7e9ecab0, prev=0x199d18) [/home/austin/wine-git/dlls/crypt32/collectionstore.c:165] in crypt32 (0x0033afb8) 6 0x7e98dbb3 Collection_enumCert+0x52(store=0x1d1e68, prev=0x199d18) [/home/austin/wine-git/dlls/crypt32/collectionstore.c:237] in crypt32 (0x0033aff8) 7 0x7e98d796 CRYPT_CollectionAdvanceEnum+0x65(store=<is not available>, storeEntry=0x14cc98, contextFuncs=0x7e9ecab0, prev=0x14d028) [/home/austin/wine-git/dlls/crypt32/collectionstore.c:165] in crypt32 (0x0033b048) 8 0x7e98dbb3 Collection_enumCert+0x52(store=0x14cc58, prev=0x14d028) [/home/austin/wine-git/dlls/crypt32/collectionstore.c:237] in crypt32 (0x0033b088) 9 0x7e9c9e95 CertEnumCertificatesInStore+0x54(hCertStore=0x14cc58, pPrev=0x14d044) [/home/austin/wine-git/dlls/crypt32/store.c:946] in crypt32 (0x0033b0c8) 10 0x7e97edec CertFindCertificateInStore+0x14b(hCertStore=<couldn't compute location>, dwCertEncodingType=<couldn't compute location>, dwFlags=<couldn't compute location>, dwType=<couldn't compute location>, pvPara=<couldn't compute location>, pPrevCer
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #8 from Anastasius Focht focht@gmx.net --- *** Bug 34120 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #9 from Austin English austinenglish@gmail.com --- *** Bug 34119 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #10 from Austin English austinenglish@gmail.com --- Created attachment 47916 --> https://bugs.winehq.org/attachment.cgi?id=47916 setupapi: use a private heap
This seems to work for me, in initial testing (500 runs of xmllite without issue).
Going for a longer pass, and trying with warn+heap and ie7 as well.
https://bugs.winehq.org/show_bug.cgi?id=26016
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |arethusa26@gmail.com
--- Comment #11 from Austin English austinenglish@gmail.com --- *** Bug 23232 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #12 from Nikolay Sivov bunglehead@gmail.com --- (In reply to Austin English from comment #10)
Created attachment 47916 [details] setupapi: use a private heap
Another reason why heap_alloc/heap_free helpers could be useful to easily switch heaps.
https://bugs.winehq.org/show_bug.cgi?id=26016
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net Summary|xmllite installer crashes |Multiple Microsoft |about 1 in 30 runs |installers crash with heap | |corruption (private heap | |for StringTableXXX | |allocation wrapper in | |setupapi needed)(XmlLite, | |XPSEP, IE7)
--- Comment #13 from Anastasius Focht focht@gmx.net --- Hello folks,
merging bug 32554 also here.
I had some discussion on IRC yesterday where I guessed this might be the same issue as bug 32554 (and others), suggesting use of private heap.
See http://bugs.winehq.org/show_bug.cgi?id=32554#c15 (private heap for StringTableXXX allocator).
Actually I thought you would only change the allocation wrapper 'MyMalloc', 'MyFree' (used for StringTableXXX API) to make use of private heap, which helped me in other setupapi/corruption bugs.
Austin your patch changes every HeapAlloc/HeapFree() in setupapi which I find a bit too invasive. I think having only the existing wrapper use the private heap might be the better option. It's also easier later to figure out what's really going on.
Can you re-test a less invasive version?
Regards
https://bugs.winehq.org/show_bug.cgi?id=26016
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |timoteo@unimed-agm.com.br
--- Comment #14 from Anastasius Focht focht@gmx.net --- *** Bug 32554 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #15 from Austin English austinenglish@gmail.com --- Created attachment 47918 --> https://bugs.winehq.org/attachment.cgi?id=47918 setupapi: use a private heap (try 2)
Sure. Here you go.
https://bugs.winehq.org/show_bug.cgi?id=26016
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #47916|0 |1 is obsolete| |
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #16 from Austin English austinenglish@gmail.com --- (In reply to Austin English from comment #15)
Created attachment 47918 [details] setupapi: use a private heap (try 2)
Sure. Here you go.
That crashes for both ie7 and xmllite pretty quickly (41/35). I'll play around with it.
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #17 from Anastasius Focht focht@gmx.net --- Hello Austin,
--- quote --- That crashes for both ie7 and xmllite pretty quickly (41/35). I'll play around with it. --- quote ---
hmm, dang .. maybe it's useful to introduce another set of 'MyXXX' helpers which uses a private heap to track down the problem (selectively replace HeapAlloc/HeapFree calls with that). Installer setupapi usage needs to be analysed to figure out what class of API might cause the problem here.
Regards
https://bugs.winehq.org/show_bug.cgi?id=26016
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |imwellcushtymelike@gmail.co | |m Blocks| |34217
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #18 from Austin English austinenglish@gmail.com --- @Focht, I've noticed even with all Heap calls changed, that I occasionally get deadlocks: + grep err:ntdll:RtlpWaitForCriticalSection ie7-git-normal/ie7-loop-35.txt err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main process heap section" wait timed out in thread 0014, blocked by 0019, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main process heap section" wait timed out in thread 0014, blocked by 0019, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main process heap section" wait timed out in thread 0014, blocked by 0019, retrying (60 sec)
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #19 from Anastasius Focht focht@gmx.net --- Hello Austin,
--- quote --- @Focht, I've noticed even with all Heap calls changed, that I occasionally get deadlocks: --- quote ---
heap crit section timeouts are also an indication of heap corruption.
Maybe it's not only setupapi at fault here - updspapi might be involved too (most MS installers make use of both). One reason for the corruption could be that those installers make assumptions of win32 internal data structures which Wine doesn't match.
You could try selectively override setupapi and updspap and do some testing.
Regards
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #20 from Austin English austinenglish@gmail.com --- Native setupi has a lot of: fixme:seh:_abnormal_termination (void)stub
and crashes with: wine: Call from 0x7b83a82e to unimplemented function apphelp.dll.SdbInitDatabase, aborting
if I stub that, it gets further, to SCECLI.dll.SceSetupMoveSecurityFile. That function doesn't appear to be documented, howver, so I didn't try to do anything with it. (that's for ie7)
xmllite installs with no issues with native setupapi after SdbInitDatabase was stubbed. Running it now in a loop.
I'll test with native updspapi next.
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #21 from Anastasius Focht focht@gmx.net --- Hello Austin,
--- quote --- xmllite installs with no issues with native setupapi after SdbInitDatabase was stubbed. --- quote ---
I created bug 35891 for that.
Additionally I found a real world app - sdb2xml - some MS tool which makes use of Application Compatibility Database API's too.
Regards
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #22 from Austin English austinenglish@gmail.com --- udpspapi from xpsp3 works fine with ie7, it seems.
I'm currently testing: (native) setupapi xmllite *250 WINEDEBUG=warn+heap (native) setupapi xmllite *250
(native) udpspapi ie7 *100 WINEDEBUG=warn+heap (native) udpspapi ie7 *100
if that works, I'll test: (native) udpspapi xmllite *250 WINEDEBUG=warn+heap (native) udpspapi xmllite *250
(and commit setupapi/updspapi to winetricks)
assuming that all works, I'll next try: (private-heap) setupapi updspapi xmllite *250 WINEDEBUG=warn+heap (private-heap) setupapi updspapi xmllite *250
(private-heap) setupapi updspapi ie7 *100 WINEDEBUG=warn+heap (private-heap) setupapi updspapi ie7 *100
to make sure that the private heap change works with the native updspapi. If so, try removing some functions from the private heap, and repeat those tests (checking for backtraces or deadlocks).
Finally, when down to the minimal changes, retest one last time without native updspapi.
Thoughts?
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #23 from Anastasius Focht focht@gmx.net --- Hello Austin,
it would be interesting to know if 'udpspapi' override alone works for all cases.
Updspapi is a private version of Microsoft's setupapi library, distributed with their installers/service packs/updaters - not to be installed into OS.
Regards
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #24 from Austin English austinenglish@gmail.com --- WINEDEBUG=warn+heap winetricks setupapi xmllite
failed with a heap deadlock on the 65th try, though that was with wrong stub/spec file. Rerunning with it fixed.
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #25 from Austin English austinenglish@gmail.com --- (In reply to Anastasius Focht from comment #23)
Hello Austin,
it would be interesting to know if 'udpspapi' override alone works for all cases.
Updspapi is a private version of Microsoft's setupapi library, distributed with their installers/service packs/updaters - not to be installed into OS.
It does not:
ie7 - fails on the 2nd try ie7 & warn+heap - fails on the 19th try
xmllitte - fails 1 try xmllite & warn+heap - fails 1 try
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #26 from Austin English austinenglish@gmail.com --- I'm not sure how to test this further Focht. With setupapi fully using a private heap, I still sometimes (but rarely) get deadlocks. If I don't test for deadlocks, they get much more frequent when I reduce the private heap usage.
Native updspapi makes things worse.
Any other ideas or advice?
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #27 from Dan Kegel dank@kegel.com --- If the partial fix improves user experience, seems worth it.
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #28 from Nikolay Sivov bunglehead@gmail.com --- Maybe I missed something, but how does a private heap help with a corruption? It could be less destructive but if it's not where a real problem is why do we need this workaround?
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #29 from Anastasius Focht focht@gmx.net --- Hello Nikolay,
--- quote --- Maybe I missed something, but how does a private heap help with a corruption? It could be less destructive but if it's not where a real problem is why do we need this workaround? --- quote ---
yes, it doesn't really fix it - until the real cause is found. It reduces the probability of encountering a crash during install time considerably. There is already a high congestion in the heap for small blocks during run of installer, increasing the likelihood of 'collateral damage' by any win32 component.
It's not uncommon for MS installers to rely/make use of undocumented (internal) data structures, in this case setupapi.
Having a separate heap/wrappers might ease the task of isolating the actual set of API which causes the corruption.
Regards
https://bugs.winehq.org/show_bug.cgi?id=26016
Simon swdevelop1981@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |swdevelop1981@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=26016
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #30 from Anastasius Focht focht@gmx.net --- *** Bug 36041 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #31 from Nikolay Sivov bunglehead@gmail.com --- I'll take another look at table layout.
http://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #32 from Nikolay Sivov bunglehead@gmail.com --- Created attachment 48216 --> http://bugs.winehq.org/attachment.cgi?id=48216 patch
Hi, please try this to see if it helps with string table corruption. I would really appreciate some testing feedback.
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #33 from Austin English austinenglish@gmail.com --- With wine-1.7.17-42-g24c5728, no patch, failed after: ie7-normal: 2 tries ie7-heap: 54 tries xmllite-normal: 95 tries xmllite-heap: 27 tries
with attachment 48216: ie7-normal: failed 1st try ie7-heap: failed 1st try xmllite-normal: 145 tries xmllite-heap: 339 tries
http://bugs.winehq.org/show_bug.cgi?id=26016
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #48216|0 |1 is obsolete| |
--- Comment #34 from Nikolay Sivov bunglehead@gmail.com --- Created attachment 48242 --> http://bugs.winehq.org/attachment.cgi?id=48242 patch v2
Yes, I can see why it crashes with ie7 installer, it's fixed in attached patch. Please try with it.
http://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #35 from Nikolay Sivov bunglehead@gmail.com --- Created attachment 48243 --> http://bugs.winehq.org/attachment.cgi?id=48243 patch v3
Skip v2, try with v3. It contains a fix for some case that wasn't tested. I verified that ie7 installer still works.
http://bugs.winehq.org/show_bug.cgi?id=26016
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #48242|0 |1 is obsolete| |
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #36 from Austin English austinenglish@gmail.com --- (In reply to Nikolay Sivov from comment #34)
Created attachment 48242 [details] patch v2
Yes, I can see why it crashes with ie7 installer, it's fixed in attached patch. Please try with it.
I had already started a loop of this one, so might as well record the data: ie7-normal: failed 24th try (crash in msvcrt) ie7-heap: failed 15th try (deadlock in heap.c) xmllite-normal: 132 tries (deadlock in heap.c) xmllite-heap: 117 tries (deadlock in heap.c)
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #37 from Nikolay Sivov bunglehead@gmail.com --- It would be interesting to see some logs for failing runs. For msvcrt - it's possible it's a result of recent changes that uncovered more problems with msvcr* dlls.
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #38 from Austin English austinenglish@gmail.com --- Created attachment 48253 --> https://bugs.winehq.org/attachment.cgi?id=48253 backtrace for ie7
failure with try 3
https://bugs.winehq.org/show_bug.cgi?id=26016
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #47907|0 |1 is obsolete| | Attachment #47918|0 |1 is obsolete| | Attachment #48253|0 |1 is obsolete| |
--- Comment #39 from Austin English austinenglish@gmail.com --- Created attachment 48256 --> https://bugs.winehq.org/attachment.cgi?id=48256 backtrace for ie7
A better backtrace.
https://bugs.winehq.org/show_bug.cgi?id=26016
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #48243|0 |1 is obsolete| |
https://bugs.winehq.org/show_bug.cgi?id=26016
--- Comment #40 from Austin English austinenglish@gmail.com --- Nikolay's patch is now in git: https://source.winehq.org/git/wine.git/commitdiff/8802f84c8cc473d5617c134c16...
I retried the xmllite installer, it failed on the 39th try (+heap was NOT set):
Backtrace: =>0 0x7bc504d8 HEAP_FindFreeBlock+0x58(heap=0x110000, size=0x400, ppSubHeap=0x33b4fc) [/home/austin/wine-git/dlls/ntdll/heap.c:1004] in ntdll (0x0033b4a8) 1 0x7bc5083b RtlAllocateHeap+0xca(heap=<couldn't compute location>, flags=<couldn't compute location>, size=<couldn't compute location>) [/home/austin/wine-git/dlls/ntdll/heap.c:1689] in ntdll (0x0033b668) 2 0x7ee6fa0d find_pe_resource+0x1fc(lzfd=0xa8, resLen=0x33b8a0, resOff=0x33b8a4) [/home/austin/wine-git/dlls/version/version.c:332] in version (0x0033b7e8) 3 0x7ee702e2 find_version_resource+0x391(lzfd=0xa8, reslen=0x33b8a0, offset=0x33b8a4) [/home/austin/wine-git/dlls/version/version.c:406] in version (0x0033b878) 4 0x7ee70a16 GetFileVersionInfoSizeW+0xa5(filename=<couldn't compute location>, handle=<couldn't compute location>) [/home/austin/wine-git/dlls/version/version.c:632] in version (0x0033b948) 5 0x7e1e498f do_file_copyW+0x10e(source=<is not available>, target="C:\windows\system32\xmllite.dll", style=0x4, handler=0x7e1e5470, context=0x33bc98) [/home/austin/wine-git/dlls/setupapi/queue.c:967] in setupapi (0x0033b9d8) 6 0x7e1e8a1a SetupCommitFileQueueW+0x3a9(owner=<couldn't compute location>, handle=<couldn't compute location>, handler=<couldn't compute location>, context=<couldn't compute location>) [/home/austin/wine-git/dlls/setupapi/queue.c:1304] in setupapi (0x0033bc68) 7 0x7e1e92dc SetupCommitFileQueueA+0x4b(owner=<couldn't compute location>, queue=<couldn't compute location>, handler=<couldn't compute location>, context=<couldn't compute location>) [/home/austin/wine-git/dlls/setupapi/queue.c:879] in setupapi (0x0033bcb8) 8 0x01055f68 in update (+0x55f67) (0x0033f354) 0x7bc504d8 HEAP_FindFreeBlock+0x58 [/home/austin/wine-git/dlls/ntdll/heap.c:1004] in ntdll: movl 0xfffffff8(%esi),%eax 1004 SIZE_T arena_size = (pArena->size & ARENA_SIZE_MASK) + Modules: Module Address Debug info Name (110 modules)
Focht, any other ideas/tips? Or would you like to move to a new bug?
https://bugs.winehq.org/show_bug.cgi?id=26016
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |8802f84c8cc473d5617c134c169 | |73b1cb2c4b53e Status|NEW |RESOLVED Component|-unknown |setupapi Resolution|--- |FIXED Summary|Multiple Microsoft |Multiple Microsoft |installers crash with heap |installers crash with heap |corruption (private heap |corruption (StringTableXXX: |for StringTableXXX |binary compatible string |allocation wrapper in |table helps to reduce crash |setupapi needed)(XmlLite, |frequency)(XmlLite, XPSEP, |XPSEP, IE7) |IE7)
--- Comment #41 from Anastasius Focht focht@gmx.net --- Hello Austin,
--- quote --- I retried the xmllite installer, it failed on the 39th try (+heap was NOT set): .. Focht, any other ideas/tips? Or would you like to move to a new bug? --- quote ---
yes, I still have some idea - other setupapi area through.
Let's resolve this bug for the binary compatible string table feature that Nikolay put a lot of work in.
Although not 'fixed' it reduces the crash frequency and improves compatibility. Changing summary to reflect that.
http://source.winehq.org/git/wine.git/commitdiff/8802f84c8cc473d5617c134c169...
Thanks Nikolay
I'll create a new bug to have you guys test out my other idea(s).
Regards
https://bugs.winehq.org/show_bug.cgi?id=26016
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #42 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.19.
https://bugs.winehq.org/show_bug.cgi?id=26016
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://web.archive.org/web | |/20120525055657/http://down | |load.microsoft.com/download | |/2/5/2/2526f55d-32bc-410f-b | |e18-164ba67ae07d/XPSEP%20XP | |%20and%20Server%202003%2032 | |%20bit.msi