AutoCAD 2023 - Bug in Block Editor?

[hencoop]

in the block editor
which has dynamic content and wipeouts
I start the PLINE command, pick the first point
and then snap to a point that is a vertex of a wipeout clip boundary
(any wipeout)
INSTANTLY CRASHES AUTOCAD
The error reporting tool opens
However, the AutoCAD window remains displayed as well as the VLIDE
Both are unresponsive and the acad.exe process must be killed.

This has happened exactly this way in multiple blocks.

Both my AutoCAD 2023 and Civil 3D 2023 are fully updated (my forum signature is not).

[ The subject line of this post has been edited for clarity by @handjonathan Original: Bug in Block Editor? ]

[pendean]

Not seeing anything like that here in AutoCAD2023.1.1 with my own blocks: are your 2023's fully updated?
Are all of your similar blocks triggers for this crash, or just this one?

If all, can you share one here so we can try it?

[hencoop]

---

hencoop wrote:
Both my AutoCAD 2023 and Civil 3D 2023 are fully updated (my forum signature is not).

---

The file is attached.

[pendean]

Thanks for the block: not seeing any issues here, are you doing more that what you stated in your first post?

[hencoop]

@pendean  I crashed again today in yet another block.  This time, no wipeout was being snapped to.  That caused me to reconsider what the circumstances are.  I always use PLINETYPE=0 and use CONVERTPOLY whenever a lightweight polyline is required (rare for me) so I didn't even think about that system variable being involved.  I reset PLINETYPE=2 and could not cause a crash.

If you can duplicate the problem by just setting your PLINETYPE=0 and snapping the second polyline point to anything in the block, then we will have proven there is a bug and that PLINETYPE=0 causes AutoCAD to crash under these conditions.

While in the Block Editor editing a dynamic block.
IT IS OF CRITICAL IMPORTANCE THAT PLINETYPE=0 AND THE SECOND POINT IS SELECTED USING ENDPOINT SNAP.

THIS ONLY HAPPENS WHEN USING THE PLINE COMMAND WITH PLINETYPE=0 AND THE SECOND POINT IS SNAPPED TO SOMETHING.

[pendean]

Set GFXDX12 variable to 0 (that's a zero) then restart your AutoCAD(s). Any relief from the crashes?

Also consider turning off LINESMOOTHING and LINEFADING variables: then start GRAPHICSCONFIG command and change the 2D Display Settings pulldown from "advanced mode" to one of the other choices if the first tip did not help.

If all else fails, then turn off Hardware Acceleration as a last resort, IF THAT WORKS, start a support ticket through your subscription portal as explained here https://knowledge.autodesk.com/customer-service/account-management/users-software/support-options#:~....

[hencoop · Accepted solution]

@pendean Been there, done that (I'm the OP in this thread): https://forums.autodesk.com/t5/civil-3d-forum/wipeout-causes-hard-crash/m-p/11479905#M479788 (an earlier instance of this problem).

Did you attempt to cause the problem by setting your PLINETYPE to 0?

I was able to eliminate the problem by setting PLINETYPE to 2  (I always use PLINETYPE=0 ... at least until now).

[hencoop]

@pendean Does this mean that you WERE able to cause this crash with PLINETYPE=0?  ...thus proving that a bug exists!

[pendean]

My PLINETYPE is always set to 2 since, well, a very long time: I've never understood why it needs to be anything else, especially in AutoCAD2023. I cannot make it crash that way, but you seem to be able to apparently.

If PLINEYPE=0 is your business need, and you've proven it crashes only with that setting as you stated above, then you will have to report the issue to Autodesk (see my previous link to how).

Not much us end users can do about it (whether we can prove it or not along with you).

[hencoop]

@pendean It's very simple.  If you can independently cause the crash by snapping to specify the second polyline vertex while in the Block Editor and while PLINETYPE=0, that removes any possibility that I have missed something unique to my system that is causing the crash.  You would be doing me a great favor by trying it.  Please do.

[hencoop]

@pendean P.S.  I use many custom tools written in Autolisp.  Many of them work with heavy Polylines.  I don't have the time to rewrite them all to use lightweight Polylines or even to add code letting me know if I've selected a lightweight Polyline and trap the error.   (I have rewritten some of them).

[TomBeauford]

To me the greatest upgrade to AutoCAD ever was r14 largely because of the introduction of lwpolylines. I remember when a heavy polyline with 100 vertices was also 100 entities which became 1 entity as a lwpolyline shrinking drawings with contours down to a small fraction of their previous size making the drawing so much faster & easier to work with.

[hencoop]

How long ago did they stop using polylines and make contours a display element of a surface?

[TomBeauford]

Civil 3D surfaces are intelligent objects usually displayed as contours for all the years I've used it but it came out years after lwpolylines which are still how contours and all linework are imported from GIS data into preliminary drawings with Map 3D. Many of our drawings like Traffic Calming and installing crosswalks can be done quickly without requiring any fieldwork. I would show you code I wrote for working with heavy polylines but I deleted it over 20 years ago.

[hencoop]

I have 73 lisp routines that work on heavy polylines.  23 of those work with both heavy and lightweight polylines.

The different code requirements can be significant.

The entity data of a POLYLINE has a POLYLINE entity and a series of VERTEX subentities followed by a SEQEND entity:

((-1 . <Entity name: 12cbd82e260>) (0 . "POLYLINE") (330 . <Entity name: 12c1c229020>) (5 . "2E756") (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "C-PROFV$TE$") (100 . "AcDb2dPolyline") (66 . 1) (10 0.0 0.0 0.0) (70 . 0) (40 . 0.0) (41 . 0.0) (210 0.0 0.0 1.0) (71 . 0) (72 . 0) (73 . 0) (74 . 0) (75 . 0))
((-1 . <Entity name: 12cbd82e270>) (0 . "VERTEX") (330 . <Entity name: 12cbd82e260>) (5 . "2E757") (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "C-PROFV$TE$") (100 . "AcDbVertex") (100 . "AcDb2dVertex") (10 5702.25 3142.7 0.0) (40 . 0.0) (41 . 0.0) (42 . 0.0) (91 . 0) (70 . 0) (50 . 0.0))
((-1 . <Entity name: 12cbd82e280>) (0 . "VERTEX") (330 . <Entity name: 12cbd82e260>) (5 . "2E758") (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "C-PROFV$TE$") (100 . "AcDbVertex") (100 . "AcDb2dVertex") (10 5750.53 3142.7 0.0) (40 . 0.0) (41 . 0.0) (42 . 0.0) (91 . 0) (70 . 0) (50 . 0.0))
((-1 . <Entity name: 12cbd82e290>) (0 . "VERTEX") (330 . <Entity name: 12cbd82e260>) (5 . "2E759") (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "C-PROFV$TE$") (100 . "AcDbVertex") (100 . "AcDb2dVertex") (10 5750.53 3194.04 0.0) (40 . 0.0) (41 . 0.0) (42 . 0.0) (91 . 0) (70 . 0) (50 . 0.0))
((-1 . <Entity name: 12cbd82e2a0>) (0 . "VERTEX") (330 . <Entity name: 12cbd82e260>) (5 . "2E75A") (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "C-PROFV$TE$") (100 . "AcDbVertex") (100 . "AcDb2dVertex") (10 5775.93 3194.04 0.0) (40 . 0.0) (41 . 0.0) (42 . 0.0) (91 . 0) (70 . 0) (50 . 0.0))
((-1 . <Entity name: 12cbd82e2a0>) (0 . "VERTEX") (330 . <Entity name: 12cbd82e260>) (5 . "2E75A") (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "C-PROFV$TE$") (100 . "AcDbVertex") (100 . "AcDb2dVertex") (10 5775.93 3194.04 0.0) (40 . 0.0) (41 . 0.0) (42 . 0.0) (91 . 0) (70 . 0) (50 . 0.0))
((-1 . <Entity name: 12cbd82e2b0>) (0 . "SEQEND") (330 . <Entity name: 12cbd82e260>) (5 . "2E75B") (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "C-PROFV$TE$") (-2 . <Entity name: 12cbd82e260>))

The entity data of a LWPOLYLINE is just one entity; however, it has a quintuplet of ASSOC lists for each vertex (10, 40, 41, 42 and 91): 

((-1 . <Entity name: 12cbd82e260>) (0 . "LWPOLYLINE") (330 . <Entity name: 12c1c229020>) (5 . "2E756") (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "C-PROFV$TE$") (100 . "AcDbPolyline") (90 . 4) (70 . 0) (43 . 0.0) (38 . 0.0) (39 . 0.0)
(10 5702.25 3142.7) (40 . 0.0) (41 . 0.0) (42 . 0.0) (91 . 0) 
(10 5750.53 3142.7) (40 . 0.0) (41 . 0.0) (42 . 0.0) (91 . 0) 
(10 5750.53 3194.04) (40 . 0.0) (41 . 0.0) (42 . 0.0) (91 . 0) 
(10 5775.93 3194.04) (40 . 0.0) (41 . 0.0) (42 . 0.0) (91 . 0) 
(210 0.0 0.0 1.0))

It is less data but getting and using the data from these two types of polylines involves entirely different code.  I find it much easier to set PLINETYPE=0 to be able to use my tried and true code than it is to recode 50± autolisp routines.  This is especially true since all of the code I have changed thus far can use either type of polyline.