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

[cadffm]

>>"Come on man, this is an egregious and inexcusable bug."

LOL (LOL, because of i don't like to cry at this moment).

But read my first answer.

This bug (i also not know "the rule behind") is not an important problem because of it is just a problem with the output to the textscreen/commandline.

Internal it works without a problem.

(Real programs: Not a problem, plaing in the commandline , unexplained ÷ ERRORS)

PS: I never rwad in the past an technical answer from Adesk.

[honkinberry]

Wow, that is a very easy way to generate the error. Yikes.
What is really bad about it, is that I’ve found AutoCAD gets very unstable once you generate that access violation.

[honkinberry]

It is a problem, because as I mentioned, it renders the Lisp Variable capability of Fields not only unusable, but extremely dangerous due to AutoCAD crashing suddenly.

[cadffm]

Oh, the FIELD thing was new to me and now i have to change my answer a bit (sorry please).

---

@cadffm wrote:

Important is that it is just an output problem,*

output to vlide console or to an external file is not a problem, only toe the text screen/commandline.

---

* One Exception: The FIELD command. If you run such code (where the error appears when the output

comes to the Textscreen),

the FIELD/LispVariable will crash, also if you run the code in the vlide or inside a function, or

with external output or without output.

Wow, this is new to me and this knowledge shifts the problem a level higher.

Thanks for shareing.

Let us wait the next 20 years (ok, not all Lisp programmer have so much time left, i know),

perhaps Autodesk fix it in the future 😂

The Level of 'how important',  i mean. The degree of strange is the final stage anyway.

[john.uhden]

Hey! I've got at least 2.0 years left!

[cadffm]

And now i have to change half of my whole statement.

Output to textscreen vs. vlide, external target or without an output - that looks correct,

also with the field other Lisp Variables thing, because (guessing) the dialog evaluates all LspVariable first.

But now, the next thing...much more important then the field command, for no reason of evaluating variables:

Run a sequence that makes trouble, take my  (setq a '((105 . 1)(106 . 2))) and insert it to the commandline

<you see the >

and now start the NEW command, select a template and...CRASH (correct?)

the same is with a simple (gc) instead the new command -> CRASH.

a n d   s o   o  n

😐

[honkinberry]

EXACTLY.

It is a very dangerous access violation error. The whole system becomes wildly unstable.

[dgorsman]

Given that this happens with lists, primarily dotted pairs.  And given this happens with leading integers, not reals.  And given the lists are fine, except when referencing them to fields.

There is something in the back end of field handling that is interpreting dotted pairs or lists with a leading integer, as DXF encoded dotted pair.  Certain DXF codes are expecting certain value types; when it's coded to use a string or bool and finds an integer instead it chokes.  Some of the lower DXF codes have special meanings, such as ( 5 . _HANDLEVALUE_ ), passing a random integer may result in improper use and another choke.

[cadffm]

If you mean field = command field? Then no, it has nothing to do with variables/symbols.

There is a more general routine implemented.

1. Fields are younger than the bug

2. Command NEW or (gc) has nothing to do with field(command).

3. You can use my sample without binding the list to a symbol or set the symbol to nil before you open field, or use command new, the crash comes.

4. If we want to guess: There is a generally predicade function with a problem.

 I like to know how old it is.

2.1 / 1985?

2.18 ?

R14/2000 with Vlisp? 

Is someone here who can check this in R13 or older?

The problem appears only for "valid" AutoLISP Entity property lists,

not if the list isn't a valid list for entity properties.

(Can we change the language of discussion to german? LOL, Sorry to all of you 😞 )

[ronjonp]

@cadffm 

That's crazy...

Command: (setq a '((105 . 1)(106 . 2)))
((105 . 1) (106 . 2))
; error: Exception occurred: 0xC0000005 (Access Violation)

[john.uhden]

Albeit you have your parentheses messed up, it is still crazy...
Command: (setq a (list '(105 . 1)'(106 . 2)'(105 . 1) '(106 . 2)))
((105 . 1) (106 . 2) (105 . 1) (106 . 2))
; error: Exception occurred: 0xC0000005 (Access Violation)

But maybe because I had errored out on yours first, as in the error lingers?

[ronjonp]

@john.uhden  How are the parenthesis messed up? 

[john.uhden]

@ronjonp wrote:
Command: (setq a '((105 . 1)(106 . 2)))
((105 . 1) (106 . 2))) ; end setq

red is wrong, and blue is right.

At least that's what I think you had intended.

[ronjonp]

@john.uhden my post was just the print out to the command line using the setq. 

[john.uhden]

My apologies then. I wasn't aware that the print out would scramble
parentheses.

[cadffm]

Are you sure to understand?

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

Only the green part is what he/you send into the commandline,

the rest of the picture is the feedback from AutoCAD.

There is no scrambled paranthese, nowhere.

Command: !'((210 0 0 "A")) ; not a valid entity property dottedpair, no problem

Command: !'((210 0 1)) ; not a valid entity property dottedpair, no problem

Command: !'((210 1 2 3 4)) ; not a valid entity property dottedpair, no problem

Command: !'((299 0 0 1)) ; not a valid entity property dottedpair, no problem

Command: !'((210 0 0 1)) ; it IS a valid entity property dottedpair, -> Error, and when you use NEW or the Field sample above -> Crash.

[john.uhden]

Yes. That was stupid of me not to see.

[john.uhden]

I was thinking that AutoCAD is verifying the correctness of the dxf code.

But I just tried something in 2002 that looks very wrong, but no errors...

Command: (setq a '((1 . 1)(62 . "A")(5 . 234)))
((1 . 1) (62 . "A") (5 . 234))

I dunno.  It IS just stupid.

[cadffm]

The problem appears by valid entity list, (1 . 1) isn't ?

[john.uhden]

Well, (setq a '(1 . 1)) is not a problem on my Win7 laptop in both vanilla
2002 and C3D 2016.