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

Activity

1. dmcdonoughwick commented on Aug 11, 2022

   

   dmcdonoughwick

   on Aug 11, 2022

   Author

   More actions

   This may be related to JDSComm's comment in ticket #182
2. dmcdonoughwick commented on Oct 1, 2022

   

   dmcdonoughwick

   on Oct 1, 2022

   Author

   More actions

   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.
3. JDSComm commented on Nov 16, 2022

   

   JDSComm

   on Nov 16, 2022

   More actions

   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
4. dmcdonoughwick commented on Sep 2, 2026

   

   dmcdonoughwick

   on Sep 2, 2026

   Last edited by dmcdonoughwick

   Author

   More actions

   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.