Access Violation in debugging when attempting to read a very long string

[dmcdonoughwick]

Describe the bug
Attempting to step through reading a very long string and setting to a variable causes an "Access Violation" and the debugging stops. This currently does not happen in VLIDE.

To Reproduce
Steps to reproduce the behavior:

1. Point the "Crash.lsp" to where the "ReallyBigFile.txt" is located
2. Start debugging "Crash.lsp" with a breakpoint on the "(setq ReallyLongString (read-line OpenFile))"
3. Issue the command "CrashFunc" and AutoCAD will instantly generate an access violation error and quit debugging.

Expected behavior
In VLIDE the process takes approximately 3 minutes to complete (on my system) but does not cause an access violation and continues debugging. If that's not possible a more descriptive error would be desirable as it was very difficult to narrow down.

Screenshots

Desktop (please complete the following information):

• OS: Windows 10 64-Bit
• Version 21H2

Additional context

(defun c:CrashFunc ( / )
  (progn
    (setq FileName "C:\\Projects\\ReallyBigFile.txt")
    (setq OpenFile (open FileName "r"))
    (setq ReallyLongString (read-line OpenFile))    
    (close OpenFile)
    (princ "Test Complete")
  )
)

ReallyBigFile.zip

[dmcdonoughwick]

This may be related to JDSComm's comment in ticket #182

[dmcdonoughwick]

This is only one way to trigger this error. It happens so often that the debug is essentially useless to me and I still rely on VLIDE. I'd be happy to run any tests or send any log files that might be useful for this.

[JDSComm]

See the attached file.
First to get VSCode working again perform the steps in "SOLUTION 2".
Then, If this ever happens again, all you have to do is "SOLUTION 3" or "SOLUTION 3 Update".

Hope this works for you as well.
I was about to give up on VSCode because of this but now I'm not having any issues with it.

VSCode - Unwind skipped on exception error if breakpoint in code.txt

[dmcdonoughwick]

I revisited this and solved it. In case anyone else runs into it, here's the issue: AutoLISP variables share a total buffer of 512 KB. If you exceed that limit, VS Code errors out because it can't populate the variables list. My solution was to port the logic that handles those variables into .NET, then just call the [LispFunction] to return what I need.

More thorough AI explanation:

We hit this and were able to characterize it further: the trigger isn't a single
long string, it's the combined printed size of all in-scope symbol values. We
bisected by padding a throwaway global to a known size and stepping over a
trivial breakpoint — a total of ~509 KB steps fine, ~541 KB access-violates, and
two 300 KB globals fail together while either passes alone. So it behaves like
one shared serialization buffer of roughly 512 KB (524,288 chars) spanning the
whole symbol table, not a per-variable limit. Also worth noting: the AV lands at
an arbitrary location rather than at the assignment that created the large value.
It appears to fault at the first variable-state sample after whatever was
blocking, so interactive prompts (getpoint, getstring, etc.) mask it and make
the crash look like it's in unrelated code — which is most of why this is so hard
to narrow down.

The workaround that unblocked us was to keep bulk data out of LISP symbols
altogether. Anything large that's really a read-only cache or lookup table can
live on the .NET side behind a [LispFunction] that returns only the small value
requested — that call is synchronous and steppable, and the payload never enters
the symbol table. Where a full refactor isn't practical, (setq BigVar nil) on
the largest globals before attaching is enough to get back under the ceiling. It
would help a great deal if the adapter truncated or lazily expanded large values
instead of faulting, and if the error named the symbol it choked on.