Is there a character limit on enum items?

[CoastalMaineBird]

LabVIEW 7.0, Win2000

I have an enum, used for specifying units (Lb, kG, %, ppm, etc.) in a large program.



I have been updating the typedef now and then for at least a year with no problem.

Yesterday, I opend the type def and added a new divider + four items. A "divider" in my case is a disabled item used to separate the categories, such as "----- Pressure:" or "----- Mass:".

I opened the CTL file, by itself, and added the following:

----- Brake-Specific Mass:
Lb / HP-Hr
G / HP-Hr
G / kW-Hr
kG / kW-Hr

I saved the CTL file, and when I opened my main program, CRASH! "Fatal Internal error: DataType.cpp line 6380"

So, I trashed the folder, unzipped a backup copy, and repeated the process - CRASH! same result.

So, I restarted Windows, tried it again - CRASH!

Hmmmm.

I trashed the folder, unzipped a backup copy, edited the CTL file, and started mass-compiling libraries one by one. One particular library caused a crash.

By opening the VIs in that library one by one, I found one that was broken. The complaint was "LabVIEW cannot determine the datatype of all the wires in this VI". WTF ???

None of the wires were broken, just the VI itself.

I started over, and changed the stuff I was adding to this:

----- Brake-Specific Mass:
A
B
C
D

Lo and behold- IT WORKS!

I changed it to this:

----- Brake-Specific Mass:
Lb / HP-Hr
B
C
D

Lo and behold- IT WORKS!

I changed it to this:

----- Brake-Specific Mass:
Lb / HP-Hr
G / HP-Hr
C
D

--- It crashes.I changed it to this:

----- BSM:
Lb / HP-Hr
G / HP-Hr
C
D

Lo and behold- IT WORKS!

I changed it to this:

----- BSM:
Lb / HP-Hr
G / HP-Hr
G / kW-Hr
D

Lo and behold- IT WORKS!

I changed it to this:

----- BSM:
Lb / HP-Hr
G / HP-Hr
G / kW-Hr
kG / kW-Hr

--- It crashes. Sure looks like a character limit, doesn't it?

So I went and removed two of the dashes in each divider (removed 28 characters overall), and now this case works:

--- BSM:
Lb / HP-Hr
G / HP-Hr
G / kW-Hr
kG / kW-Hr

So I go whole hog, and now this works:

--- Brake-Specific Mass:
Lb / HP-Hr
G / HP-Hr
G / kW-Hr
kG / kW-Hr

--- which is what I originally wanted.

In other words, removing 28 characters gave me room to add the things I wanted to add.


The total number of items in this enum is 51 or 52, the total number of characters is about 406 or so, not counting line endings, for the case with three good values and a "D" in the fourth slot.


If I assume there's a CRLF internally for each one, that would bring the total to about 508, leading me to wonder if there's a 512-character limit on enum items?

Anybody run into this before?

[Ben]

I have not seen that issue.

Could you share the enum in question?

According to the definition of the data types in LV

http://zone.ni.com/devzone/conceptd.nsf/2d17d611efb58b22862567a9006ffe76/370dfc6fd19b318c86256a33006bfb78 

There should not be a 512 limit for the strings.

I would like to do a "flatten to string" to take a look at the type descriptor to figure out why that is blowing up.

Curious,

Ben

[CoastalMaineBird]

I did lots of testing last night on this issue.
It's quite repeatable. I tested it on LV 7.1 (OSX) and the bug is there, but LV 8b120 works OK.
I have attached the LLB that I sent to tech support.

Here is the report I sent:
Problem Description :
Apparently there is a character limit on ENUM items.

If I add two characters to any item in this enum, LabVIEW will CRASH when I apply changes. The crash occurs without actually RUNNING the program.

I have tested on LabVIEW 7.0 (Win2000) and 7.1.1 (OS X). Both exhibit the same behavior.

LabVIEW 8.0 b120 (OS X) does NOT crash - it works correctly.

STEPS TO REPRODUCE:
1... Open the library and keep HDT SORT CHANNELS INTO PAGES.vi open.
2... Open HDT UNITS CONTROL.ctl in the library.
3... Add two or more characters to any item in the ENUM.
4... APPLY CHANGES
5... Watch LabVIEW crash.

It certainly leads to bizarre behavior - If you remove the UNITS control from the HDT DISPLAY UNITS vi while you change the typedef, there is no crash. But as soon as you put it back and wire it to the connector, ALL the terminals turn to (void).

Message Edited by CoastalMaineBird on 11-18-2005 09:11 AM

[CoastalMaineBird]

There should not be a 512 limit for the strings.

I wrote a program to count the characters and came up with 54 items, a total of 522 (not 512) characters, -IF- I assume a CR + LF for each item.

I don't know why they would use a CR+LF in such a case, but it was a thought. Given that it works out to 522, it looks like I was barking up the wrong tree.

I should mention that it is EXPECTED that the top VI will be broken after you change the ENUM. There's a place where I pass a reference to that typedef'ed control and that will break of the typedef changes.

But it certainly should not crash LV.

Message Edited by CoastalMaineBird on 11-18-2005 09:15 AM

[CoastalMaineBird]

I just looked at the BEFORE and AFTER type strings for the enum itself.

When I tested just the enum with this it does not crash.

There were only two differences: The overall length was different by 2 (which I would expect), and
The length of the item i changed was different by 2 (which I also would expect)

Since it does not crash here, the problem is not with the enum itself, but in how it gets used.

[Ben]

Hi Coastal,

I do not have time to give a quality full explanation now but the "how it is used" reminds me of a posting by Rolf Kalbermatter re:LV limits.

Check that link I posted again.

If your enum is in a cluster then the type definition of the cluster may be going over the limit of the 16 bits allocated to specify the length of the the type def.

Like I said, no time now,

Ben

[CoastalMaineBird]

If your enum is in a cluster then the type definition of the cluster may be going over the limit of the 16 bits allocated to specify the length of the the type def.

BINGO! I think you're on to something.

The TYPEDEF for the cluster is now 30554 bytes (Holy Cow!) There are 60 of these ENUMS in the cluster as well as 60 DBLs and 60 STRs.

If I reduce the length of the enum, I get:
0 30554
-1 30554
-2 30434
-3 30434
-4 30314

It goes down by 120 every TWO characters - must be a padding scheme.
that means if I added 1 character (crash!), the typedef would be 30674 - not a magic number that I can see.
Hmmmmm...

Message Edited by CoastalMaineBird on 11-18-2005 10:45 AM

[Ben]

Max I16 value is 32767.

I would think it would have been a U16 but the doc I pointed at does not make it clear if that field is signed or un-signed.

Ben

[CoastalMaineBird]

CORRECTION: the third item is not a STR- it's a COLOR box.

If I remove one set of indicators (ENUM+DBL+CLR) from the cluster TYPEDEF, I can add four characters to my ENUM without crashing.

But I can't add six.

[Ben]

OK Had a look at your example.

The array has a type descriptor that is larger than the cluster (makes sense)

AND

The VI, since it returns the array of clusters has an even larger type descriptor which is 30864.

Since the flatten to string returns I16's I have to assume the size is limited to the max value that can be represented by a I16.

I will check the flatten to string in LV8 this week-end to see if this has changed.

So I do not think this is an enum limit but a type descriptor limit but I still have this memory of Rolf indicating the limit was 65535, so I am not sure if my memory is faulty, or if there is a bug involved here.

Ben

PS And yes there is padding invloved.

Message Edited by Ben on 11-18-2005 02:56 PM