• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Custom IC SKILL
  3. memory leak?

Stats

  • Locked Locked
  • Replies 4
  • Subscribers 143
  • Views 16080
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

memory leak?

drdanmc
drdanmc over 7 years ago

Are there any known ways to confuse the garbage collector in skill?  I have a moderately large simulation that uses Ocean to step through a number of conditions.  For each condition, there is a transient analysis followed by some post-processing code which produces a waveform family (a waveform family for each transient sim).  I don't think anything in my code should be expanding the memory used each time through the loop because in simplified form it looks like:

foreach(sim_setup all_sim_setups

  ;; close all viva windows (in case that was a memory killer)

  foreach(win awvGetWindowList() awvCloseWindow(win))

  ;; reset the remaining window

  awvResetWindow(awvGetCurrentWindow() ?force t)

  ;; configure the sim with desVar() calls, may be update some of the simulation analysis settings

 

  printf("memoryAllocated() returned %g\n", memoryAllocated()) ;; check memory

  gc()  ;; force garbage collection

  run()

  ;; access some results, do math (including a fairly large number of calls to dft()), plot various results,

  ;; write out some png files with saveGraphImage(), dump some text files with

  ;; fp=outfile("somefile.txt") fprintf(fp, "stuff") close(fp)

)

What I see is before the first run, the memory allocated is low and then it jumps a bunch after the first sim.  But after that I'm growing by about 300Mb each time through:

  memoryAllocated() returned 372.344
Done - free list cells = 2724041, bytes allocated for all types = 182042907
memoryAllocated() returned 5310.04
Done - free list cells = 2804791, bytes allocated for all types = 200569114
memoryAllocated() returned 5606.61
Done - free list cells = 2813000, bytes allocated for all types = 200666771
memoryAllocated() returned 5908.91
Done - free list cells = 2804808, bytes allocated for all types = 200776481
memoryAllocated() returned 6181.61
Done - free list cells = 2802109, bytes allocated for all types = 200945203
memoryAllocated() returned 6477.51
Done - free list cells = 2799522, bytes allocated for all types = 201107058
memoryAllocated() returned 6779.2
Done - free list cells = 2790640, bytes allocated for all types = 201284560
memoryAllocated() returned 7049.48
Done - free list cells = 2809618, bytes allocated for all types = 201976762
memoryAllocated() returned 7345.52
Done - free list cells = 2806987, bytes allocated for all types = 202142740
memoryAllocated() returned 7647.66
Done - free list cells = 2796874, bytes allocated for all types = 202318483
memoryAllocated() returned 7917.4
Done - free list cells = 2815944, bytes allocated for all types = 203002061
memoryAllocated() returned 8214.05
Done - free list cells = 2813363, bytes allocated for all types = 203163430
memoryAllocated() returned 8515.86
Done - free list cells = 2802934, bytes allocated for all types = 203276529
memoryAllocated() returned 8784.89
Done - free list cells = 2800332, bytes allocated for all types = 203505040

and then, *boom*, ocean fails with:

simulate...
*Error* ipcBeginProcess: Unable to fork() child process due to system error
(Consider exiting any unnecessary applications) - "Cannot allocate memory"
*

I've had the sense that maybe the simulation post processing code is where the leak is because I have a waveform calculator version and have noticed running in ADE-L that repeated sims seem to cause the memory use to keep growing.

So... that gets back to the original question.  What should I be looking for that causes memory leaks?  I would have thought it would be things like opening more and more windows without closing or creating new variables with new names each time through a loop or adding to a list or table or waveform family each time.  But as near as I can tell I really shouldn't be needing any additional storage after the first time through.

Thanks

-Dan

  • Cancel
Parents
  • Andrew Beckett
    Andrew Beckett over 7 years ago

    Hi Dan,

    Please contact customer support about this. I recently filed a CCR related to memory growth when certain waveform manipulation functions in OCEAN where memory growth was only partly abated by calling gc(). The issue is that there is some caching of waveform data for efficiency (so that accessing the same waveform more than once doesn't require re-reading off disk), and gc() doesn't cause that always to be reclaimed. You issue might be something else, or some other scenario.

    Best route is customer support so that we can investigate properly, reproduce the problem, and get R&D involved in fixing it.

    Regards,

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • drdanmc
    drdanmc over 7 years ago in reply to Andrew Beckett

    Thanks.  I'll see if I can distill down to more directed test case.  

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • drdanmc
    drdanmc over 7 years ago in reply to drdanmc

    SR submitted.  I was able to fairly easily reproduce this purely in skill by just creating a waveform, calling dft() and doing it again a bunch of times.  Didn't even need to invoke spectre or access real simulation results.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • drdanmc
    drdanmc over 7 years ago in reply to drdanmc

    Here is a workaround

    ;; really leaky:

    dft(my_signal, Tstart, Tstop, Nfft, "Rectangular", 1, 1)

    ;; workaround that is not nearly as bad (note the extra 0 at the end)

    dft(my_signal, Tstart, Tstop, Nfft, "Rectangular", 1, 1, 0)

    but I still see evidence of other less severe leaks, probably related to what you have observed in the CCR you mentioned.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • drdanmc
    drdanmc over 7 years ago in reply to drdanmc

    Here is a workaround

    ;; really leaky:

    dft(my_signal, Tstart, Tstop, Nfft, "Rectangular", 1, 1)

    ;; workaround that is not nearly as bad (note the extra 0 at the end)

    dft(my_signal, Tstart, Tstop, Nfft, "Rectangular", 1, 1, 0)

    but I still see evidence of other less severe leaks, probably related to what you have observed in the CCR you mentioned.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information