Access Violation Crash

[Worle]

Does anyone have any advice for diagnosing an access violation crash of LabVIEW.

It is crashing when using the JDP JSON toolkit and the PNR JSONText Object Serialisation libraries when decoding a very specific object structure.

It doesn't always crash, you have to run it repeatedly and quickly to cause it to crash. I have also dropped debug elements throughout these libraries and it appears to crash at a different point and after a different number of executions each time.

The possible cause in the screenshot below also changes every time.

I am guessing that it is a bug with the LabVIEW memory manager somewhere, I am just not sure how to try and find the culprit to attempt a different implementation.

The closest I have found on the forum is this. https://forums.ni.com/t5/LabVIEW/Crash-access-violation-json/m-p/3761541#M1059481 

I have posted some example code on this thread https://bitbucket.org/drjdpowell/jsontext/issues/212/access-violation-crash-with-very-specific

[Kyle97330]

Do you have access to other PCs and/or LabVIEW versions to see if the problem occurs everywhere the library and data structure is used, or if it's isolated to either just your PC or just a certain version of LabVIEW?

Can you provide details on what "a very specific object structure" means?  Is it mostly "vanilla" data types (numerics, strings, Booleans, etc.) or does it include more exotic things (classes, variants, references)?

[rolfk]

Access Violations unfortunately are a very unspecific error when looked at from an application point of view. They simply mean something has somewhere gone awfully wrong and the CPU was able to detect that during execution.

It lacks pretty much all context. Sometimes you are lucky and can map the reported address to some code in your application, if and only if you have the map files and debug symbol tables for that application, often the error manifests itself however deep down in the bowels of the OS. It's still usually something in the application that causes it but tracing the error back to the cause is almost impossible without also having access to the source code of the application.

In old days one would send in this crash report to support and then pray that there was an AE assigned to it who actually wanted to dig that deep and bother someone in LabVIEW R&D to look into it more. Nowadays you click "Yes" to send the crash report and are pretty sure it vanishes in a big black hole that might be eventually used for statistical analysis but not much more.

But your information so far is fairly thin. As Kyle already stated "a very specific object structure" sounds like an interesting hint, if it is specific, but it is also very unspecific in itself! 😁 

[Worle]

The link in the original post had some code in it, I have attached another copy here.

This copy actually is slightly stripped down, the Decode Only.vi illustrates the problem with 100% reliability.

I have tried it on a couple of machines with the same affect.

The simplest object structure I can recreate the problem with is this.

I have instrumented the JSONText libraries with a debug log and I have not worked out a pattern as to where LabVIEW is crashing. Sometimes it will run for 100 iterations, sometimes only 1 or two. The code also stops executing at different places each time.

Having said that the majority of the crashes appear to be happening just after Generic Object Serializer:JSON to LVObject.vi returns its values to the calling VI.

I have submitted a bug report to NI. Unless anyone has any pearls of wisdom/NI get back in touch quickly I am going to have to abandon trying to fix this and restructure my classes to avoid the issue in the first place.

[Kyle97330]

The link in the first post just gives a message saying "This issue is submitted and being reviewed", so it doesn't actually have anything we can see.  I suspect only you can until it gets reviewed.

The zip file is theoretically usable but I am frozen at LabVIEW 2021 so I can't check it personally.

However I do suspect that the problem is the class data type in general, especially nested ones.

At my company we do have classes that we wanted to flatten out to save to disk and recall later for various reasons.  We tried the built-in XML conversions, which seemed to work pretty well at first until we ran into a few problems with it, as certain data types don't flatten/unflatten properly (variants and numbers with units being the biggest problems), and when class versions are changed we had other problems ranging from partial data loss up to complete inability to decode.

We looked into a number of options but what we eventually decided was that any completely generic "flatten/unflatten everything" method wasn't actually possible.

What we eventually settled on was creating a LabVIEW Interface class that had 3 overridable methods:

Object to JSON.vi

Get decodable names.vi

JSON to object.vi

"Object to JSON" would tell the object to encode itself as JSON in any way it liked, but with a requirement to have "Name" and "Version" string elements nested in it at the top level.

"Get decodable names" would return a list of all "Name" strings that a given class would decode.  Empty array means it doesn't support JSON. One element means it decodes itself.  Two or more means it is either a factory class of sorts, or it supports decoding of a class under multiple names due to changing the class name to correct spelling errors or whatever.

"JSON to object" would convert any JSON with a matching "Name" string to an object of the type passed into its Dynamic Dispatch input.  It would check the version string as well if there were historical differences in how it decodes.

When you want to decode JSON but don't know what exact object to pass into the DD input terminal to get to the correct decoder, there was another VI we made that checks all classes currently in memory to see if they support the Interface, calls "Get decodable names" on all of them, checks the JSON for its "Name" string element, and if it finds a match it creates an instance of the supported class programmatically and passes the JSON to that one's "JSON to object" implementation.

This is a fair amount of work as you do have to make a manual decoder and encoder for each class, but it's the only viable option we found because all other ones choked on edge cases.

[Worle]

I have been toying with a similar idea regarding the interfaces. I was going to also create another child of the JDP JSONText Serialiser which invokes the interface methods as well so the JSONText Library would be able to handle clusters containing classes rather than having to individually flatten objects.

As you say it is just a lot of work.

If I was to put my money on what the problem was I would say it was the set in the parent cluster, having said that if I remove any of the private data elements the example will run without any issues.

Currently I have replaced the set with an array in my code and it is working fine, if I have issues I will have to so something along the lines of what you have suggested.

I have attached a copy in 2019 for your interest

[PNR · Accepted solution]

> If I was to put my money on what the problem was I would say it was the set in the parent cluster, having said that if I remove any of the private data elements the example will run without any issues.

Spot on.

Thanks for providing the test code. I was able to reproduce and analyze the issue: https://github.com/logmanoriginal/JSONtext-Object-Serialization/issues/26#issuecomment-2226851475

The root cause is known issue 1035177, which causes the name of a Set to contain garbage data after reconstructing the Set using the Flattened String To Variant function.

This appears to be fixed in LabVIEW 2024 Q1. For older versions, using an Array instead of a Set fixes the issue.

[Worle]

Thanks for your effort diagnosing this.