Simplest way to crash AutoCAD

[honkinberry]

This occasionally bugs me like crazy, when I have to work on code having to do with layer colors.

It seems totally logical to me, that it might be handy to have an associative list of all possible layer colors.

As in ((1 . 1) (2 . 2) (3 . 3) ... (255 . 255))

But regardless if you feel that is useful, there is certainly no reason I shouldn't be able to create such a list, yes?

There's no reason the AutoLISP engine would not like that, the same is if I wanted a string variable of "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789".

It's my variable, I can do with it what I want, right?

So why does this crash AutoCAD?

(setq i 1)
(while (< i 256)
(setq mylist (append mylist (list (cons i i))))
(setq i (1+ i))
)

Okay, to be fair, *that* doesn't crash AutoCAD.  Only doing this afterwards:

!mylist

Or this:

(print mylist)

It's like some sort of AutoLISP Kryponite or something.

I don't suppose someone has a whimsical explanation for why this is?

Because it feels rather like saying Beetlejuice three times -- "Don't make an assoc list of the numbers 1 throuth 255!"

Oh, and sorry I didn't say this earlier -- be sure to save any important document before copying and pasting the above code.

Thanks for any assistance!

--J

[Kent1Cooper]

It doesn't crash AutoCAD for me.  After running that code, when I do !mylist, it prints out the list of dotted pairs exactly as one would expect it to look.  However, that is followed by:

; error: Exception occurred: 0xC0000005 (Access Violation)

so something is odd, but it doesn't crash.  I happen to be at my older-version location right now [ArchDesktop 2004, Windows XP], and couldn't say whether the difference might be related to version, or operating system, or hardware, or hardware acceleration if that's a possibility with your version.

Also oddly, and in case it provides any clue to someone, when I do (print mylist), it starts in the middle with:

(123 . 123) (124 . 124) ...

and carries across the end [including closing right parenthesis for the overall list] to starting again somewhere else in the middle [so some items occur more than once in what it prints]:

... (254 . 254) (255 . 255)) (152 . 152) (153 . 153) ...

and goes to the end again, and then starts at the beginning:

... (254 . 254) (255 . 255)) ((1 . 1) (2 . 2) ...

and finally finishes at the last item before where it first started:

... (121 . 121) (122 . 122)

followed by the same error message, but again, no crashing.

[honkinberry]

It crashes the AutoLISP engine hard.

If you then try to run any LISP code, you'll eventually get a complete crash.

--J

[dmfrazier]

With AutoCAD 2013, Win7 32bit, this is what I get, without "crashing":

Command: !mylist
((1 . 1) (2 . 2) (3 . 3) (4 . 4) (5 . 5) (6 . 6) (7 . 7) (8 . 8) (9 . 9) (10 . 10) (11 . 11) (12 . 12) (13 . 13) (14 . 14) (15 . 15) (16 . 16) (17 . 17) (18 . 18) (19 . 19) (20 . 20) (21 . 21) (22 . 22) (23 . 23) (24 . 24) (25 . 25) (26 . 26) (27 . 27) (28 . 28) (29 . 29) (30 . 30) (31 . 31) (32 . 32) (33 . 33) (34 . 34) (35 . 35) (36 . 36) (37 . 37) (38 . 38) (39 . 39) (40 . 40) (41 . 41) (42 . 42) (43 . 43) (44 . 44) (45 . 45) (46 . 46) (47 . 47) (48 . 48) (49 . 49) (50 . 50) (51 . 51) (52 . 52) (53 . 53) (54 . 54) (55 . 55) (56 . 56) (57 . 57) (58 . 58) (59 . 59) (60 . 60) (61 . 61) (62 . 62) (63 . 63) (64 . 64) (65 . 65) (66 . 66) (67 . 67) (68 . 68) (69 . 69) (70 . 70) (71 . 71) (72 . 72) (73 . 73) (74 . 74) (75 . 75) (76 . 76) (77 . 77) (78 . 78) (79 . 79) (80 . 80) (81 . 81) (82 . 82) (83 . 83) (84 . 84) (85 . 85) (86 . 86) (87 . 87) (88 . 88) (89 . 89) (90 . 90) (91 . 91) (92 . 92) (93 . 93) (94 . 94) (95 . 95) (96 . 96) (97 . 97) (98 . 98) (99 . 99) (100 . 100) (101 . 101) (102 . 102) (103 . 103) (104 . 104) (105 . 105) (106 . 106) (107 . 107) (108 . 108) (109 . 109) (110 . 110) (111 . 111) (112 . 112) (113 . 113) (114 . 114) (115 . 115) (116 . 116) (117 . 117) (118 . 118) (119 . 119) (120 . 120) (121 . 121) (122 . 122) (123 . 123) (124 . 124) (125 . 125) (126 . 126) (127 . 127) (128 . 128) (129 . 129) (130 . 130) (131 . 131) (132 . 132) (133 . 133) (134 . 134) (135 . 135) (136 . 136) (137 . 137) (138 . 138) (139 . 139) (140 . 140) (141 . 141) (142 . 142) (143 . 143) (144 . 144) (145 . 145) (146 . 146) (147 . 147) (148 . 148) (149 . 149) (150 . 150) (151 . 151) (152 . 152) (153 . 153) (154 . 154) (155 . 155) (156 . 156) (157 . 157) (158 . 158) (159 . 159) (160 . 160) (161 . 161) (162 . 162) (163 . 163) (164 . 164) (165 . 165) (166 . 166) (167 . 167) (168 . 168) (169 . 169) (170 . 170) (171 . 171) (172 . 172) (173 . 173) (174 . 174) (175 . 175) (176 . 176) (177 . 177) (178 . 178) (179 . 179) (180 . 180) (181 . 181) (182 . 182) (183 . 183) (184 . 184) (185 . 185) (186 . 186) (187 . 187) (188 . 188) (189 . 189) (190 . 190) (191 . 191) (192 . 192) (193 . 193) (194 . 194) (195 . 195) (196 . 196) (197 . 197) (198 . 198) (199 . 199) (200 . 200) (201 . 201) (202 . 202) (203 . 203) (204 . 204) (205 . 205) (206 . 206) (207 . 207) (208 . 208) (209 . 209) (210 . 210) (211 . 211) (212 . 212) (213 . 213) (214 . 214) (215 . 215) (216 . 216) (217 . 217) (218 . 218) (219 . 219) (220 . 220) (221 . 221) (222 . 222) (223 . 223) (224 . 224) (225 . 225) (226 . 226) (227 . 227) (228 . 228) (229 . 229) (230 . 230) (231 . 231) (232 . 232) (233 . 233) (234 . 234) (235 . 235) (236 . 236) (237 . 237) (238 . 238) (239 . 239) (240 . 240) (241 . 241) (242 . 242) (243 . 243) (244 . 244) (245 . 245) (246 . 246) (247 . 247) (248 . 248) (249 . 249) (250 . 250) (251 . 251) (252 . 252) (253 . 253) (254 . 254) (255 . 255))
; error: Exception occurred: 0xC0000005 (Access Violation)

Maybe this provides a clue (?).

If I repeat the code a few times (setting mylist back to nil in between, and changing the number from 256 to smaller values, to see if the error stops at any point) AutoCAD does eventually crash.  If I instead work my way up from smaller values, somewhere above 100 is where the error begins to appear (and AutoCAD eventually crashes).

I seem to recall something that I read, somewhere, about a limitation on how much memory can be used to store symbol data, but I can't get my eyes on it.

[Anonymous]

I just ran the function 10 times, then inside vlide, then I inspected mylist. No crash.

So, I repeated the function 90 times more. Still no problem. (length mylist) = 25500

So, I repeated the function 1000 times. Watched Windows Task manager while it slammed the system. Ouch, that took way longer than I thought! So I canceled the function

(length mylist) =  186529

Inspect of mylist works fine inside vlide.

So, it's not memory problem. I'm guessing it's a problem with displaying the results.

Then at command prompt I typed !mylist and got the following -

; error: Exception occurred: 0xC0000005 (Access Violation)

Here is Task Manager memory before -

Here is Task Manager memory after -

[honkinberry]

Correct, it is only once the output is displayed.

For instance, you can do a (length mylist), a (car mylist), (equal nil mylist), you name it.

But once you do a (print mylist), bam, Access Violation, and the LISP engine is dead.

--J

[Kent1Cooper]

---

@honkinberry wrote:

It crashes the AutoLISP engine hard.

If you then try to run any LISP code, you'll eventually get a complete crash.

....

---

You may, but I don't.  I ran your code to build your list again, did the !mylist thing and the (princ mylist) thing and also (print mylist) [which returned the same as described about (princ mylist) earlier, except that the initial left parenthesis was moved to the very end].  Then I tried some of the heaviest-lifting Lisp routines I have.  I ran my line-a-cylinder-with-spheres routine, which is pretty heavy-duty.  Then -- take a look at the image attached to the first comment here, in the lower right corner where it says "IB squared!" -- small-scale insulation batting S-curves as a Polyline built on a larger-scale insulation-batting Polyline.  I did the same, only much more so.  It constructed a Polyline of almost 46,000 segments before I stopped it, taking quite a while to do it while I navigated the Forums, got the links in this message from the web, cleaned out Junk e-mail, opened another AutoCAD session [because the one doing that IB thing wouldn't let open another drawing while it was working] to check the number of vertices in that IB squared Polyline [2,661], closed that session, opened another again and worked on other drawings [including running a number of Lisp routines], did some more web-surfing, looked at some photos, etc., etc., without crashing.  So I think the cause for you is likely to be elsewhere than in AutoLisp operation per se.

[honkinberry]

As it is the display that is producing the access violation, perhaps it is subsequent displays that crash.

Your routine appears to have only a single (princ) at the end -- perhaps some additional (princ "xxxx") would crash?

--J

[Kent1Cooper]

---

@honkinberry wrote:

As it is the display that is producing the access violation, perhaps it is subsequent displays that crash.

Your routine appears to have only a single (princ) at the end -- perhaps some additional (princ "xxxx") would crash?

....

---

I'm not sure to what you are referring when you say "your routine," or whether this is really meant to be in reply to me.  In any case, in Post 6 you said "once you do a (print mylist), bam, Access Violation, and the LISP engine is dead."  Even after several such operations, yes, I do get the access violation each time, but no, the Lisp engine does not die [I did the 46,000-segment Polyline with a Lisp routine after several such access violations], and AutoCAD does not crash.

[honkinberry]

---

@Kent1Cooper wrote:

---

I'm not sure to what you are referring when you say "your routine," or whether this is really meant to be in reply to me.  In any case, in Post 6 you said "once you do a (print mylist), bam, Access Violation, and the LISP engine is dead."  Even after several such operations, yes, I do get the access violation each time, but no, the Lisp engine does not die [I did the 46,000-segment Polyline with a Lisp routine after several such access violations], and AutoCAD does not crash.

---

Sorry, not used to their new forum interface.

Yes was replying.

Okay, well then there is something in my Lisp code that must be more unique.

It just certainly seems that any Lisp code that I run whatsoever after getting that access violation cracks Acad in half.

Regardless, to the point -- there is *no reason* that outputting such a list should cause an access violation!

And even though we're not sure exacty what or where, but it *does* render the AutoLISP engine less stable -- all for simply creating such a list and outputting it to the command window!

Apologies for not being exact with perfect steps to reproduce exactly the further crashing.

--J

[Kent1Cooper]

---

@Kent1Cooper wrote:

....  I happen to be at my older-version location right now [ArchDesktop 2004, Windows XP], and couldn't say whether the difference might be related to version, or operating system, or hardware, or hardware acceleration if that's a possibility with your version.

....

---

I've now tried it on AutoCAD 2016 / Windows 8.1.  After !mylist, it did crash AutoCAD when I tried the IB thing.  When I got back in, built the list again, and did IB before doing !mylist, everything was fine, but I then did !mylist and tried IB again, and it crashed again.  Whether the issue is with the difference between 2004 and 2016 version of AutoCAD, or between Windows XP and Windows 8.1, or possibly hardware-related, I wouldn't have a clue, but it certainly seems that it must be related to one [or more?] of those differences, since I've used the same code to make the list every time, and the same AutoLisp command to try crashing it.

[martti.halminen · Accepted solution]

You seem to have hit a very old AutoCAD bug: when I reported this to Autodesk over 10 years ago, they said that it was already known.

It isn't actually a bug in the AutoLISP system, but in the AutoCAD command line interpreter: if you run the program and try the printing etc. in the VLIDE Lisp Console, no problems.

What is happening is that whenever the command interpreter sees something even vaguely resembling DXF codes, it eagerly tries to use that as such, even in totally inappropriate contexts.

- The answer that I got essentially stated that the command interpreter is an unmaintainable heap of spaghetti code nobody knows how to repair, so don't hold your breath waiting for that.

- I can reproduce the error on 64-bit AutoCAD Mechanical 2015 on Windows 7.

-- 

[honkinberry]

---

@Anonymous wrote:

- The answer that I got essentially stated that the command interpreter is an unmaintainable heap of spaghetti code nobody knows how to repair, so don't hold your breath waiting for that.

- I can reproduce the error on 64-bit AutoCAD Mechanical 2015 on Windows 7.

-- 

---

...and yet they were able to update it with 2014 and 2015 to display colors and have clickable keyboard options.  Oh, and also that fun improvement of getting rid of line wraps.

I guess they're really committing to the bit on this whole abandoning LISP thing.  It's like LISP is their Fidel Castro.

--J

[dgorsman]

Not even close.  "COMMAND INTERPRETER" not command line interface.  Different things.

[honkinberry]

---

@dgorsman wrote:

Not even close.  "COMMAND INTERPRETER" not command line interface.  Different things.

---

Seriously?

You're trying to tell me that the legacy AutoLISP code base has those two completely firewalled and separate?

The spaghetti code to which was referred is no doubt inheirited from the original LISP core, in which case those two would in fact be very closely related.

In fact -- note that in the aforementioned reports of crashing, the problem is more pronounced on 64-bit installations, which has been exactly my experience.

In short -- as Autodesk attempted to "spruce up" the command line interface, they broke something with the 32-bit LISP engine, making access violations far more common.  And the very reason for this is the tight relationship between the interface and the interpreter in the core LISP engine.  But attempting to separate the two, they opened up can of out of process access violations.

Still though, spaghetti code or not, I bet I could find and fix the bug in less than two hours.  But that wouldn't be in line with their priorities.

--J