PDA

View Full Version : Node editor: 100 % repeatable crash with undo stack



Captain Obvious
10-17-2008, 07:59 AM
Try doing this:

In a node editor (any node editor), create a few nodes. Open the Task Manager or Activity Monitor or whatever, and look at the memory usage for Lightwave. Select at least one node in the editor, and start hammering away on shift-c & shift-e, to expand and collapse the nodes over and over again. Notice how the memory usage climbs constantly? The speed of increase is basically a product of the complexity of the node tree (and how quickly you can press the buttons, of course). Basically, it seems that the node editor's undo stack duplicates the entire node tree every time you take an action. When the undo stack reaches a certain size (I'm not sure what that particular size is), Lightwave crashes. Try it -- it eventually crashes with 100 % certainty on all the setups I've tried it on!

With a complex node tree, every single step of undo takes several megabytes of memory, and it's enough with 50 or so megabytes worth of undo stack to cause a crash. Adding new nodes, expanding or collapsing nodes, rewiring the network, etc, are all undoable actions, and they all make the node undo stack grow bigger at an alarming rate. Purging the stack clears up the extra memory being used, and resets the risk of crashing, but it quickly gets old hammering away at the Purge button every time you make a change. It also makes you wonder what the point of having an Undo system is in the first place, since it just makes the darn thing crash.

This is in LW 9.3.1. Has this been fixed for 9.5 or 9.5.1?

toby
10-19-2008, 04:05 PM
When I expand and collapse and try to undo it says "nothing to undo"...
so I copied a node and hit paste - delete - paste - delete enough times to up the ram usage by 150mb, no crash. This is the cfm 9.3 on osx 10.411. Sure it's not just your system?

Hopper
10-19-2008, 04:18 PM
Unfortunately, memory isn't magic. If you have a complex state system such as an undo chain, yeah, it's going to take a butt-load of memory when you are tracking potentially large objects. That's just the way it is. However, there is obviously a design flaw if it eventually crashes. Memory limits and such should have the proper error handlers, etc... Even if the application is blindly trying to allocate memory from the heap, the OS should still handle any swapping if necessary.

I would say that problems such as these may have stemmed from poor design. It's easy to create a dumb undo stack, but it takes a better breed to come up with an intelligent one. And as a developer myself, I can tell you that most of the time, the elegant ways usually just have to wait. It's the brute force gorilla programming that gets it done on time.

Edit: I opened 9.3.1 and was tweaking around with the nodes. Oddly enough, I don't have the same problem you are having. It looks as if it is allocating and deallocating memory just fine. My memory doesn't bloat and it looks as if garbage collection is happening as it should. I can't get it to crash no matter how fast I try.

Sensei
10-20-2008, 02:10 AM
Captain, take screen-shot and show your node tree setup that reproduces problem.. It's rather problem with particular nodes and/or connections than general one, otherwise any node would reproduce it, but it's not going to happen on people's machines..

Red_Oddity
10-20-2008, 03:05 AM
I do notice the increase in used memory, waiting for a crash right now, what i do notice though, is that the more and longer i do SHift-C Shift-E (Collapse and Expand) the slower and slower it start expanding.
Testing it with a very very basic scene and some nodes that aren't even connected to the surface node.

Still not crashing though, but i do have 8GB in this machine, so, that might take a while.

Captain Obvious
10-20-2008, 04:34 AM
Very strange. I'm able to reproduce this on a number of machines, all running 64-bit XP with 8 gigs of RAM.

I'll post more information if I can figure something out.

Red_Oddity
10-20-2008, 02:15 PM
Ah, i used the 32 bit version, might try the 64bit version tomorrow (if i have time left, deadlines deadlines deadlines...)

toby
10-20-2008, 08:49 PM
the more and longer i do SHift-C Shift-E (Collapse and Expand) the slower and slower it start expanding.
I noticed that but only when doing it quickly. Proc usage goes up to 100% ( one proc ) when I expand one, so I think it's just not keeping up with me