Topic: exceeded maximum number of selection sets

[rkmcswain]

I have a couple of users who get "exceeded maximum number of selection sets" at some point during the day, and of course functions that need selection sets fail from that point on until AutoCAD is restarted.

I know about the various fixes that supposedly clear this up, but I'm interested in finding the cause. These two users are two of many identically configured users, so they must be running some certain command or set of commands that is causing this problem...

Other than turning on the AutoCAD log file and inspecting it afterwards, any thoughts on how to track down the culprit program?

[MP]

For tracking down the culprit program I'd analyze the atoms-family before and after execution of programs.

Edit: This post (and others in the thread) may help.

To cleanup the following may help. Quick and dirty --

Code: [Select]

(defun c:PurgeSelectionSets ( / picksets )

    (foreach pickset
   
        (setq picksets
            (vl-remove-if-not
               '(lambda ( symbol ) (eq 'pickset (type (eval symbol))))
                (atoms-family 0)
            )
        )   
       
        (princ
            (strcat
                "Purging <"
                (vl-symbol-name pickset)
                ">\n"
            )
        )
       
        (set pickset nil)
       
    )
   
    (princ
        (strcat
            "Purged "
            (itoa (length picksets))
            " selection set(s)."
        )
    )
   
    (princ)

)
You can use the following to max out the selection sets for testing --

Code: [Select]

(   (lambda ( / prefix suffix )

        (setq prefix "ss" suffix 1000)
       
        (princ
            (strcat "Error <"
                (vl-catch-all-error-message
                    (vl-catch-all-apply
                       '(lambda ( )
                            (while t
                                (set
                                    (read
                                        (strcat prefix
                                            (itoa
                                                (setq suffix   
                                                    (1+ suffix)
                                                )
                                            )
                                        )
                                    )
                                    (ssget "x")
                                )
                            )
                        )   
                    )
                )
                ">"   
            )
        )   
       
        (princ)
    )
)
See sig.

[rkmcswain]

As luck would have it, the #1 command that is complained about when this happens is MATCHPROP.
Clearing the selection sets does not fix this command, you still have to shutdown and restart.

It *does* however allow lisp files that use (ssget) to work again....

Thanks for the code. Still looking into this....

In the first case where I have a log file to examine, the user was only in this particular drawing for 6 minutes. No lisp code was executed in this time. Here is what he ran in those 6 minutes

LAYISO
LAYUNISO
MATCHPROP
STRETCH
ERASE
BHATCH
LIST
PLINE
OFFSET
DIST
LINE
BREAK
EXPLODE
FILLET

[MP]

As luck would have it, the #1 command that is complained about when this happens is MATCHPROP. <snip> Here is what he ran in those 6 minutes -

LAYISO
LAYUNISO
MATCHPROP
STRETCH
ERASE
BHATCH
LIST
PLINE
OFFSET
DIST
LINE
BREAK
EXPLODE
FILLET

And so thusly underscores my comments here (8th sentence) and here (2nd sentence) ad nauseum.

Best of luck Mr. McSwain.

[rkmcswain]

LAYISO
LAYUNISO
MATCHPROP

So it sounds like what you are trying to say (without actually coming out and saying it...) is that the above three commands are poorly written and if my user quits using them, the problem will go away....?

[MP]

LAYISO
LAYUNISO
MATCHPROP

So it sounds like what you are trying to say (without actually coming out and saying it...) is that the above three commands are poorly written and if my user quits using them, the problem will go away....?

Sorry, didn't meant to be obtuse; I suppose that's my style sometimes.

Let me be more direct: Many Autodesk authored utilities, especially of the Express tools variety, are poorly written. Use at your own risk and peril.

[rkmcswain]

Sorry, didn't meant to be obtuse; I suppose that's my style sometimes.

Let me be more direct: Many Autodesk authored utilities, especially of the Express tools variety, are poorly written. Use at your own risk and peril.

Ok - so you think the LAYISO and LAYUNISO, etc were moved into core AutoCAD without being debugged more carefully ?

[LE]

I do not use the express tools... but if those tools are now ObjectARX or any partial - I will guess that they at least make sure to free the selection sets - that's one of the first main rules one have to follow, when getting into ARX or C++.

But, won't put my hands on fire for them...


a quote from the arx help and it is basically the same as in the lisp help too...

You must release the allocated selection set after you are finished with processing the selection. If you fail to do this the selection set will be kept on the stack until AutoCAD terminates. Since AutoCAD can only hold 128 application-based selection sets per session, the unreleased selection sets can result in failed object selections through ObjectARX.

added:

Also the class AcDbMatchProperties is being part of the arx for quite a while now, and what ever the base command done by Phil Kreiker on his original code for PAINTER later became MATCHPROP - it is nothing left about that.

[rkmcswain]

I do not use the express tools...

These are not express tools, these are core AutoCAD commands.

Also, I'm beginning to wonder if the error message in the title wasn't just a coincidence - because I can run the code provided by MP on the system when the problem occurs and there is never too many selection sets. Not to mention that the user wasn't even in the drawing long enough to create 127 selection sets (unless the code is doing some creative stuff....)

[MP]

Autodesk's ineptitude is not limited to lisp. For example, and if I recall correctly, selection set memory management is pooched on solprof, and even though Autodesk has acknowledged as much in direct communications, I believe it remains pooched.

[MP]

Well, looks like I need to eat me words: A cursory check under 2008 suggests solprof's selection set problem may be licked. Good on ya Autodesk.

[LE]

These are not express tools, these are core AutoCAD commands.

LAYISO and LAYUNISO were express tools - they just added to the core commands.

My comment was in general - I know does not help at all

[rkmcswain]

Well - I still have one user with this problem. Every 30 minutes or so....

One new piece to the puzzle. When the error occurs, it affects EVERY open drawing file, even the "drawing 1.dwg" where DBMOD=0.

I was under the impression that each open document had it's own lisp environment. Do selection sets span this barrier?

Iterating the (atoms-family) list for PICKSET atoms results in nothing. There are none.

Any more thoughts....?

[T.Willey]

How did you iterate the atoms family?  Here is what mine returns

(
    (PICKSET . 1)
    (REAL . 3)
    (VLA-OBJECT . 1)
    (VLR-Command-Reactor . 4)
    (LIST . 158)
    (STR . 52)
    (SUBR . 6624)
    (INT . 884)
    (EXRXSUBR . 291)
    (SYM . 8286)
)

With this code.

Code: [Select]

(foreach i (atoms-family 0)
    (setq iType (type (eval i)))
    (if (setq tempList (assoc iType TypeList))
        (setq TypeList (subst (cons iType (1+ (cdr tempList))) tempList TypeList))
        (setq TypeList (cons (cons iType 1) TypeList))
    )
)


[Jeff_M]

Just passing through with a quick thought, although I don't recall if ActiveX SS's are held, or add, to the 127 limit....this will give you list of a count of all ActiveX SS's in each open drawing.

Code: [Select]

(vlax-for doc (vla-get-documents (vlax-get-acad-object))
  (setq allSS (cons (vla-get-count (vla-get-selectionsets doc)) allSS))
  )