2014 Huge ActiveX memory leak?

[dbroad]

Could some of you advanced users who actually use activeX objects include this command in your autoload and periodically test your status to see if memory leaks are happening to you like they are to me?  No matter what I do (localize variables, use vlax-relase-object, use the  garbage collector..) the reference count goes up and up and up.  After I've opened and closed 20 to 30 drawings and used activeX, I may have reference counts of 50 to 500 to 5000.  Eventually I need to restart autoCAD to clear the count and recover the space.

;;returns the quantity of unreleased references to the autoCAD object
;;as far as I can tell.
(DEFUN c:cref ()
  (GC)
  (VLAX-RELEASE-OBJECT (VLAX-GET-ACAD-OBJECT))
  )

 If I am off base, I'd appreciate learning that as well.  Thanks.

FYI: My system Windows 7, 64Bit

[dbroad]

Just to give you something to test, included is a small lisp that uses activeX and a drawing that would be modified by it.  After running c:tha, the cref count rises to 25 from 3.

Modify the lisp to uncomment out the vlax-release-object items.  You could even try saving the activeselectionset and then trying to release it. I am going to rewrite the function to avoid activeX for now but it points to a memory leak unless you guys can see the error of my ways.  Thanks.

[dgorsman]

Return value for (vlax-release-object ...) is "unspecified" so that is probably something for the dev team to look into.

I've popped several drawings open and closed, and while the return number does go up with drawing opened, it comes back down as they are closed.  After a few times the number seems to be creeping up (10, 11, 13 after two dozen or so drawings, new drawings, etc.) but not significantly so.

This might be a factor of which ActiveX objects are in use.  Most of mine are calling MSXML.

[dbroad]

To demonstrate the return value, see the following video.  Be sure to turn off the keyboard overlay to see the return values clearly.

[dbroad]

To demonstrate the growth of the number of references to the autocad object please see this video.  I apologize for not providing complete code for the thinneratt.lsp routine.  Please comment out these lines which call and use the results of (getdimscale) which was not provided.

	(progn
;;	  (setq ds (getdimscale))
;;	  (setq ht (* 0.085 ds))
	  (vla-put-scalefactor att 0.7)
;;	  (vla-put-height att ht)
      ))

[dbroad]

Well I've solved my immediate problem by rewriting the function to be non-activeX.  I still don't think the issue itself is closed as this function seems to have exposed a leak that can only be plugged by service pack, which is unlikely.  Thanks for the response.

;;D. Broad
;;Function scans the document for bubcirc block references that
;;have an attribute longer than 2 characters.  For those attributes
;;it adjusts the width factor to keep them from flowing out of the circle
;;removed activex methods 8/2/2014 due to memory leaks
;;main function - no arguments
(DEFUN thinneratt  (/ ss i ds ht ei)
  (IF (SETQ ss (SSGET "x" '((0 . "insert") (2 . "BUBCIRC"))))
    (PROGN
      (SETQ i 0)			;first element index
      (SETQ ds (getdimscale))		;dimension scale
      (SETQ ht (* 0.085 ds))		;smaller than usual height
      (REPEAT (SSLENGTH ss)
	(SETQ ei (ENTGET (ENTNEXT (SSNAME ss i)))) ;first attribute of block
	(IF (> (STRLEN (CDR (ASSOC 1 ei))) 2) ;only for long strings
	  (PROGN
	    (SETQ ei (SUBST (CONS 40 ht) (ASSOC 40 ei) ei)) ;shrink height
	    (SETQ ei (SUBST (CONS 41 0.7) (ASSOC 41 ei) ei)) ;condense width factor
	    (ENTMOD ei)			;modify attributes
	    ))
	(SETQ i (1+ i))			;next element
	))))
;;command wrap
(DEFUN c:tha () (thinneratt) (PRINC))

[kdub_nz]

Doug,

The increasing reference count for activeX objects has been known since VLISP was released.

It's not a Memory Leak as such, just product of ActiveX.

One way to eliminate the situation is to assign the reference to a variable and release the reference when finished.

There are several threads on this situation both here and at theSwamp.

Here's one from 10 + years ago

http://www.theswamp.org/index.php?topic=547.msg6844#msg6844 

and

http://www.theswamp.org/index.php?topic=7496.0

From the Docs ..
[quote][b]Performance Considerations [/b] :

Repeated calls to access the AutoCAD Application, active Document, and ModelSpace objects should be avoided, as they negatively impact performance. You should design your applications to obtain these objects one time, and refer to the obtained object pointers throughout the application. [/quote]

So theoretically, .. its better to assign it once and use the variable, rather than repeatedly burrow down into the Object Model.
[/quote]

[dbroad]

Kerry,

Thanks for the reply.  In the sample lisp I provided, there should have been only one instance of a reference to the autocad object and therefore at worst, it should have incremented the count one a single time (not by 25).  When the drawing was closed, the reference count should have been affected.  Garbage collection should have also been more effective.  I rewrote it once by assigning the selection set to a variable and then releasing that variable.  All the variables are local and should be self releasing.  Nothing referenced anything beyond the application itself.  Whether or not the activex objects are released, this little function indicates that pointers are being created and that memory is being consumed by those pointers.

 Looking at the resources that  AutoCAD consumes over time,  it appears that the continues to consume more and more RAM until the application needs to be restarted to remain responsive.  To me that is a memory leak.