Cherry Audio Forums

Hey, I just ran into a strange issue. Never saw this before, but I can easily reproduce it, and I'm wondering if this is something I have misconfigured in my system and/or something really obvious I'm missing.

Simply put, VMD crashes if there are "too many" class definitions in the code. It feels like "something" hits some limit and causes the crash. AFAIK, it's not a limitation of Java, but something else is happening here.

To reproduce, just open a new fresh VMD project, and add class definitions in the code under "Add your own variables and functions here". Empty dummy classes do the trick just fine. Like so: When I do this and get to about 90-95 classes (the exact number seems to vary a little, for some reason), the code still compiles and starts running, the module window appears, then suddenly disappears, and I get the OS X crash report window (the report is attached). VMD still thinks the module is running, so I need to select "Stop running" from the menu. Removing a class or two makes the program work again.

A few points:
- This is not about too many class _instances_. Just adding class definitions is enough.
- The actual contents of the class does not seem to matter, an empty dummy class does the trick.
- As far as I can understand, the error happens somewhere between compiling and actually running the code. It happens with a new default project with no user code, except class definitions.
- It also doesn't seem to matter if the class definitions are in the main .java file or other files - if the total is "too much", it's crash boom bang. Enums and anonymous classes are also counted in the total.

I'm working on a pretty big module with lots of classes and enums, and I hit the limit "naturally", and it took me a while to figure out what is happening.

Can anyone else reproduce this, and any ideas how to get around it? Thanks!

Some additions:
- Attached is a text file with 100 dummy class definitions so you can easily try this yourself (just copy & paste them into a fresh VM project and see if it still runs)
- Interfaces also count into the total (in addition to regular / abstract / anonymous classes and enums)
- I tried studying the crash report a little, but didn't have any major revelations so far

Interesting. Though I've never created any software that defined that many new classes even when developing libraries, so it's an academic rather than practical interest.

I believe there's not supposed to be any theoretical upper limit to the number of new classes defined in a Java program but in practice one would expect problems when one get's to large numbers, but I'd expect such large numbers to be something like 2^16 rather than 90 to 95.

I now split classes into individual files and don't have the time to create 90+ files but it sounds like you've already determined that it's the total number of classes rather than how they're defined anyway.

Looking at the error report it looks like a dangling pointer in JUCE that's causing an exception. So possibly a C++ problem rather anything to do with Java.

Have you tried publishing the code and running it in VM proper? It might be some weird limitation in the VMD test client that doesn't cause any problems in VM.

Just tried inserting the text you provided and ran it under Windows 10 in debug mode. The test client didn't show up but it may have done so and disappeared so quickly that I didn't see it.

It tried contacting the server without the window being present and I had to use Stop Running to stop it so some process was obviously there even without the window being visible.

Looking at the log files it just seems to have died without logging any error.

Thanks for testing this & doing some further analyzing! So yeah, seems it's a built-in VMD "feature" instead of something wrong with my system, unfortunately. I just tried publishing a module with "too many" class defs, and interestingly the whole VMD crashes and quits to desktop before it even shows the publish window (couldn't find anything in the crash logs). I removed a few classes, and then it worked as expected.

Yeah, I agree 90+ classes can be quite a lot in a single module, but I still find it hard to believe that with the amount developers currently making modules for VM, no-one has ever hit this limit before. In addition to good ol' regular classes, I tend to use a lot of inner classes, enums, interfaces, plus small anonymous classes for various purposes, and all these together can easily reach the danger zone (it seems...). I'm still in the middle of development of the module, and I might optimize and possibly remove some classes later, but with this limitation it's quite difficult to continue.

Anyway, a big thanks again! Let's see if someone from Cherry Audio can comment, or if not, I'll try sending a support request.

Yikes! Possibly stating the obvious, but looks like the ClassFileParser is blowing-up?

Have you raised a ticket with CA? Be interesting to see what they say.

Good luck - that's not a nice wall to be hitting! -Rob

That sounds like bad news. I can't think why attempting to publish would actually crash VMD.

Probably best to contact support over this issue as you'll wait forever for some response via the forum.

On the more general question of what's a sensible number of classes to define in a project, I have found somewhere around three dozen to be a magic number for virtually everything. So no more than 36 classes in a library, 36 methods in a class, 36 lines of code in a method, 36 items in an enumeration, 36 user interface elements and so on.

Perhaps the three dozen ish number is the upper limit on what a human mind can contemplate before everything starts falling apart.

But obviously that doesn't excuse a system not being able to cope with larger numbers.

ColinP wrote: ↑Sun Jul 23, 2023 7:07 pmPerhaps the three dozen ish number is the upper limit on what a human mind can contemplate before everything starts falling apart.

Some would argue the magic number is seven (plus or minus two), but that probably only applies to me

https://en.wikipedia.org/wiki/The_Magic ... _Minus_Two

There was a time I used to apply this to all UI design, menu options etc., but that trend has been "bucked" a long time ago!

-Rob

Chuckles. Hey Rob, some days I struggle with one (plus or minus one) never mind seven!

The 36 thing is just a rule of thumb. For instance I'll write a ~100 line method if that makes it easier to understand than using redundant sub-methods. And my Granular Synth has a lot more than 36 UI elements, but symmetry and color-coding help reduce the cognitive load.

All right, I sent CA a support request. In the past they have always responded pretty quickly, hopefully now too.