Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

memory_profiler reporting itself #49

Open
ohaddahan opened this issue Sep 19, 2017 · 6 comments
Open

memory_profiler reporting itself #49

ohaddahan opened this issue Sep 19, 2017 · 6 comments

Comments

@ohaddahan
Copy link

ohaddahan commented Sep 19, 2017

I noticed today (I also updated my Gems today , so it might be related).
That memory_profiler now reports it's own footprint as a part of the analysis report.
I believe this wasn't the case before and it creates a false top level analysis metrics.

See the example here:
https://gist.github.com/ohaddahan/cdaef533abf963f16f7bccec141c2185

Most of the memory report is actually caused by memory_profiler.


Total allocated: 28693134 bytes (206218 objects)
Total retained:  28671354 bytes (205866 objects)

allocated memory by gem
-----------------------------------
  28664857  memory_profiler-0.9.8
     26437  chili-hunter-2/app
      1840  activesupport-5.0.0
@dgynn
Copy link
Collaborator

dgynn commented Sep 25, 2017

I think you may have mixed the .start/.stop mode with the .report mode in your IRB session.

I can recreate memory_profiler self-reporting by calling MemoryProfiler.start first. I expect that your IRB session got into a weird state this way.

MemoryProfiler.start
MemoryProfiler.report { "allocate one string" }.pretty_print

Total allocated: 1496 bytes (10 objects)
Total retained:  232 bytes (1 objects)

allocated memory by gem
-----------------------------------
      1456  memory_profiler/lib
        40  other
...

Please re-open this issue if can recreate the problem in a clean IRB session or a script.

@dgynn dgynn closed this as completed Sep 25, 2017
@seanlinsley
Copy link

BTW @dgynn unless GitHub has changed how it works, issue creators can't re-open issues that a contributor has closed.

@dgynn
Copy link
Collaborator

dgynn commented Sep 25, 2017

Thanks @seanlinsley I didn't realize that.

@ohaddahan
Copy link
Author

ohaddahan commented Sep 25, 2017

@dgynn it's a 100% not due to me calling MemoryProfiler.start since I never use that and always opt for :

report = MemoryProfiler.report do
......
  end 
  report.pretty_print( to_file: 'file.txt' )

But it's a little spurious , I'll try creating a more consistent testcase.

@dgynn
Copy link
Collaborator

dgynn commented Sep 25, 2017

@ohaddahan Oh, here's a possible cause. If the block of code being reported on throws an exception we are not cleaning up correctly.

MemoryProfiler.report { raise "error" } rescue nil
MemoryProfiler.report { "allocate one string" }.pretty_print

Total allocated: 1496 bytes (10 objects)
Total retained:  232 bytes (1 objects)

allocated memory by gem
-----------------------------------
      1456  memory_profiler/lib
        40  other

Is it possible that happened in your IRB session? That is something we should handle better.

@dgynn dgynn reopened this Sep 25, 2017
@ohaddahan
Copy link
Author

@dgynn might be it , I'll give a try. Sounds possible since ctrl+C is quite common during interactive debug session :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants