Process>>deepCopy can crash image

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Process>>deepCopy can crash image

Carsten Haerle
We had problem which corrupted the image memory and crashed the VM, when
using #deepCopy to copy some an instance. I found out that this was due to
copying a Process which then startet copying the InputState with all
windows, which contained some ActiveX controls.

Not only the copy was really slow, but also the image memory was corrupted
after that. Short time after the copy the VM crashed with in invalid read at
some location.

May be deep copying a Process should be completely disabled by overriding
#_deepenShallowCopy:trail: in Process to do nothing?

Regards

Carsten


Reply | Threaded
Open this post in threaded view
|

Re: Process>>deepCopy can crash image

Bill Schwab-2
Carsten,

> May be deep copying a Process should be completely disabled by overriding
> #_deepenShallowCopy:trail: in Process to do nothing?

I'll defer to OA for the official answer, but it reminds me of the old joke:

Patient: It hurts when I raise my arm like this (demonstrating)
Doc: Don't do that.

What motivated you to copy a process?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Process>>deepCopy can crash image

Bill Schwab-2
Carsten,

> What motivated you to copy a process?

Was the problem that you were holding a reference to a process in something,
and copied the something?  A good workaround might be to use

    Object fromBinaryStoreBytes:something binaryStoreBytes

to copy the object, because Processes override to nil for STB.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Process>>deepCopy can crash image

Carsten Haerle
Yes, of cause we didn't try to copy a process directly, but copied an object
which had a reference to a process. As there is already a method deepCopy, I
would prefer using this method instead of first serializing and
deserializing. It should also be much faster.

Regards

Carsten

"Bill Schwab" <[hidden email]> schrieb im Newsbeitrag
news:buougu$kjarj$[hidden email]...
> Carsten,
>
> > What motivated you to copy a process?
>
> Was the problem that you were holding a reference to a process in
something,

> and copied the something?  A good workaround might be to use
>
>     Object fromBinaryStoreBytes:something binaryStoreBytes
>
> to copy the object, because Processes override to nil for STB.
>
> Have a good one,
>
> Bill
>
> --
> Wilhelm K. Schwab, Ph.D.
> [hidden email]
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Process>>deepCopy can crash image

Blair McGlashan
"Carsten Haerle" <[hidden email]> wrote in message
news:bup6g1$qmu$01$[hidden email]...
> Yes, of cause we didn't try to copy a process directly, but copied an
object
> which had a reference to a process. As there is already a method deepCopy,
I
> would prefer using this method instead of first serializing and
> deserializing. It should also be much faster.

#deepCopy is only really of use in strictly controlled circumstances where
you know the extent of what will be copied (and can you ever know that for
sure?). Frankly you are much better off providing a specific #copy
implementation on your classes that copies just those objects that need to
be copied. The #copy implementation added to Process itself by the
continuations package is a case in point - it creates a copy of the current
state of a process such that it can be resumed at a later date,
independently of the original.

Regards

Blair