Stupid Lisp bug

[honkinberry]

This has driven me crazy for years, I can't believe it is still a thing.

(setq _test nil)
(setq i -1)
(repeat 256
  (setq i (1+ i))
  (setq _test (append _test (list (cons i i))))
) ; repeat

That should give you an immediate access violation error.

But better yet, then type FIELD, click on Lisp Variables, and AutoCAD doesn't just crash, it instantly and completely disappears.

Is this the equivalent of saying "Biggie Smalls" three times in the mirror?

--J

[ronjonp]

What version of CAD are you on? Does not crash 2021 here.

[honkinberry]

With 2021 when I go into the FIELD dialog and click on Lisp Variables, I get an immediate Access Violation error at the command line. You don’t?

[ronjonp]

---

@honkinberry wrote:
With 2021 when I go into the FIELD dialog and click on Lisp Variables, I get an immediate Access Violation error at the command line. You don’t?

---

Nope.

[Kent1Cooper]

I ran that [Acad2019] just for kicks.  For me, it does  give an access violation error, though after  making the entire list, if timing is part of your issue.

I did the Field thing, and yes, it crashed, but not  instantly and completely -- there was the "normal" stopped-working-checking-for-a-solution message, and a box that waited for me to pick on the "Close program" button.

I don't know what the violation is there -- it just makes a list of dotted pairs, and it gets to the end successfully, and returns the result as a completed list, as in lots of AutoLisp routines.  Access to what  has been violated?  Violated by what?

I tried again, and before doing the Field thing, just typed  !_test  to see whether it had saved it to the variable, at which it returned the list again [so yes, it had saved it], and  the access violation message also returned.

In any case, what would you use such a thing for?

[ronjonp]

@honkinberry I was able to replicate the crash opening fields / lispvariables using this:

(setq _test nil)
(setq i 256)
(repeat i (setq i (1- i)) (setq _test (cons (cons i i) _test))) ; repeat

[honkinberry]

Maintaining a list of color substitutions.

Can’t think of a programming language where you aren’t allowed to create such an array for fear of it crashing the entire system.

[ronjonp · Accepted solution]

---

@honkinberry wrote:
Maintaining a list of color substitutions.

Can’t think of a programming language where you aren’t allowed to create such an array for fear of it crashing the entire system.

---

@honkinberry  Very strange indeed. A quick test and if those values are stored as: (setq _test (cons (list i i) _test)) it does not crash.

[honkinberry]

I've tried many variations including that one that still crash.

I was about to convert it to Reals, which doesn't crash, but your post made me think of something!

(reverse)!

If it's 255 to 0, then it doesn't crash for me, and I can still assoc it.

So that's my temporary solution for now.

But this has been an issue for me since... I'm going to say probably 2004.  I originally posted about this around then, maybe it was 2006.

I just can't fathom how a list of this construction could possibly cause such an error.

--J

** edit, no, sorry, reversing it does still crash.

So the temporary solution for now is to have a list of Reals instead of Integers, which definitely does not crash.

[ronjonp]

Did you try the (list i i) ?

[honkinberry]

Yes, that still crashes for me.
As does having the first value be (-1 -1), etc.
The best simple solution I’ve found is reals, storing it as (0.0 0)

—J

[Kent1Cooper]

[EDIT:  now I see @ronjonp beat me to it in suggesting this....]

Here's an alternative that doesn't crash AutoCAD [for me], and  still uses integers instead of your workaround with real numbers [so in the case of color numbers, you won't need to convert back]:  Do little two-item "plain" lists instead of dotted pairs:
....

    (setq _test (append _test (list (list i i))))

....

You would simply need to use either:

  (cadr (assoc somenumber _test))

or:

  (last (assoc somenumber _test))

to get the second number from a given sub-list, rather than using  (cdr)  as you would with a dotted-pair sub-list.

[honkinberry]

That was actually the first thing I tried, and it still crashes on me.

Both that, and reversing the list, seem to crash *less*, but still crash.

Only by switching the index of each element to a Real, have I consistently seen no issues.

--J

[john.uhden]

Yep, does for me too in 2002.

I see no reason for it, except I thought maybe 256 was an unpassable limit.  So I tried it with 255... same error.  Even with 100, it errored out.  Nice work!

Yet, this does work (when localizing variables)...

(defun c:test (/ test i)
  (setq i -1)
  (repeat 256
    (setq i (1+ i))
    (setq test (append test (list (cons i i))))
  )
  (princ test)
  (princ)
)

I really don't get it.

[CADaSchtroumpf]

Indeed it is a very strange limitation ...

To me it seems to be 103, at 104 I have a violation!

((lambda ( / tmp i)
	(repeat (setq i 103)
		(setq
			i (1- i)
			tmp (cons (cons i i) tmp)
		)
	)
))

[dbroad]

Thanks for reporting this bug.  I hope the forum manager is passing this information up to the AutoCAD development team as I know they have had recent interest in improving LISP.

This suggestion for a workaround is essentially the same as @ronjonp  but it seems to work for me.  It works faster and the field dialog opens faster and doesn't report any errors.  Closing drawings and closing AutoCAD isn't a problem either.  (Tested with 2017 on Windows 7 with 32GB Ram)

(setq _test nil)
(setq i 256)
(repeat 256
  (setq i (1- i))
  (setq _test (cons (cons i (cons i nil)) _test))
) ; repeat

Unfortunately, you would need to use (cadr(assoc key# _test)) to get the value#

[honkinberry]

Apologies for not doing proper testing of this.

My best guess is that I still had a variable set as a dotted pairs when I tested the (list value value) method, hence why I kept getting access violation errors.

So agreed, this is the simplest workaround.

--J

[ronjonp]

@honkinberry What is your application for this list? Is it really made up of equal dotted pairs? 

I see you answered HERE.

This is a very strange bug indeed...

[honkinberry]

It’s a color substitution list.
There are 255 indexed colors. So this is the control list for converting from our standard to the user’s. The default has all values the same.
So when creating a layer, it checks this to see what color it should be made to match the user’s preferences.

But again, does that matter?
If I had a JavaScript array of the letters of the alphabet and it crashed a web browser, would you seriously ask me why I was creating such an array?
Come on man, this is an egregious and inexcusable bug.

[cadffm]

There is a problem with the output to Textscreen, min. 18 years, i guess 21years or longer.

Adesk know about the issue and nothing changed for 2 decades.

Important is that it is just an output problem,

output to vlide console or to an external file is not a problem.

A simpler sample:

!'((105 . 1)(106 . 2))

or

(setq a '((105 . 1)(106 . 2)))

One did a big mistake, perhaps im hurry, but nobody fixed it.

Report bugs, post ideas?

You can read well sounding posts from Adesk workers, but .. if you can not laugh, then cry.

And we could talk about it hours, weeks and years, Adesk will not fix the problems.

😞