RE: shdocvw: Implement IWebBrowser::ExecWB and IWebBrowser::QueryStatusWB.
From: Greg Geldorp <ggeldorp(a)vmware.com>
From: Erich Hoover
On Thu, Jan 27, 2011 at 3:53 AM, Greg Geldorp <ggeldorp(a)vmware.com> wrote:
... Looking at http://test.winehq.org/data/tests/shdocvw:webbrowser.html, the shdocvw:webbrowser test doesn't have a history of occasional crashes. There are a few failures, but none of them are due to access violations. Which kind of indicates that the crash is because of the changes you made. I know it sucks to investigate failures that don't repro consistently, but I do think some more testing would be good here. Of course, if there's any info you need about the VM just let me know.
Well, I commandeered a XP SP3 box this morning and ran that exact same set of tests successfully 10,000 times. I don't have access to a Win7 box or I would have run the tests on that. Thoughts?
I'll do a similar test on Win7 tomorrow and let you know the results.
I started by running your test binary 10,000 times on W7PROX64. Not a single crash, so that looked kind of promising. Just to be sure, I then ran the binary on a dual-core Win7 x64 machine (the W7PROX64 VM has only one core assigned to it). This resulted in an immediate crash. Tried a few more times, it crashed 9 out of 10 times. To make sure that these crashes are related to your patch, I ran the test without your patch on the same dual-core machine. First few tries didn't produce crashes, I then ran it in a loop 10,000 times. Not a single crash. So, it looks like your patch introduces some multi-threading issue. I haven't investigated further, perhaps I'll have some time over the weekend to dig a bit deeper. Greg.
On Fri, Jan 28, 2011 at 6:45 AM, Greg Geldorp <ggeldorp(a)vmware.com> wrote:
... I started by running your test binary 10,000 times on W7PROX64. Not a single crash, so that looked kind of promising. Just to be sure, I then ran the binary on a dual-core Win7 x64 machine (the W7PROX64 VM has only one core assigned to it). This resulted in an immediate crash. Tried a few more times, it crashed 9 out of 10 times.
To make sure that these crashes are related to your patch, I ran the test without your patch on the same dual-core machine. First few tries didn't produce crashes, I then ran it in a loop 10,000 times. Not a single crash.
So, it looks like your patch introduces some multi-threading issue. I haven't investigated further, perhaps I'll have some time over the weekend to dig a bit deeper.
Hmm, interesting - thanks for taking a look into this, I really appreciate it. I ran a test on a different XP SP3 machine here (this time a dual-core) and it worked just fine. So, at first I thought this must be an issue to the combination of multi-core and Windows 7. However, if the location of the exception has anything to say about it (crashing after test_Navigate2:test_LocationURL), then my guess would be that it's because of the "wb" global. I didn't notice this before (or if I did, I forgot) but test_Navigate2:test_ready_state uses the IWebBrowser2 "wb" global, which I did not initialize until after test_Navigate2. If you wouldn't mind giving it a try on your system where the error is reproducible, I've attached a revised patch where this variable is initialized properly. Erich Hoover ehoover(a)mines.edu
From: Erich Hoover
Hmm, interesting - thanks for taking a look into this, I really appreciate it. I ran a test on a different XP SP3 machine here (this time a dual-core) and it worked just fine. So, at first I thought this must be an issue to the combination of multi-core and Windows 7. However, if the location of the exception has anything to say about it (crashing after test_Navigate2:test_LocationURL), then my guess would be that it's because of the "wb" global. I didn't notice this before (or if I did, I forgot) but test_Navigate2:test_ready_state uses the IWebBrowser2 "wb" global, which I did not initialize until after test_Navigate2. If you wouldn't mind giving it a try on your system where the error is reproducible, I've attached a revised patch where this variable is initialized properly.
Jackpot. This version ran 10,000 times without a glitch on the dual-core machine. Greg.
On Sat, Jan 29, 2011 at 4:18 AM, Greg Geldorp <ggeldorp(a)vmware.com> wrote:
Jackpot. This version ran 10,000 times without a glitch on the dual-core machine.
Great! Thank you so much for helping me to track this down. Erich Hoover ehoover(a)mines.edu
participants (2)
-
Erich Hoover -
Greg Geldorp