Meshing memory workflow

Next
 From:  BurrMan
4385.1 
Hi Michael,
I'm not sure if I asked this before as it seems familiar.. Maybe there was an ini setting.. When meshing a model, if I create a dense mesh option that "runs out of memory", then I try to re-launch the mesh operation and my old value is selected and crashes MoI before I can change the value to something less.. I'm not quite sure if this needs to be dealt with as it is a rare occasion.. Just bringing it up.
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Michael Gibson
4385.2 In reply to 4385.1 
Hi Burr, there isn't any .ini setting for dealing with that which I can remember.

The tricky part is that once you have completely exhausted all memory once, it can make various code paths fail in ways that are hard to account for. It's pretty good at catching running out of memory while in the mesh creation itself, but you must have run out of memory again during some other auxilary calculation instead of the main mesh creation one.

Just in general out of memory is a difficult condition to handle well, it just does not get tested well since it can change the code flow in so many different areas.

If you had a crash dump created (a moi_report1.zip , or moi_report2.zip file) can you please send it to me at moi@moi3d.com so I can try to see where the crash happened? But there may not have been one created because running out of memory can also interfere with being able to create a crash dump as well.

Another thing that can happen when you completely run out of memory once is that you can be left with a situation called "memory fragmentation", where all the available memory is kind of cut up into small blocks and that can interfere with operations after that. So if you hit that "out of memory" warning once, your best bet is usually to exit MoI and start a new session.

Since handling running out of memory is so difficult (since like I mentioned, it means different code paths taken in a whole lot of different areas) it's just not generally something that I'll be able to get to the same level of reliability as I try with regular operation.

- Michael
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  BurrMan
4385.3 In reply to 4385.2 
Hi Michael,
Yeah, I wont need to send the dump (Unless you really want one).. It was the "second one" that creates the crash... I havnt had a crash on an out of memory situation.. It was when I hit that, then waited after canceling it, and trying to mesh "again", where the same settings that created the memory issue are presented and crash the MoI executable at that point.. Just knowing I shouldnt try to continue at that stage is good...

Maybe the out of memory error should carry that info with it, like "You should probably restart MoI now" kind of thing... :o

Anyway, thanks for the response.
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
 From:  Michael Gibson
4385.4 In reply to 4385.3 
Hi Burr, if a dump was created, please do e-mail it to me since that may give me a clue as to what particular area needs some additional checks for out of memory handling.

I do try to fix those up when I'm able to - the difficult part is that there are many of them lurking around in different places and it's only when you run out of memory in that particular section of code that it will cause a problem.

So actually since it's a hard to reproduce problem sending the crash dump if it was generated would be helpful...

Thanks,
- Michael
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged
 

Reply to All Reply to All