Closed Bug 201097 Opened 22 years ago Closed 22 years ago

[AxPlugin] activex Plugin performs illegal operation when active-x content opened

Categories

(Core Graveyard :: Embedding: ActiveX Wrapper, defect)

Product:
Core Graveyard
Component:
Embedding: ActiveX Wrapper
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: ashshbhatt, Assigned: adamlock)

References

Details

Attachments

(3 files)

Stack of crash
6.55 KB, text/plain
Details
mozconfig
1.43 KB, text/plain
Details
Patch
1.20 KB, patch
dbradley
: review+
alecf
: superreview+
Details | Diff | Splinter Review
Tested with 20030407 illegal operation dialog comes up when a page with active-x content is opened. Mozilla does not crash and the execution os the script on the page continues. Closing mozilla crashes it. Does not happen in mozilla debug build. Looks like pref issue since the crash happens in xppref32.dll Stack trace xppref32.dll!00c44332() xppref32.dll!00c4418c() xpcom.dll!100046e9() mozilla.exe!004102d1() mozilla.exe!00402f1e() kernel32.dll!77e814c7()
is this a dupe of bug 200680?
NO, this is something I only get in nightly builds. This does not happen in the debug build
Is there a specific URL that causes this?
This happens on any page which has Active-x content like <object> tag Testcase: <html> <head> </head> <body> <object ID="Player" height="10" width="10" CLASSID="CLSID:6BF52A52-394A-11d3-B153-00C04F79FAA6" foo="Foo()"> <param name="baseURL" value="file:///c:/m/activex_samples"> </object> </body> </html>
It seems to be any control. The plugin or something it calls crashes and the NPAPI and puts up a 'plugin has crashed' dialog. I can't find any way to stop it doing this so I can see a stack trace of talkback incident. Even setting a "plugin.dont_try_safe_calls" pref doesn't make any difference. I'll have to do an optimized build and see if I can reproduce it. Ashish if you can generate a talkback ID, can you attach it please? Thanks
Works until 2003-04-01-05-trunk_ax and crashes 2003-04-02-05-trunk_ax onwards. caused by somethig that was checked in on 04/01.
Attached file Stack of crash —
This is the stack of a crash I get in the plugin code. Not entirely sure it's the same. pData looks bad, it's not null, but it's not a valid pointer either.
Well I've figured out how to use the pref. It seems to be read even before there is a user profile, so it has to go into the defaults\pref folder to be picked up, e.g. add this to activex.js: pref("plugin.dont_try_safe_calls", true); I have been unable to reproduce this with my own local optimized build this morning, but here is the (not very helpful) stack trace for a downloaded nightly version: NPMOZAX! 02112192() GKPLUGIN! 01a136c5() GKPLUGIN! 01a18935() GKLAYOUT! 00e77525() GKLAYOUT! 00e76b19() GKLAYOUT! 00e8f2ce() GKLAYOUT! 00e93c2e() GKLAYOUT! 00e93a8c() GKLAYOUT! 00e93915() GKLAYOUT! 00e937f9() GKLAYOUT! 00e92acb() GKLAYOUT! 00e925b3() GKLAYOUT! 00e916f3() GKLAYOUT! 00e9a81a() GKLAYOUT! 00e93471() GKLAYOUT! 00e928b7() GKLAYOUT! 00e925b3() GKLAYOUT! 00e916f3() GKLAYOUT! 00e84a7a() GKLAYOUT! 00e75160() GKLAYOUT! 00ef5a0f() GKLAYOUT! 00ef5746() GKLAYOUT! 00ed6cf4() GKLAYOUT! 00ed6cf4() GKLAYOUT! 0101ab85() GKLAYOUT! 0101abb0() GKLAYOUT! 00ed6cf4() GKLAYOUT! 0101a455() GKLAYOUT! 00e84a7a() GKLAYOUT! 01018fe3() GKLAYOUT! 00e65fcf() GKLAYOUT! 00e6d112() GKLAYOUT! 00e6cf05() XPCOM! 1002c30b() SHELL32! 778b0c24() The only change that has gone into the plugin recently is changes to the control param parsing code in LegacyPlugin.cpp on 2nd April for bug 199163. This fits in with the timetable but I don't see anything about it which would cause this crash.
I've tried a couple of combinations of flags to replicate the issue in my local build with no success. So far I have been testing with VC++ 7.0 but I'm now trying a build using VC++ 6.0 to see if that makes a difference. The only checkin that went into the plugin in the timeframe was this: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=LegacyPlugin.cpp&root=/cvsroot&subdir=mozilla/embedding/browser/activex/src/plugin&command=DIFF_FRAMESET&rev1=1.35&rev2=1.36 Perhaps the CComVariant constructor in the call is confusing it or perhaps something else. I'm also trying to determine what build flags and other settings were used in producing the faulty build to see if it is a specific issue with the build environment.
Well, I've tried and tried again to reproduce this locally and have not managed it. I spoke to Loan Pham about the mozconfig settings being used, the compiler version, the clobber / incremental settings and as far as I know my local build configuration is identical yet I still can't reproduce the problem. I have just completed a clean fetch and build from scratch using the same mozconfig and have uploaded it to http://blues.netscape.com/users/adamlock/publish/mozilla_ax4.zip Ashish can you test this and see if it works better than the build machine? I'll attach the mozconfig to this bug next.
Attached file mozconfig —
OK, so there is something wrong in the build machine, I do not get the illegal operation dialog with this build
Attached patch Patch — — Splinter Review
This patch works for Ashish. It fixes two potential issues, that may be tripping up compilers with certain headers or patch levels: 1. Moves the decl of CComVariant out of the call to AddNamedProperty 2. Renames variable 'i' to 'j' as there is another 'i' in the class.
Comment on attachment 120585 [details] [diff] [review] Patch Requesting r/sr on this simple patch that fixes some machines that build plugins that crash.
Attachment #120585 - Flags: superreview?(alecf)
Attachment #120585 - Flags: review?(dbradley)
Comment on attachment 120585 [details] [diff] [review] Patch r=dbradley Silly compilers.
Attachment #120585 - Flags: review?(dbradley) → review+
Comment on attachment 120585 [details] [diff] [review] Patch sr=alecf
Attachment #120585 - Flags: superreview?(alecf) → superreview+
Fix is checked in. Reopen the bug if the problem persists. Ashish, can you do me a favour and run this command from your DevStudio\VC98\ATL\Include directory? FOR %f IN (*.h) DO @md5sum %f My results are below: 9063104c36a02ece5c02abf8e4a90ced *ATLBASE.H 1430ed90f8c285d63f94350acfb7c50c *ATLCOM.H ed301bbfac602eafb573a82a08448fde *ATLCONV.H e574c4a9914e40e14287c6077b08aae2 *ATLCTL.H 1fbc47f696032f3018b8c7c9686dc9fc *ATLDB.H 68b4b5ac3f860de3407cf2fa12261919 *ATLDBCLI.H 6bb21abbf97689555ef0e919a2f15a59 *ATLDBSCH.H 201bce787c60c10bd87c440787503392 *ATLDEF.H ac5f243fe8c60355120c4e2c6e07d7c3 *ATLHOST.H 35692cf18c943ca79277a7c0fee89e69 *ATLIFACE.H cd44d8ffe983f6e8427c851f38a6ddaa *ATLSNAP.H e2c742f9ca1d1e79fcb29c003300605a *ATLWIN.H e405b717ddcf339d4fae6bb8ef24a26b *STATREG.H
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
From my machine Which has visual studio.net installed a28868d027a95a4475c178c7db511fd8 *ATLBASE.H a2bc73deb54e70f44b2dece511003231 *ATLCOM.H ed301bbfac602eafb573a82a08448fde *ATLCONV.H e574c4a9914e40e14287c6077b08aae2 *ATLCTL.H f17bb9261f1554a9d860c60651f04e13 *ATLDB.H 9d925415dd8d79b25777cef7de039251 *ATLDBCLI.H 05b42a7b4c311a067f140150aa908e49 *ATLDBSCH.H 201bce787c60c10bd87c440787503392 *ATLDEF.H ac5f243fe8c60355120c4e2c6e07d7c3 *ATLHOST.H 35692cf18c943ca79277a7c0fee89e69 *ATLIFACE.H cd44d8ffe983f6e8427c851f38a6ddaa *ATLSNAP.H e2c742f9ca1d1e79fcb29c003300605a *ATLWIN.H e405b717ddcf339d4fae6bb8ef24a26b *STATREG.H From the machine where I did the optimized build 9063104c36a02ece5c02abf8e4a90ced *ATLBASE.H 1430ed90f8c285d63f94350acfb7c50c *ATLCOM.H ed301bbfac602eafb573a82a08448fde *ATLCONV.H e574c4a9914e40e14287c6077b08aae2 *ATLCTL.H 1fbc47f696032f3018b8c7c9686dc9fc *ATLDB.H 68b4b5ac3f860de3407cf2fa12261919 *ATLDBCLI.H 6bb21abbf97689555ef0e919a2f15a59 *ATLDBSCH.H 201bce787c60c10bd87c440787503392 *ATLDEF.H ac5f243fe8c60355120c4e2c6e07d7c3 *ATLHOST.H 35692cf18c943ca79277a7c0fee89e69 *ATLIFACE.H cd44d8ffe983f6e8427c851f38a6ddaa *ATLSNAP.H e2c742f9ca1d1e79fcb29c003300605a *ATLWIN.H e405b717ddcf339d4fae6bb8ef24a26b *STATREG.H
Hmm, ATL headers seem the same. Loan sent me a list of checksums for the standard SDK headers and there were some minor differences to mine. Frankly I'm stumped as to the cause. We'll have to wait and see if the patch makes a difference.
Todays build seems to work, so I guess the problem has been solved. Ashish, can you verify please? Thanks
Verified on 2003-04-16
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: