Re: Wine Gecko 1.1.0 RC1
On 9/3/10 10:04 PM, Anssi Hannula wrote: On Monday 23 August 2010 22:00:22 Jacek Caban wrote: This build is based on Firefox 4 beta 4 (that is expected to be released this week). It goes with massive improvements, but it's less interesting here. We finally have sane building procedure. Thanks to mingw-w64 project, we no longer have to maintain our own fixes to headers and libraries. I guess http://wiki.winehq.org/BuildingWineGecko is no longer up-to-date, then? Yeah, the build procedure changes quite often as I was working to make it easier and more proper. Build instructions are stored in Git. It doesn't make much sense to maintain wiki page anymore, so I've changed it to refer to Git. Jacek
Re: Wine Gecko 1.1.0 RC1
On Mon, Aug 23, 2010 at 10:00 PM, Jacek Caban ja...@codeweavers.com wrote: It's not yet fully tested and I need help with this. I'd appreciate any help with testing. Almost all changes required by the new Gecko were possible to be committed to current Wine. The attached patch contains remaining bits. All you need to test it is current Wine Git (must be today's or later), the attached patch and a new Gecko build. You can find new builds [1] and win64 build [2]. Put .cab files according to generic instructions [3] (obviously with different file names due to different Gecko versions). Please let me know of any regressions. There are some recent crashes in urlmon:url (32 bit) that seem to be related to wine gecko. The crashes are pretty random (usually crashes at asynchronous https test, but I've seen crashes with other backtraces or in other tests, and sometimes all tests run without a crash). I don't have the debug symbols for wine-gecko installed, but I attached a log+backtrace of the crash. Tell me if you need something more. They started for me just about when we switched to wine 1.1.0, but I'm not the only one who gets them. The bad thing is that it stops the tests with a message box saying TerminateProcess failed, so it's a pretty bad crash. Octavian $ WINETEST_DEBUG=1 WINEPREFIX=~/.wine32 ./wine programs/winetest/urlmon_test.exe url url.c:2965: test CreateAsyncBindCtx... url.c:2968: test CreateAsyncBindCtxEx... url.c:2971: test RegisterBindStatusCallback... url.c:2973: test BindToStorage failures... err:ole:CoGetClassObject apartment not initialised err:ole:CoGetClassObject apartment not initialised err:ole:CoGetClassObject apartment not initialised url.c:2976: synchronous http test (COM not initialised)... fixme:wininet:InternetLockRequestFile STUB fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! url.c:2981: test StdURLMoniker... url.c:2984: synchronous http test... fixme:wininet:InternetLockRequestFile STUB fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! url.c:2448: Test failed: unexpected OnProgress_FINDINGRESOURCE url.c:2987: emulated synchronous http test (to file)... url.c:2990: synchronous http test (to object)... fixme:urlmon:URLMoniker_BindToObject use running object table fixme:system:SetProcessDPIAware stub! fixme:iphlpapi:NotifyAddrChange (Handle 0x9ce914, overlapped 0x9ce918): stub fixme:ntdll:NtLockFile I/O completion on lock not implemented yet fixme:mshtml:nsURI_GetAsciiHost default action not implemented fixme:mshtml:nsChannel_Open (0x18511b8)-(0x32de04) fixme:mshtml:nsHttpChannelInternal_SetDocumentURI (0x185ae28)-() fixme:wininet:InternetLockRequestFile STUB fixme:mshtml:nsChannel_IsNoStoreResponse (0x185ae28)-(0x32e124) fixme:mshtml:nsChannel_IsNoCacheResponse (0x185ae28)-(0x32e120) fixme:mshtml:nsURI_GetHostPort default action not implemented fixme:mshtml:nsURI_GetHostPort default action not implemented fixme:mshtml:nsURI_GetHost default action not implemented fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:mshtml:nsChannel_IsNoStoreResponse (0x185ae28)-(0x32f4e4) fixme:mshtml:nsChannel_IsNoCacheResponse (0x185ae28)-(0x32f4e0) fixme:mshtml:nsChannel_Cancel (0x185ae28)-(804b0002) url.c:2646: Test failed: unexpected Obj_OnProgress_FINDINGRESOURCE url.c:2993: emulated synchronous http test (with cache)... url.c:2996: emulated synchronous http test (with cache, no read)... url.c:2999: synchronous http test (with cache, no read)... fixme:wininet:InternetLockRequestFile STUB fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! url.c:2448: Test failed: unexpected OnProgress_FINDINGRESOURCE url.c:3002: synchronous file test... url.c:3005: emulated synchronous file test (to file)... url.c:3008: synchronous file test (to object)... fixme:urlmon:URLMoniker_BindToObject use running object table fixme:mshtml:nsURI_GetHostPort default action not implemented fixme:mshtml:nsURI_GetHost default action not implemented fixme:mshtml:nsChannel_Cancel (0x18989c8)-(804b0002) url.c:3013: http test... fixme:mshtml:nsURI_GetHost default action not implemented fixme:mshtml:nsURI_GetHost default action not implemented fixme:wininet:InternetLockRequestFile STUB fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! url.c:2448: Test failed: unexpected OnProgress_FINDINGRESOURCE url.c:3016: http test (to file)... fixme:wininet:InternetLockRequestFile STUB fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! url.c:2448: Test failed: unexpected OnProgress_FINDINGRESOURCE url.c:3019: http test (to object)... fixme:urlmon:URLMoniker_BindToObject use running object table fixme:mshtml:nsURI_GetAsciiHost default action not implemented fixme:mshtml:nsHttpChannelInternal_SetDocumentURI (0x11cbaa8)-() fixme:wininet:InternetLockRequestFile STUB
Re: Wine Gecko 1.1.0 RC1
On 9/4/10 2:28 PM, Octavian Voicu wrote: On Mon, Aug 23, 2010 at 10:00 PM, Jacek Caban ja...@codeweavers.com mailto:ja...@codeweavers.com wrote: It's not yet fully tested and I need help with this. I'd appreciate any help with testing. Almost all changes required by the new Gecko were possible to be committed to current Wine. The attached patch contains remaining bits. All you need to test it is current Wine Git (must be today's or later), the attached patch and a new Gecko build. You can find new builds [1] and win64 build [2]. Put .cab files according to generic instructions [3] (obviously with different file names due to different Gecko versions). Please let me know of any regressions. There are some recent crashes in urlmon:url (32 bit) that seem to be related to wine gecko. The crashes are pretty random (usually crashes at asynchronous https test, but I've seen crashes with other backtraces or in other tests, and sometimes all tests run without a crash). I don't have the debug symbols for wine-gecko installed, but I attached a log+backtrace of the crash. Tell me if you need something more. They started for me just about when we switched to wine 1.1.0, but I'm not the only one who gets them. The bad thing is that it stops the tests with a message box saying TerminateProcess failed, so it's a pretty bad crash This is not new crash. It's an old, rare random crash. I've tried to debug it, but didn't find the bug. I will probably come back to this later, when time permits. Jacek
Re: Wine Gecko 1.1.0 RC1
On Sat, Sep 4, 2010 at 9:00 PM, Jacek Caban ja...@codeweavers.com wrote: On 9/4/10 2:28 PM, Octavian Voicu wrote: There are some recent crashes in urlmon:url (32 bit) that seem to be related to wine gecko. The crashes are pretty random (usually crashes at asynchronous https test, but I've seen crashes with other backtraces or in other tests, and sometimes all tests run without a crash). I don't have the debug symbols for wine-gecko installed, but I attached a log+backtrace of the crash. Tell me if you need something more. They started for me just about when we switched to wine 1.1.0, but I'm not the only one who gets them. The bad thing is that it stops the tests with a message box saying TerminateProcess failed, so it's a pretty bad crash This is not new crash. It's an old, rare random crash. I've tried to debug it, but didn't find the bug. I will probably come back to this later, when time permits. But is it related to a bug in wine or gecko? Running with debug version of gecko shows numerous assertion failures and at the end lots of unclaimed memory, but I suppose you know about these problems. I know it's random, but after the upgrade to wine 1.1.0 it's become must less rare for me. Again, I must stress that that is just one backtrace, I've seen crashes in different places, but most happen somewhere during https test (again, not in the same place all the time).
Re: Wine Gecko 1.1.0 RC1
On 9/4/10 8:09 PM, Octavian Voicu wrote: On Sat, Sep 4, 2010 at 9:00 PM, Jacek Caban ja...@codeweavers.com mailto:ja...@codeweavers.com wrote: On 9/4/10 2:28 PM, Octavian Voicu wrote: There are some recent crashes in urlmon:url (32 bit) that seem to be related to wine gecko. The crashes are pretty random (usually crashes at asynchronous https test, but I've seen crashes with other backtraces or in other tests, and sometimes all tests run without a crash). I don't have the debug symbols for wine-gecko installed, but I attached a log+backtrace of the crash. Tell me if you need something more. They started for me just about when we switched to wine 1.1.0, but I'm not the only one who gets them. The bad thing is that it stops the tests with a message box saying TerminateProcess failed, so it's a pretty bad crash This is not new crash. It's an old, rare random crash. I've tried to debug it, but didn't find the bug. I will probably come back to this later, when time permits. But is it related to a bug in wine or gecko? Running with debug version of gecko shows numerous assertion failures and at the end lots of unclaimed memory, but I suppose you know about these problems. It seems to be a problem in Wine, not Gecko. I've seen memory corruptions in crypt32, although they were not nessessarily crypt32 bugs. I know it's random, but after the upgrade to wine 1.1.0 it's become must less rare for me. Again, I must stress that that is just one backtrace, I've seen crashes in different places, but most happen somewhere during https test (again, not in the same place all the time). Yeah, that's the nature of random bugs. Jacek
Re: Wine Gecko 1.1.0 RC1
On Monday 23 August 2010 22:00:22 Jacek Caban wrote: This build is based on Firefox 4 beta 4 (that is expected to be released this week). It goes with massive improvements, but it's less interesting here. We finally have sane building procedure. Thanks to mingw-w64 project, we no longer have to maintain our own fixes to headers and libraries. I guess http://wiki.winehq.org/BuildingWineGecko is no longer up-to-date, then? Also I've fixed a bug so that moztools is no longer needed for crosscompiling. It means that we no longer need any binary files, which should make open source fanatics (in a good sense) happy. Well... almost. We still need to create .cab file, which I do via Filzip on Windows. That's something we can work around. We use .cab files, because that's the only archive format that Wine can deal with. We can teach Wine to use other formats, which would finally make it possible for Wine packagers to do their own builds, if they like. -- Anssi Hannula
Re: Wine Gecko 1.1.0 RC1
On 24 August 2010 05:00, Jacek Caban ja...@codeweavers.com wrote: The attached patch contains remaining bits. Haven't tested it, but I was having a flick through, and noticed that the second hunk for dlls/mshtml/nsembed.c has: ERR(Could not get nsIDontent interface: %08x\n, nsres); instead of ERR(Could not get nsIContent interface: %08x\n, nsres); -- Paul TBBle Hampson, paul.hamp...@pobox.com
Re: Wine Gecko 1.1.0 RC1
On 8/24/10 12:12 PM, Luca Bennati wrote: Applied the patch to master, recompiled ok. I put the rc1 cab in /usr/share/wine/gecko/, as always. In the creation of a new prefix, it gave me an err which wasn't there before: err:mshtml:init_xpcom AutoRegister(NULL) failed: 80070057 but 'wine iexplore' works better than before (sites that crashed wine before don't crash it anymore). I investigated it a bit recreating a new prefix with 'WINEDEBUG=+mshtml winecfg' and here's the log: Thanks for testing. This error is a known false error. Modules loading method has changed in Gecko and AutoRegister call is no longer needed, so I'm going to remove this call. It's harmless in the new Gecko, so I'm going to do it in another patch to limit size of this one. Thanks, Jacek
