016097 Crashes this scene on playback
Steps to reproduce
1. Open attached scene and play animation.
Result: before the time slider reaches the end of the 1000 frames = Max Crash with no save
Reinstall 016096 and no crash on playback with no issues
The minidump shows it happening in a very weird place will no callstack linking to actual tyFlow code. Combine that with the fact that I can't repro it here and I'm stumped.
One thing to mention: when I open the file I get a bunch of missing asset errors (3 jpgs, an hdr and 2 xmls). Would you mind sending those over? Can send to support@tyflow.com if you don't want to attach them publicly. Maybe the issue is triggered by an asset I'm missing.
Well that is a head scratcher. So, I opened the scene on my older machine and tested, no crashes.
Then back on my main machine, I stripped out all assets, same problem. But, then I made a new scene and merged the entire cleaned stripped version and got no crash.
So, something in THAT file on THAT machine was funky.
Case closed, I would just move on and not look back.
One last thing to try to perhaps narrow down the original cause....try disabling any multithreading (set max threads to 1 on the problem flow) and see if it works...
OK, I spoke too soon.
Thought I had solved the problem but no. I had 016096 installed and thought I had 016097 installed, sorry. Been going back and forth so much doing this test.
I assumed it was something in that scene but it is every scene crashing on playback.
My other machine does not crash at all.
I created the most simple scene possible, just 100 sphere shapes moving in random directions and that crashed with 016097 but not 016096
Attached are a cleaned scene that always crashes quickly and the minidump
11-28-2020, 09:25 PM (This post was last modified: 11-28-2020, 09:26 PM by tyFlow.)
Are you doing anything weird with your max instance? Manually setting processor affinity or anything like that? Running Max in a VM instance? The fact that it's crashing in very simple scenes is indicative of a bigger problem, not necessarily related to tyFlow.
(11-28-2020, 09:25 PM)tyFlow Wrote: Are you doing anything weird with your max instance? Manually setting processor affinity or anything like that? Running Max in a VM instance? The fact that it's crashing in very simple scenes is indicative of a bigger problem, not necessarily related to tyFlow.
No, nothing weird at all. And I just finished a massive project with TyFlow in every single scene and had a very stable working situation, since September when I got this new Boxx maybe I had Max crash maybe ten times and I've been at it 8 to 12 hours a day. The problem is this new version 16097 on this new machine during viewport playback.
But, I have been opening up my old scenes from this big COVID19 project with 16097, I play them back with no problem. These are some big scenes as well.
The crash so far as I can tell are with newly created scenes in 16097 or scenes edited with 16097.
Was wondering if its something with the caching but I disabled the cache and it played longer but still crashed.
I did take a crashing scene and was able to make a TyCache that plays back fine.
Taking a scene that I made in 16097 and loading it up in 16096 will always play fine.
Hmm well then I guess it remains a mystery. The biggest part of the mystery is the fact that none of the operators you're using were impacted by changes in v0.16097 from what I can tell...and combined with the fact that both minidumps point to strange places in memory that aren't directly related to tyFlow code.
Did you try the thing I mentioned above where you limit max threads to 1 and see if that helps it?
(11-29-2020, 12:10 AM)tyFlow Wrote: Hmm well then I guess it remains a mystery. The biggest part of the mystery is the fact that none of the operators you're using were impacted by changes in v0.16097 from what I can tell...and combined with the fact that both minidumps point to strange places in memory that aren't directly related to tyFlow code.
Did you try the thing I mentioned above where you limit max threads to 1 and see if that helps it?
Yes, multithreading settings had no difference. I've tried so many different tweaks and changes.
Is there anything you changed that deals with memory or display?
If you change the display mode of all particles to a point-based display...so that no meshes are visible in the viewport...does the issue still occur?
The only place in tyFlow code where I detach threads (which would explain why your crash stacktrace does not fall back directly to tyFlow code) is during mesh cleanup. I'm wondering if maybe some irregular MSVS compilation optimization in that section of code is causing issues on your hardware. That may explain why this build is affecting you even though no relevant code to your scene was changed.
11-29-2020, 07:16 AM (This post was last modified: 11-29-2020, 07:50 AM by AndyMurdock.)
(11-29-2020, 06:08 AM)tyFlow Wrote: Nope, not that I can think of.
If you change the display mode of all particles to a point-based display...so that no meshes are visible in the viewport...does the issue still occur?
The only place in tyFlow code where I detach threads (which would explain why your crash stacktrace does not fall back directly to tyFlow code) is during mesh cleanup. I'm wondering if maybe some irregular MSVS compilation optimization in that section of code is causing issues on your hardware. That may explain why this build is affecting you even though no relevant code to your scene was changed.
Setting the display to small dot does NOT crash, then changing the display to Geometry will crash that same playback view. It will play for a 100 frames or so and crash. Different spots on the time line.
Now I recall one difference, this trouble machine is using a nightly of VRay. Would a beta of VRay possibly contribute to this issue?
Andy
Heh well it's not a fix unfortunately, just a workaround. Glad to hear it works but I had to disable some internal optimization systems in this one. Now I've gotta dig in and figure out the real issue so I can turn them back on.
(11-29-2020, 05:09 PM)tyFlow Wrote: Heh well it's not a fix unfortunately, just a workaround. Glad to hear it works but I had to disable some internal optimization systems in this one. Now I've gotta dig in and figure out the real issue so I can turn them back on.
Understood. Send me a new build if you want me to try it.
