search

SAP / SapMachine

An OpenJDK release maintained and supported by SAP
https://sapmachine.io
GNU General Public License v2.0
504 stars 92 forks source link

Don't try to resolve CodeBlobs in malloc trace dumps #1794

Closed schmelter-sap closed 1 week ago

schmelter-sap commented 1 month ago

This removes the overoptimistic feature to get the code blob of a PC on the stack when printing stack traces. This could lead to misleading methods being printed, when the blob was moved or deleted in the meantime.

fixes #1789

SapMachine commented 1 month ago

Hello @schmelter-sap, this pull request fulfills all formal requirements.

SapMachine commented 2 weeks ago

Hello @schmelter-sap, this pull request fulfills all formal requirements.

schmelter-sap commented 2 weeks ago

The non-backtrace code also stops at the first frame with a code blob associated (due to the fr.cb() != nullptr check in MallocStatisticImpl::capture_stack()).

reinrich commented 2 weeks ago

The non-backtrace code also stops at the first frame with a code blob associated (due to the fr.cb() != nullptr check in MallocStatisticImpl::capture_stack()).

That's what I meant. I wasn't sure if this was the desired behavior. So (at most) one frame with an associated code blob is added to the stack trace. Its callers are not added. And that's on purpose. The malloc trace is not meant for analyzing native memory problems originating from java. E.g. leaks where memory is allocated with Unsafe::allocateMemory cannot be analyzed, correct?

schmelter-sap commented 2 weeks ago

That's correct. We would see that a memory leak was caused by Unsafe::allocateMemory, but would not see the Java code allocating the leaked memory. The same can be said for direct byte buffers.

SapMachine commented 1 week ago

Hello @schmelter-sap, this pull request fulfills all formal requirements.