iexplorer halts on exit when ActiveXObject has been used

[Simon]

Hi,

I have written an ActiveX object to resize images and upload them to a
database, this all works fine but when I close internet explorer the
process iexporer.exe is still running in my task manager and I can not
launch anything from the desktop (eg. a web shortcut) without firt
killing this process. The object is launched using JScript with the
following code:

var Launcher = new ActiveXObject("LaunchControl");
Launcher.Domain = document.domain;
Launcher.LaunchImageUpload();
Launcher = null;

Why is the process still hanging around? I think I've covered disposing
of all resources used in the ActiveX object (which is a C# windows form
registered for com interop and installed in the GAC).

Any help would be much appreciated.

Simon

 

[VK]

I have written an ActiveX object to resize images and upload them to a
database, this all works fine but when I close internet explorer the
process iexporer.exe is still running in my task manager and I can not
launch anything from the desktop (eg. a web shortcut) without firt
killing this process.

An error in your ActiveX control, and based on the description a nasty
one (with is bad) but somewhere at the top level (which is good .
Consult at microsoft.public.dotnet.languages.csharp

JScript is not to blame.

 

[Patient Guy]

Hi,

I have written an ActiveX object to resize images and upload them to a
database, this all works fine but when I close internet explorer the
process iexporer.exe is still running in my task manager and I can not
launch anything from the desktop (eg. a web shortcut) without firt
killing this process. The object is launched using JScript with the
following code:

var Launcher = new ActiveXObject("LaunchControl");
Launcher.Domain = document.domain;
Launcher.LaunchImageUpload();
Launcher = null;

Your problem is setting Launcher to null. You created Launcher with an
ActiveXObject constructor using the 'new' operator.

The way to dispose of the object is to use its destructor, which is the
'delete' operator:

delete Launcher; // in place of Launcher = null;

Some might argue to leave well enough alone, and let the garbage
collection process take care of de-allocating memory and processing
involving the object.

But it is probably the careful programmer who tries to match each 'new'
with a 'delete' somewhere, within the same scope if possible, but at least
somewhere in code. It's the old malloc/free code-checking problem to
avoid memory leaks or processes that refuse to go away.

I cannot explain what happens when the object is set to 'null,' and I
would love to know just what is happening, for it might explain what you
are observing.

 

[Patient Guy]

Your problem is setting Launcher to null. You created Launcher with
an ActiveXObject constructor using the 'new' operator.

The way to dispose of the object is to use its destructor, which is
the 'delete' operator:

delete Launcher; // in place of Launcher = null;

I have to follow up to my own post unfortunately, because I am sure I will
get upbraided by a few hair-splitters for an improper use of terms here.

I checked with some sources regarding what exactly 'new' and 'delete' are.
They are simply whatever mechanism the "system" (being a Javascript
interpreter in this case) uses for allocating and de-allocating memory.
Although I never said the 'new' operator was a constructor, it does work
necessarily through a constructor, which as a function initializes the
allocated memory (I do not imply that initialization must involve the
setting of values of properties or methods of the object, or even the
naming of those properties or methods).

I did say that the 'delete' operator was a destructor, and I believe in
the most technical way, that is wrong. Again, it is merely the mechanism
internal to the system for de-allocating memory in the memory management
system. A destructor is a function which can be used to set values
(perhaps in global memory? or in other objects) and perhaps prepare an
object or object property for proper de-allocation, such as calling
'delete' on objects which themselves are properties of the object soon to
be 'delete'd.

There is a high probability now that more will be said, if only because I
expanded on my self-doubts here.

 

[Richard Cornford]

Patient Guy wrote:

I have to follow up to my own post unfortunately, because
I am sure I will get upbraided by a few hair-splitters for
an improper use of terms here.

I don't think we will be splitting hairs here, you are so far off the
mark that you have posted a fantasy of VKesque proportions.

I did say that the 'delete' operator was a destructor, and
I believe in the most technical way, that is wrong.

Yes it is. Given your proposal that - delete - operations should have a
one-to-one relationship with - new - operations I assume you are
viewing - delete - as directly (or actively) resulting in the
destruction of an object created with the - new - operator and assigned
to an object property or variable. I.E.:-

var something = new Somethong();

- and:-

delete something;

- would act upon the object resulting from the - new Something() -
expression. It does not. It acts upon the object in the scope chain on
which 'something' is a named property. The ECMA 262 algorithm for -
delete is:-

<quote cite="ECMA 262, 3rd Ed. section 11.4.1">
11.4.1 The delete Operator

The production UnaryExpression : delete UnaryExpression is
evaluated as follows:

1. Evaluate UnaryExpression.
2. If Type(Result(1)) is not Reference, return true.
3. Call GetBase(Result(1)).
4. Call GetPropertyName(Result(1)).
5. Call the [[Delete]] method on Result(3), providing Result(4) as
the property name to delete.
6. Return Result(5).
</quote>

The UnaryExpression evaluated in the first step (in - delete
something; - following - var something = new Something() is the
unqualified Identifier - something -, which is resolved against the
scope chain in accordance with ECMA 262 (assume 3rd edition from now on)
Section 10.1.4, which always produces a Reference type, so step 2 is
fine. Step 3 retrieves the 'Base' object from that Reference type, which
is either the global object (if the variable was declared in the global
scope) or is a Variable object (if it is a function local variable).

The property named retrieved in step 4 is the string "something", and so
step 5 calls the internal [[Delete]] method of the global/variable
object, passing "something" as the name of the property to delete. The
algorithm for - [[Delete]] is:-

<quote cite="ECMA 262, 3rd Ed. section 8.6.5">
8.6.2.5 [[Delete]] (P)

When the [[Delete]] method of O is called with property name P, the
following steps are taken:

1. If O doesn't have a property with name P, return true.
2. If the property has the DontDelete attribute, return false.
3. Remove the property with name P from O.
4. Return true.
</quote>

So you might expect that the property of the global/Variable object with
the name "something" will be removed from the global/Variable object.

Now the property of the global/Variable object with the name "something"
had been assigned a value that is a reference to the object created
with - new Something() - so the act of removing the property from the
global/variable object will remove that reference from the system. This
is where memory management does come into the picture. Javascript uses
automatic garbage collection and when there are no longer any accessible
references to an object that object becomes eligible from garbage
collection (at some undeterminable future time). If the "something"
property of the global/Variable object was removed it would no longer
refer to the constructed object, and if its value had been the only
reference to that object then that object becomes available for garbage
collection.

However, step 2 in the [[Delete]] algorithm checks to see if the
property that is to be deleted has the internal DontDelete attribute,
and if it does is does not act (the property is not removed).

The "something" property of the global/Variable object was created as a
result of a variable declaration, subject to sections 10.1.3, 10.2.1 and
10.2.3 of the specification, where we find:-

<quote cite="ECMA 262, 3rd Ed. section 10.2.1">
10.2.1 Global Code
....
Variable instantiation is performed using the global object as the
variable object and using property attributes { DontDelete }.
....
</quote>

<quote cite="ECMA 262, 3rd Ed. section 10.2.3">
10.2.3 Function Code
....
Variable instantiation is performed using the activation object as
the variable object and using property attributes { DontDelete }.
....
</quote>

- and see that the DontDelete attribute is set on all declared global
and function local variables (except those declared within an - eval -
function call).

And so given:-

var something = new Something();

- doing:-

delete something;

- will be ineffective, it will not result in the removal of the property
of the global/Variable object, and so it will not result in the removal
of the value of that property that refers to the object constructed
with - new Something() -, and while the reference to the object remains
the constructed object cannot be garbage collection, and will continue
to consume memory. Thus the proposal that - delete - should be used in
order to free references to objects so that their memory could be
released during garbage collection is almost the reverse of good advice.

Indeed, because the "something" property has a value that is a reference
to an object, the act of assigning a different value to that property
will result in the removal of the pre-existing reference from the
system, reliably. And so:-

something = null;

- is a better alternative because it will prevent - something - from
referring to the constructed object.

There is a high probability now that more will be said,
if only because I expanded on my self-doubts here.

;-)

Richard.

 

[Simon]

Thanks for all the replies.

I have to say I don't completely understand the last post but I have
tried using the 'delete' keyword and combinations of 'delete' and ' =
null;' to no avail.

Having had some time to think more about this, it's my impression the
iexplorer.exe process is blocking for some reason when Internet
Explorer is closing as I can use the rest of my application fine even
after opening and closing the ActiveX object. It seems as IE tries to
close the ActiveX object is not letting go (technical term

The ActiveX code in object looks like this;

public void LaunchImageUpload()
{
using (FormPhotoUpload _FormPhotoUpload = new
FormPhotoUpload(_Domain))
{
_FormPhotoUpload.ShowDialog();
}
}

Because this is a modal dialog can it be keeping a reference to the
parent window (IE) which is not released?

I will probably have to follow VK's advice and post on
microsoft.public.dotnet.languages.csharp to solve that side of things.
Although I have a test page which will close IE fine and it is just;

<html>
<head>
<script language="javascript">
var Launcher = new ActiveXObject("LaunchControl");
Launcher.Domain = "localhost";
Launcher.LaunchImageUpload();
</script>
</head>
<body>
</body>
</html>

Thanks again for taking the time to help with this.

Simon

 

[Arnaud Diederen]

I must admit, I've been coding in JS for a while now, but didn't
really understand the difference between:

-----------------------
xx = new Object ();
-----------------------

and

-----------------------
var xx = new Object ();
-----------------------

I found your post very informative, thank you!

Best regards,
Arnaud

 

[VK]

If you don't find any use for or of the operator 'delete', why would it be
proposed in the language specification?

Well, actually it was introduced by Netscape to *delete* custom
properties from objects, one release after they gave the ability to
*add* custom properties to host objects (originally to window only).
And it was long before the modern OOP tools ;-)

So instead of creating a bunch of global vars (especially if you
couldn't know in advance their exact amount) you extended window:
window['foo'] = 1; window['bar']=2 etc.

Now any kid can do var myObject = {'foo':1, 'bar':2}; but Object()
constructor came only later, plus the *thinking* itself in such terms
had to be invented and learned yet.

Nevertheless what is "delete" now, and how does it affect on memory
management is irrelevant to the history.

I just see that you're taking JavaScript way too C'ish while it is
mostly Java'ish. You cannot directly destroy objects because you don't
have an explicit destructor and you have no real memory access. You can
only delete references - by using delete operator or by the old "kill
Kenny" method objReference = null (or even more nasty objReference =
undefined). The object memory heap by itself remains in any
circumstances: unnamed and unreferenced, waiting for the garbage truck.

Also in IE window / document properties implement the unfamous slogan
"Once in - never out": you can window['foo'] = 1; but you cannot delete
window.foo

This way the original purpose of "delete" is lost anyway, so feel free
to use it wherever it helps.

 

[Richard]

Actually not, if you read my post carefully.

I did read your post carefully, how carefully did you read mine?

I said that the 'new' and 'delete' operations were intended
to invoke a memory management mechanism in the system whose
internal workings are left to the implementor.

Yes you did, which is what I have paraphrased above. specifically
relating to - delete - you use the term "invoke", and that implies
direct (or active) object destruction in the context of what you have
written.

Do these operations ALWAYS----must they always--- involve the
use of construction and destruction, or the use of a function
that is a constructor and destructor, respectively. One gets
into trouble---especially here---if they assert with "epistemic
certainty" that all new operations involve constructors and
delete operations involve an uncalled-in-code destructor.

In javascript all functions are capable of being used with the new
operator and are, in a sense, constructors (that is, they all implement
the internal [[Construct]] method). Functions that return objects
cannot effectively be used as a constructor for new objects, but all
other functions can (including functions that return primitive values).
And if the operand of the - new - operator is not a function then an
exception is thrown, so all non-erroring uses of the - new - operator
will involve a functions (which is effectively a constructor by virtue
of being a function).

All operations using - delete - certainly do not involve destructors,
except as a possible side-effect consequence of the action of the
delete operator.

The var 'something' is a reference to the object created by use
of a constructor call Something.

Clearly the operation

delete something;

UNDOES what the 'new' operation

No, that is not what the delete operator does at all.

(you can argue about the details of the
implementation) did to create that object.

There is no question of what the implementation does, what is important
is what the delete operator does.

delete something;

says, "take the object that you refer to and de-allocate its
memory...no further reference to the object or any of its
properties is intended."

Not in javascript. In javascript - delete - says; resolve the operand
to a Reference type and remove the named property from the Reference
type's base object (assuming that the operand did resolve as a
Reference type and the property is not marked DontDelete).

If I said or otherwise implied that properties to the 'delete'd
object which themselves are references to other objects and are
'delete'd as part of the delete operation, then that is not the
case. However, I don't believe I ever said that.

You did not say that, it was what you did say, and have repeated, that
I am correcting.

If you are trying to make the case that the object referenced
by 'something' is somehow distinct from the object returned
by the 'new Something();' call, then please re-iterate this,
and with perhaps a very clear demonstration of proof.

I am not trying to make that case. I am quote happy to assume that
there have been no modifications to the value of - something -
in-between the assignment of the reference to the constructed object
and the application of the - delete - operator upon - something -.

The ECMA 262 algorithm for -
delete is:-

<quote cite="ECMA 262, 3rd Ed. section 11.4.1">
11.4.1 The delete Operator

The production UnaryExpression : delete UnaryExpression is
evaluated as follows:

1. Evaluate UnaryExpression.
2. If Type(Result(1)) is not Reference, return true.
3. Call GetBase(Result(1)).
4. Call GetPropertyName(Result(1)).
5. Call the [[Delete]] method on Result(3), providing Result(4) as
the property name to delete.
6. Return Result(5).
</quote>

The UnaryExpression evaluated in the first step (in - delete
something; - following - var something = new Something() is the
unqualified Identifier - something -, which is resolved against the
scope chain in accordance with ECMA 262 (assume 3rd edition from now on)
Section 10.1.4, which always produces a Reference type, so step 2 is
fine. Step 3 retrieves the 'Base' object from that Reference type, which
is either the global object (if the variable was declared in the global
scope) or is a Variable object (if it is a function local variable).

The property named retrieved in step 4 is the string "something", and so
step 5 calls the internal [[Delete]] method of the global/variable
object, passing "something" as the name of the property to delete. The
algorithm for - [[Delete]] is:-

<quote cite="ECMA 262, 3rd Ed. section 8.6.5">
8.6.2.5 [[Delete]] (P)

When the [[Delete]] method of O is called with property name P, the
following steps are taken:

1. If O doesn't have a property with name P, return true.
2. If the property has the DontDelete attribute, return false.
3. Remove the property with name P from O.
4. Return true.
</quote>

So you might expect that the property of the global/Variable object
with the name "something" will be removed from the global/Variable
object.

No, I don't.

That was a rhetorical 'you'. Someone reading the algorithms for -
delete - and the [[Delete]] method of Objects quoted from the
language's specification, and not thinking about the DontDelet
attribute, might expect - delete something; - to result in the removal
of a "something" property from whichever object on the scope chain had
such a property.

I expect the object that is referred to by 'something' to be
"removed" (deconstructed, destroyed, whatever).

And I am informing you that javascript's delete operator does not do
that, historically and by specification. Having directly quoted the
applicable algorithms from the specification I was not expecting you to
still be maintaining your fantasy at this point.

I don't believe anywhere in my previous posts did I ever contend
that a variable name 'something' is itself destroyed.

No, if you had maintained that you would have been correct, as that is
precisely what javascript's delete operator does (subject to the
DontDelete restriction).

"...remove that reference...."?

Or remove the object referred to?

No, it will only remove the reference. It is the garbage collectors
task to identify and remove freed objects.

Yes, and I don't believe I ever contended anything contrary
to that view.

You implied that the - delete - operator would act upon the object
created with - new Something(); - in a way that resulted in its
destruction. While the most the delete operator can do is remove
reference to that object so that it may become eligible for garbage
collection at some future time.

However, step 2 in the [[Delete]] algorithm checks to see if the
property that is to be deleted has the internal DontDelete
attribute, and if it does is does not act (the property is not
removed).

The "something" property of the global/Variable object was created
as a result of a variable declaration, subject to sections 10.1.3,
10.2.1 and 10.2.3 of the specification, where we find:-

<quote cite="ECMA 262, 3rd Ed. section 10.2.1">
10.2.1 Global Code
...
Variable instantiation is performed using the global object as
the variable object and using property attributes { DontDelete }.
...
</quote>

<quote cite="ECMA 262, 3rd Ed. section 10.2.3">
10.2.3 Function Code
...
Variable instantiation is performed using the activation object as
the variable object and using property attributes { DontDelete }.
...
</quote>

- and see that the DontDelete attribute is set on all declared
global and function local variables (except those declared within
an - eval - function call).

And so given:-

var something = new Something();

- doing:-

delete something;

- will be ineffective, it will not result in the removal of the
property of the global/Variable object, and so it will not result
in the removal of the value of that property that refers to the
object constructed with - new Something() -, and while the
reference to the object remains the constructed object cannot be
garbage collection, and will continue to consume memory. Thus the
proposal that - delete - should be used in order to free
references to objects so that their memory could be released
during garbage collection is almost the reverse of good advice.

Again, you seem to be making the argument that I contended that
the name by which to refer to the created object is somehow acted
upon the by 'delete' operation.

I am not saying that you contended it. I am saying that is how delete
works in javascript.

... . I never made the case that the 'delete' operation acts on
the identifier, but rather on what the identifier/variable refers to.

The delete operator acts upon the object on the scope chain for which
the Identifier is a named property. It _does_not_ not act upon the
object referred to by the value of that property.

You seem to be arguing against what I see to be the CLASSICAL
USAGE and PRACTICE of the 'delete' operator.

What do you consider the "CLASSICAL USAGE" of the delete operator in
javascript? The language's specification makes it very clear what that
operator is supposed to do; remove named properties from objects.

Exactly in what cases would you find it appropriate to use the
operator 'delete'?

When I wanted to remove a named property from an object (and knew that
the DontDelete attribute was not applicable to that property). I would
use the delete operator when I wanted to do what the operator does.

If you don't find any use for or of the operator 'delete', why
would it be proposed in the language specification?

<snip>

Who said I don't have any use for it. I certainly don't use it very
often, but it is extremely rare that I see any advantage in removing
named properties from objects.

Richard.