Closed Bug 201097 Opened 21 years ago Closed 21 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: 21 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: