HI all, (If you're not interested in details, please read the last paragraph). It's been over year since the last Gecko update. A lot has happen since then. I've been planning to update our build a bit later, with Firefox 4 codebase, but plans have changed. We had some serious problems with previous build (like bug 22157 and bug 24059, both should be fixed in the new build). Also there is *a lot* happening in Mozilla world. With upcoming Firefox 4, the backward compatibility is no longer supported and the code is changing with an impressive speed. I try to follow these changes, but I need a good solid base so that I can take care of our needs in Mozilla. 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. 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. The new Gecko is also the first to support Win64. Not all tests pass yet, but failing ones are due to missing DispCallFunc implementation for Win64, so it's not a Gecko problem. 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. Thanks, Jacek [1] http://gerwazy.lo3.wroc.pl/~jcaban/wine_gecko-1.1.0-rc1-x86.cab [2] http://gerwazy.lo3.wroc.pl/~jcaban/wine_gecko-1.1.0-rc1-x86_64.cab [3] http://wiki.winehq.org/Gecko
On 24 August 2010 05:00, Jacek Caban <jacek(a)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.Hampson(a)Pobox.com
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
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
On Mon, Aug 23, 2010 at 10:00 PM, Jacek Caban <jacek(a)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
On 9/4/10 2:28 PM, Octavian Voicu wrote:
On Mon, Aug 23, 2010 at 10:00 PM, Jacek Caban <jacek(a)codeweavers.com <mailto:jacek(a)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
On Sat, Sep 4, 2010 at 9:00 PM, Jacek Caban <jacek(a)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).
On 9/4/10 8:09 PM, Octavian Voicu wrote:
On Sat, Sep 4, 2010 at 9:00 PM, Jacek Caban <jacek(a)codeweavers.com <mailto:jacek(a)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
participants (4)
-
Anssi Hannula -
Jacek Caban -
Octavian Voicu -
Paul "TBBle" Hampson