Fatal Internal Error: thevent.cpp

[ijustlovemath]

Hi all,

Using LV2013 SP1.

I'm creating a logging framework for my application, part of which accepts a variant, and serializes the variant data to an array of strings. This worked well, until I realized it could not support nested clusters. I got to work fixing it, and arrived at a mostly satisfactory solution, until I realized that I also didn't support arrays within the clusters. I did 1D arrays, then realized I could generalize it to any dimensional arrays, which I did.

So now, I had this framework that supported taking a cluster, which could contain clusters which also contained clusters, which could also contain multidimensional arrays of anything, and serialize it all.

Well, for some reason (we all know the reason), when I run the test sometimes, LabVIEW crashes. This is not reproducible with a finite list of steps, rather it's more like:

1. Do some work for a while

2. Try to run the serialization test

3. LabVIEW crashes

I think I'm breaking some kind of recursion depth limit, which is understandable, but I don't know why it works sometimes and not others.

I've seen this trhead: http://forums.ni.com/t5/LabVIEW/fatal-internal-error-error-quot-thevent-cpp-quot/td-p/1451460 which seems to think it should be resolved in LV2010, which I have a larger version than.

I'm attaching the VIs that I'm using. You'll need OpenG's variant, error, and string libraries, as well as VariantType.lvlib

The test that breaks sometimes is "LV Crash Problem/Utilities/Test/Test Cluster Elements To String Array.vi"

Warning!! This could, and possibly will, crash your instance of LabVIEW, with no chance to save work! Run at your own risk!

[this_one_time_at_vancamp]

Ijustlovemath, I'm having trouble reproducing the bug. I would agree though, it looks like there is probably a recursion limit or some other type of overflow. It would appear that the program works for clusters of reasonable sizes and depths. Is there any reason it needs so many levels of depth other than just wanting to make the program robust? Perhaps you could create a way to limit the number of nested structures to a reasonable amount so a user likely wouldn't reach the bottom of the recursion?

[ijustlovemath]

As you say, I just wanted to solve the problem generally. I've since added to that configuration cluster (which I made a typedef immediately after uploading this) a "max array dimension" parameter, and will possibly add a "max recursion depth" parameter which decrements before each recursive call. I'd love to see if anyone from NI can look into this, as it's really preferable to not have LV crash in the middle of an application deployment just due to a somewhat more robust logging feature.

[this_one_time_at_vancamp]

I'll continue to look into it, although without a reproducible case it will be hard to address. I still think the best solution is to constrict the input size and depth enough that the error doesn't come up - restricting the user to certain input requirements may prove more effective than making the program accepting of infinite input types. I think you are on the right track to getting the program as robust as possible. A similar architecture that flattens everything to variants would be looking into, although you may run into a similar issue.