1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Ran out of memory, even though I have 16 gB

Discussion in 'Using Alibre Design' started by JST, Jan 3, 2020.

  1. JST

    JST Alibre Super User

    Ran out with a model that fits in 4 gB.... Opened, then closed for subassembly modification several times, then ran out of memory, according to the error message, when opening a very small subassembly for modification.

    Obviously the ":memory leak" is not yet fixed.

    This has happened now on three very different machines and OS versions, on many totally unrelated models so NOT specific to anything but "me" and the use of a Microsoft OS.
  2. simonb65

    simonb65 Alibre Super User

    This can be a bit misleading as you didn't say what the memory usage was before you opened the model. Have a look at your task manager and see a) what tasks are using your memory, b) how much memory Alibre is using at startup, c) how much memory Alibre is using when its loading in the model d) how much memory is released by Alibre when you close a model. The latter is not always a true indication with managed applications that use memory pools, thread pools and garbage collectors! Running out of memory isn't or may not be just down to a single application ... although I have seen memory leaks in Alibre in the past and I'm not convinced they are all resolved either. I'd be doing some memory/performance profiling if I were on the dev team ... but, to give them the benefit of the doubt, I suspect they may (read should) already be doing that.
  3. JST

    JST Alibre Super User

    Prior unreleased memory? No, fired up cold and started in with Alibre. it is definitely an Alibre issue.

    No problems until a number of large models had been loaded, worked with, and saved. Finally, one was loaded, and a part in it loaded for modification ( do not like "edit here" in complex models). That last part came up with a load error, "out of memory". Had to close Alibre and re-start it, which always cures the problem.

    Same exact issue previously seen with 7 and XP. I feel sure it is known, I have brought it up, and have sent it in to Support, likely going back to the 3DSys days.

    Was once told it was an OS problem that they could do nothing about. But when I was using Solidworks, it NEVER happened, even with large models. I could do that all day and never saw an issue.
  4. simonb65

    simonb65 Alibre Super User

    In all my 36+ years developing software, I've never had one case of an OS being responsible for memory leaks! Its always the application and it's always fixable! Just need the right approach to software design and the ability to profile and unit test it.
  5. JST

    JST Alibre Super User

    Agree. But it was the present Alibre folks who pointed at the OS...... With Windows I could almost believe it.....
  6. simonb65

    simonb65 Alibre Super User

    I have a PCB package which, a few years ago, didn't scale fonts very well when zooming in/out. I reported it, and after a few months of them saying it was a Microsoft issue with the way text width (in pixels) is calculated by the OS. So, I wrote a small demo showing them how you scale fonts in a dynamic UI. 2 days later I got a patch which fixed the issue! It was nothing to do with the OS, Windows or Microsoft.

    It's sometimes it's easier to blame the OS than to sort the issue, or from my experience, developers say things like that if they either don't fully understand the problem or just don't know how to begin to debug it (I had one employee that was like that and I got tired of constantly fixing his work that we parted company!).

    I know Alibre is not robust by the way it throws exceptions (not handled by Alibre), the way it errors with NULL pointers (not checked by Alibre), the way it doesn't manage file handles (Alibre occasionally dies trying to open network files because it doesn't handle the file open error results), the way its slow at redrawing when you incrementally add/load parts to an assembly (which I can demonstrate through the API and is caused by calculations repeatably being done and not deferred until everything is loaded ... MOI isn't slow, 3DConnexion Viewer isn't slow), the way Alibre dies if you let your machine sleep (because Alibre does not handle the window Sleep/Resume/Hibernate notifications from windows), the big red cross in some views that was blamed on the OS (it's actually the default thing the OS draws in a user control if an exception occurs in your OnPaint handler or it tries to use a NULL pointer and you don't handle it) ... so what makes you think that they are 100% on top of memory management?

    10 years ago, I wrote an application used by some of the top European banks to remotely manage their server health, it had over 50,000 servers connected to it reporting their health with interruptions from network outages and reliability. The constant connection/disconnection of comms between the servers was a nightmare in terms of memory management. It took over 2 months of instrumentation, profiling and testing just to make it 100% bomb proof in terms of memory leaks, etc. If you build application functionality on top of a framework that is not robust, the problems just continue and get worse. Windows provides the tools and error handling to report back to your application if you do something bad. If you don't handle that information and proactively do something about it, your program crashes (as we have seen from numerous posts here in the last 12 months).
    Last edited: Jan 4, 2020
    NateLiqGrav and pottersfriend like this.
  7. JST

    JST Alibre Super User

    Trust me, I do NOT think that. However, as I have been a designer of other things (power electronic devices, amplifiers, and motor controls), I do not have your insight, just sufficient programming experience to know what CAN happen, and to suspect that it is Alibre at fault here, which is why I bring it up.

    I have sufficient programming experience to also know that other errors can cause the things that I have mentioned, odd errors with lofts and fillets where no error should occur, "identical" dimensions that cannot align, etc, and that those things can be caused by failure to handle truncation predictably, failure to clear or initialize variable locations, etc, etc. Also obscure issues with the compiler, to be fair.

    However, Windows has "not exactly been robust" for so long that my comment about "almost" believing the OS claim is not entirely just me making a joke.....
  8. Andrew Roth

    Andrew Roth Senior Member

    Monitoring User objects and Graphic Device Interface objects, you will see that after closing a file these objects are not released by alibre. after a long session or perhaps just with a large complex file, this is going to cause trouble. After opening and closing an assemble file 8 times alibres user objects and GDI objects count continues to grow. from a programmers view this is objects (pens fonts brushes) being created but not deleted. used to cause crashes on my old system which had little memory. My files don't tend to get very large so I have not gotten to the point where this causes issues on my new system. I've programmed a few memory leaks in my days, not always easy to track down. And yes some of these were do to windows "glitches", especially with api font usage.

Share This Page