When I enable debug mode max hangs with one core working at 100%. I’ve opened the debugger before so not sure why it’s not working anymore. First time it happened I just started out with a new flow with no output node yet so I figured that might be the problem. However, setting up the simplest flow possible (input position -> output position) causes debug mode to freeze as well.
Martijn
Thanks!
We found a lot of bugs in it today and fixed them. (Beta 4 coming very soon!)
Also improved update speed (spinners don’t have to reevaluate the flow), Prev/Next buttons to skip by Count since spinner.scale is not a property, Min/Max/Mean optional info and more.
Stay tuned!
Still having the same problem with Beta 4 (max 2012, 32 bit).
Enabling debug mode causes max to freeze and leaves one core running at 100%.
Tested with an empty flow, and one that had just an Input Channel (Position) connected to a position output.
Martijn
Chad is also having similar problems.
We will escalate this and see if we can figure it out.
It would be interesting to try to run a MAXScript from the listener to see if the actual debug info gathering is the problem, or the DotNet ListView creation.
Create a Sphere, add a Genome, drop some nodes into it and call
debugResult = GenomeGlobalInterface.EvaluateDebug theNode theIndexwhere theNode is the $Sphere001 and theIndex is the modifier index (1).
This should return an IObject you can call methods on:
theMinMaxMean = debugResult.GetMinMaxMeanValues() --returns the min/max/mean values for the nodes as array of arrays
theValues = debugResult.GetIterationValues theIteration --returns the debug values for the nodes as array of arrays
--where theIteration is an integer corresponding to the current iteration, e.g. in vertex mode 1 means first vertex
See if these work for you. If they do, I will have to take a closer look at the DotNet ListView code. I might be doing something bad there…
(You are invited to look at it too 
)
“Good” news - I was able to reproduce the problem on my machine.
Looks like it is in the DotNet code, but it could be a side effect of something else.
Will keep you posted.
I rewrote a large part of the code, and it looks like the actual rebuilding of the IObject (when you press the Update button) is causing the memory corruption.
Once the data is created, I can change the display (Nth, Count, Previous/Next) without any problems, but updating multiple times causes memory problems.
I will pass it to Darcy to take a closer look.
You probably already caught this since you refactored a large part of the code, but I found the problem (at least, why it wasn’t working in my case).
Genome_MagmaFlow.ms, line 292
[code]local theStep = spn_nth.value
if theStep > theCount do theStep = theCount-1
for i = 1 to theCount by theStep do
(
theValues = debugResult.GetIterationValues i
append resultsArray #(i, theValues)
)
[/code]
When theCount == 1 you get an infinite loop (since theStep is now 0). I fixed it by changing 292-293 to:
local theStep = amax 1 (amin (theCount-1) spn_nth.value)Also, it seems the value of spn_first wasn’t actually being used anywhere, so I added that to the same loop:
[code]local theFirst = amin theCount spn_first.value
local theStep = amax 1 (amin (theCount-1) spn_nth.value)
for i = theFirst to theCount by theStep do
(
theValues = debugResult.GetIterationValues i
append resultsArray #(i, theValues)
)[/code]
Martijn
Thanks for catching that special condition!
There is also a true memory corruption problem when running this with thousands of vertices and dozens of operators.
Pressing Update causes Garbage Collection warnings first, and and after a while Max locks up or crashes to desktop.
We suspect it is related to the IObject created by the Genome debug method which is not gc-ed correctly.
I have optimized the code to read directly from that object while populating the list, instead of moving the data to an intermediate array (last week I was lazy and used the existing function from Magma, but that meant the data was stored twice). Now it is much faster to update the spinners, but if you press Update, it will cause a crash sooner or later.
Debugger memory problems should be fixed as of Beta 5 (April 5th, 2012).
Note that we also added an artificial limit to process just the first 10,000 iterations (after I run out of memory with millions of vertices in one scene).
The actual limit is exposed to MAXScript and will be exposed in the UI in Beta 6 next week.
Bonus feature: If you select a row in the Debugger, the values will also appear in the nodes’ output sockets names in the editor, making it even easier to follow the data flow.