[Bug 33450] New: .NET 3.5 Framework installation fails (.NET WorkFlow Service Registration Tool "WFServicesReg.exe" crash)
http://bugs.winehq.org/show_bug.cgi?id=33450
Bug #: 33450 Summary: .NET 3.5 Framework installation fails (.NET WorkFlow Service Registration Tool "WFServicesReg.exe" crash) Product: Wine Version: 1.5.28 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: msxml3 AssignedTo: wine-bugs@winehq.org ReportedBy: focht@gmx.net Classification: Unclassified
Hello folks,
while investigating some .NET related bugs I found .NET Framework 3.5 doesn't install anymore with current winetricks. There is now a crash in .NET WorkFlow Service Registration Tool (WFServicesReg.exe) which leads to main installer getting stuck. Looks like a Wine msxml regression or new bug.
Can be reproduced after first failed install by running the tool manually.
Prerequisite: clean WINEPREFIX + 'winetricks -q dotnet35'
Console output:
--- snip --- $ wine C:\windows\Microsoft.NET\Framework\v3.5\WFServicesReg.exe /c /v /m /i fixme:heap:HeapSetInformation (nil) 1 (nil) 0 DDSet_Entry: WFServicesReg.exe DDSet_Status: CFxInstaller::CopyConfigFilesToTemp is64bit=0 DDSet_Status: CFileHelper::CopyConfigFilesToTempLocation DDSet_Status: CFxInstaller::SetupComponents isInstall=1 DDSet_Status: CFxInstaller::SetupComponents Calling SetupExtensions. isInstall=1 DDSet_Status: CFxInstaller::SetupExtensions isInstall=1 is64Bit=0 DDSet_Status: CConfigEntry::Initialize szConfigPath=C:\users\focht\Temp\WSF8f8c.tmp DDSet_Status: CConfigEntry::RefreshConfigFile DDSet_Status: CExtensionElement::SetData szName=persistenceProvider szType=System.ServiceModel.Configuration.PersistenceProviderElement, System.WorkflowServices, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 szXPath=system.serviceModel/extensions/behaviorExtensions/add DDSet_Status: CFxInstaller::SetupExtensions Adding System.ServiceModel.Configuration.PersistenceProviderElement, System.WorkflowServices, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35. DDSet_Status: CExtensionElement::AddToConfigFile _xPath=system.serviceModel/extensions/behaviorExtensions/add DDSet_Status: CConfigEntry::IsPresent szPath=system.serviceModel/extensions/behaviorExtensions/add[@name='persistenceProvider' and @type='System.ServiceModel.Configuration.PersistenceProviderElement, System.WorkflowServices, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'] DDSet_Status: CConfigEntry::IsPresent szPath=system.serviceModel/extensions/behaviorExtensions/add[@name='persistenceProvider'] DDSet_Status: CConfigEntry::CreateElementInConfigFile szPath=system.serviceModel/extensions/behaviorExtensions/add insertBefore=0 DDSet_Status: CConfigEntry::AppendTextNode DDSet_Status: CConfigEntry::AppendTextNode DDSet_Status: CConfigEntry::AppendTextNode DDSet_Status: CConfigEntry::AppendTextNode DDSet_Status: CConfigEntry::AppendTextNode DDSet_Status: CConfigEntry::AppendTextNode DDSet_Status: CConfigEntry::AppendTextNode wine: Unhandled page fault on read access to 0x00000007 at address 0xf74cc19d (thread 0009), starting debugger... --- snip ---
Running it with winedbg:
--- snip --- Unhandled exception: page fault on read access to 0x00000007 in 32-bit code (0xf744619d). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:f744619d ESP:0033f970 EBP:0000003c EFLAGS:00010286( R- -- I S - -P- ) EAX:00000006 EBX:f7578ff4 ECX:f75793f8 EDX:ffffffff ESI:f75793e0 EDI:f75793e0 Stack dump: 0x0033f970: 7e879d70 7bcc89d0 0033f998 0033f9a0 0x0033f980: 7bcc89d0 0033fa20 0033fa08 7bc4b26c 0x0033f990: 7bcc89d0 7bcc89d0 0033fa08 7bc4b26c 0x0033f9a0: 00110060 00000001 00000017 ffffffff 0x0033f9b0: 00000006 00000040 00330000 7de87a8a 0x0033f9c0: 00110014 0000003c 0033fa48 7b850bb3 000c: sel=0067 base=00000000 limit=00000000 32-bit r-x Backtrace: =>0 0xf744619d _int_malloc+0x6d() in libc.so.6 (0x0000003c) 1 0xf7448e75 __libc_malloc+0x64() in libc.so.6 (0x0000003c) 2 0x7dd22462 xmlNewText+0x31() in libxml2.so.2 (0x00000000) 3 0x7dd22850 xmlNewDocText+0xf() in libxml2.so.2 (0x0033fb58) 4 0x7de82243 domdoc_createNode+0x3da(iface=0x12b6d4, Type={n1={n2={vt=0x10, wReserved1=0, wReserved2=0x1a78, wReserved3=0x102, n3={cVal=3, uiVal=0xe03, ulVal=0x1020e03, intVal=0x1020e03, uintVal=0x1020e03, bVal=3, iVal=0xe03, lVal=0x1020e03, fltVal=0.000000, dblVal=0.000000, boolVal=0xe03, scode=0x1020e03, date=0.000000, bstrVal="...", pulVal=0x1020e03, pintVal=0x1020e03, puintVal=0x1020e03, pbVal="...", piVal=0x1020e03, plVal=0x1020e03, pfltVal=0x1020e03, pdblVal=0x1020e03, pboolVal=0x1020e03, pscode=0x1020e03, pdate=0x1020e03, pbstrVal=0x1020e03, pvarVal=0x1020e03, byref=0x1020e03, pcyVal=0x1020e03, pdecVal=0x1020e03, ppunkVal=0x1020e03, ppdispVal=0x1020e03, pparray=0x1020e03, pllVal=0x1020e03, pullVal=0x1020e03, brecVal={pvRecord=0x1020e03, pRecInfo=0x1021a78}}}, decVal={wReserved=0x10, u={={scale=0, sign=0}, signscale=0}, Hi32=0x1021a78, u1={={Lo32=0x1020e03, Mid32=0x1021a78}, Lo64=0x1021a7801020e03}}}}, name=0x0(nil), namespaceURI=0x0(nil), node=0x33fba8) [/home/focht/projects/wine/wine-git/dlls/msxml3/domdoc.c:1969] in msxml3 (0x0033fb58) 5 0x7de811fe domdoc_createTextNode+0x12d(iface=<couldn't compute location>, data=<couldn't compute location>, text=<couldn't compute location>) [/home/focht/projects/wine/wine-build32/dlls/msxml3/../../include/msxml6.h:5222] in msxml3 (0x0033fbf8) 6 0x01013735 in wfservicesreg (+0x13734) (0x0033fc38) ... --- snip ---
Can be worked around with 'winetricks msxml3'.
$ wine --version wine-1.5.28-200-gf3b0a9f
Regards
http://bugs.winehq.org/show_bug.cgi?id=33450
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |dotnet, download, Installer URL| |http://download.microsoft.c | |om/download/6/0/f/60fc5854- | |3cb8-4892-b6db-bd4f42510f28 | |/dotnetfx35.exe
http://bugs.winehq.org/show_bug.cgi?id=33450
--- Comment #1 from Anastasius Focht focht@gmx.net 2013-04-24 02:26:51 CDT --- Created attachment 44279 --> http://bugs.winehq.org/attachment.cgi?id=44279 WINEDEBUG=+tid,+seh,+loaddll,+process,+msxml wine WFServicesReg.exe /c /v /m /i
http://bugs.winehq.org/show_bug.cgi?id=33450
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=33450
--- Comment #2 from Nikolay Sivov bunglehead@gmail.com 2013-04-30 07:13:34 CDT --- Maybe I broke it with 47d2f3caf56eb6c06b1d8f6d0f07b9815da685e6? Trying to test myself right now.
http://bugs.winehq.org/show_bug.cgi?id=33450
--- Comment #3 from Nikolay Sivov bunglehead@gmail.com 2013-04-30 14:57:47 CDT --- Interesting, if I'm able to reproduce that with debian libxml2 2.7.8. However if I build it from git (currently it's 2.9.1) I get a different crash, and it seems that problematic code is execute in this case. What's you lib version?
http://bugs.winehq.org/show_bug.cgi?id=33450
--- Comment #4 from Austin English austinenglish@gmail.com 2013-04-30 14:59:10 CDT --- (In reply to comment #3)
Interesting, if I'm able to reproduce that with debian libxml2 2.7.8. However if I build it from git (currently it's 2.9.1) I get a different crash, and it seems that problematic code is execute in this case. What's you lib version?
I noticed something similar. I can reproduce this on Fedora, but not my gentoo machine, which as libxml2-2.9.0.
Not sure what version my Fedora laptop has, off hand.
http://bugs.winehq.org/show_bug.cgi?id=33450
--- Comment #5 from Nikolay Sivov bunglehead@gmail.com 2013-05-03 15:04:51 CDT --- It doesn't depend on libxml2 version, in fact crash was caused by the very same thing. Libxml2 has a habit to "optimize" away adjacent text nodes, so when you add a new text child it checks if it will be added next to existing text node, then it will merge text data and free passed child node. Relevant piece of code from xmlAddChild():
--- /* * If cur is a TEXT node, merge its content with adjacent TEXT nodes * cur is then freed. */ if (cur->type == XML_TEXT_NODE) { if ((parent->type == XML_TEXT_NODE) && (parent->content != NULL) && (parent->name == cur->name)) { xmlNodeAddContent(parent, cur->content); xmlFreeNode(cur); return(parent); } if ((parent->last != NULL) && (parent->last->type == XML_TEXT_NODE) && (parent->last->name == cur->name) && (parent->last != cur)) { xmlNodeAddContent(parent->last, cur->content); xmlFreeNode(cur); return(parent->last); } } ---
'cur' here is what's passed as child to add to the tree. That of course leads to DOM tree going out of sync with libxml2 tree and eventually it will double free or access freed memory. It's possible to have our own xmlAddChild() version that is not that smart and preserves all nodes, but the question here is what will potentially break next in libxml2 when a tree gets several text siblings next to each other. I'll check if it makes any assumptions about that, and probably will check with author too.
http://bugs.winehq.org/show_bug.cgi?id=33450
--- Comment #6 from Nikolay Sivov bunglehead@gmail.com 2013-05-06 01:29:14 CDT --- I just got a reply from libxml2 author, Daniel said that such tree hacking will break XPath results as XPath processor expects merged text nodes. So we're basically in a situation when lib internals won't let us have a tree model we want. This could be solved probably with having own XPath processor that doesn't need this feature to work.
http://bugs.winehq.org/show_bug.cgi?id=33450
Daniel Jelinski djelinski1@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |djelinski1@gmail.com
--- Comment #7 from Daniel Jelinski djelinski1@gmail.com 2013-05-18 10:13:49 CDT --- cb9d787be150af96c75a652341622d086f7da1ff is the first bad commit commit cb9d787be150af96c75a652341622d086f7da1ff Author: Nikolay Sivov nsivov@codeweavers.com Date: Mon Feb 25 00:30:22 2013 +0400
msxml3: Better handle cross-tree node moves.
Hope that helps... The commit does not revert cleanly.
http://bugs.winehq.org/show_bug.cgi?id=33450
--- Comment #8 from Nikolay Sivov bunglehead@gmail.com 2013-05-18 11:55:16 CDT --- Hm, that's a strange result actually, to test it you could just step before this commit and then back on it to see a difference. It's possible there's several issues of course.
http://bugs.winehq.org/show_bug.cgi?id=33450
--- Comment #9 from Daniel Jelinski djelinski1@gmail.com 2013-05-18 13:35:29 CDT --- yup, double checked before posting, just checked again to make sure.
http://bugs.winehq.org/show_bug.cgi?id=33450
--- Comment #10 from Daniel Jelinski djelinski1@gmail.com 2013-05-18 14:07:14 CDT --- Created attachment 44494 --> http://bugs.winehq.org/attachment.cgi?id=44494 hack
this hack restores the previous behaviour, allowing WFServicesReg to complete.
http://bugs.winehq.org/show_bug.cgi?id=33450
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com Regression SHA1| |cb9d787be150af96c75a6523416 | |22d086f7da1ff
--- Comment #11 from Dan Kegel dank@kegel.com 2013-06-28 21:04:04 CDT --- Just ran into this myself with wine-1.6-rc3 (on first try) on ubuntu 13.04, so I added the suggested workaround to winetricks ( r1013 ).
Adding reported regression hash.
http://bugs.winehq.org/show_bug.cgi?id=33450
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=33450
--- Comment #12 from Nikolay Sivov bunglehead@gmail.com 2013-07-01 05:07:35 CDT --- Created attachment 45062 --> http://bugs.winehq.org/attachment.cgi?id=45062 patch
Attached patch fixes it for me, but it's not really a proper fix for at least two reasons:
- it's limited to a case when we have one xmlnode created for xmlNodePtr, so when we have multiple instances for the same node references won't update properly; - the whole idea to move text node to orphans just hides a problem, it allows to cleanly release instances, but doesn't preserve tree structure or content.
http://bugs.winehq.org/show_bug.cgi?id=33450
swdevelop1981@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |swdevelop1981@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=33450
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kennybobs@o2.co.uk
http://bugs.winehq.org/show_bug.cgi?id=33450
hanska2@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hanska2@luukku.com
--- Comment #13 from hanska2@luukku.com --- PING
Last comment
2013-07-01
Is this really valid?
http://bugs.winehq.org/show_bug.cgi?id=33450
--- Comment #14 from Anastasius Focht focht@gmx.net --- Hello Jarkko,
--- quote --- Is this really valid? --- quote ---
if you are questioning the validity of this bug you should come up with a thorough research/explanation.
I have no problem to hear alternate conclusions - which do happen, albeit very rarely. Make sure you are up to the task of understanding what all these bugs are about before making claims. Just stating "still a problem with Wine <version>" is ok. Guesswork should be avoided unless you can substantiate it with details/facts.
The bug is still valid and it's easily verifiable: remove the workaround for this bug in 'dotnet35' recipe in 'winetricks' script and run the recipe on a clean 32-bit WINEPREFIX.
Regards
https://bugs.winehq.org/show_bug.cgi?id=33450
mrdeathjr28@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28@yahoo.es
https://bugs.winehq.org/show_bug.cgi?id=33450
--- Comment #15 from Austin English austinenglish@gmail.com --- (In reply to Anastasius Focht from comment #14)
Hello Jarkko,
--- quote --- Is this really valid? --- quote ---
if you are questioning the validity of this bug you should come up with a thorough research/explanation.
I have no problem to hear alternate conclusions - which do happen, albeit very rarely. Make sure you are up to the task of understanding what all these bugs are about before making claims. Just stating "still a problem with Wine <version>" is ok. Guesswork should be avoided unless you can substantiate it with details/facts.
The bug is still valid and it's easily verifiable: remove the workaround for this bug in 'dotnet35' recipe in 'winetricks' script and run the recipe on a clean 32-bit WINEPREFIX.
Regards
Hi Anastatius,
So while poking around in winetricks today, I noticed that it isn't applying this workaround for wine versions < 1.5.28.
To be sure, I removed the whole section, and ran: $ winetricks -q -v --verify dotnet35
------------------------------------------------------ .Net Verifier returned 0 ------------------------------------------------------ ------------------------------------------------------ verify_dotnet35 succeeded! ------------------------------------------------------
The patch still partially applies, though, so I'm not sure what's happening. None of the dependencies of dotnet35 install native msxml3 either, so it's not that..
This was with wine-2.8-540-ge0e4f9bbcd, for reference.
https://bugs.winehq.org/show_bug.cgi?id=33450
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #16 from joaopa jeremielapuree@yahoo.fr --- Is still a bug in current wine(3.20)?
https://bugs.winehq.org/show_bug.cgi?id=33450
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NOTOURBUG Summary|.NET 3.5 Framework |.NET 3.5 Framework |installation fails (.NET |installation fails (.NET |WorkFlow Service |WorkFlow Service |Registration Tool |Registration Tool |"WFServicesReg.exe" crash) |"WFServicesReg.exe" crash | |with libxml2 < 2.9.0)
--- Comment #17 from Anastasius Focht focht@gmx.net --- Hello folks,
not reproducible any more, even with old Wine 1.5.28 this was reported against. I have all Wine releases from 4.0-rc down to 1.4 built on a recent Fedora distro (ships libxml2 2.9.8) with for testing. It was most likely fixed in libxml2 2.9.x series.
Figuring out which changes in libxml2 [1] apparently fixes this is left as an exercise to whom it may concern. Resolving as 'NOTOURBUG'.
Regards
[1]: https://github.com/GNOME/libxml2
https://bugs.winehq.org/show_bug.cgi?id=33450
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://download.microsoft.c |https://web.archive.org/web |om/download/6/0/f/60fc5854- |/20130329011524if_/http://d |3cb8-4892-b6db-bd4f42510f28 |ownload.microsoft.com/downl |/dotnetfx35.exe |oad/6/0/f/60fc5854-3cb8-489 | |2-b6db-bd4f42510f28/dotnetf | |x35.exe
-
wine-bugs＠winehq.org -
WineHQ Bugzilla