You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have come across a closed issue(#33 ) that described the phenomenon. Upon verification, it seems that it is necessary to enable the debug=true option in the cargo build command. When using the release option, the debug parameter defaults to false. I have two concerns regarding this observation:
May I inquire why, in the absence of support for --strip=none, it is possible to print function names without fully enabling debug information? It appears that information from the debug mode is not entirely decoupled from the dependencies on stripping.
In practical production processes, it is highly likely to use the release option. However, if issues arise in a production environment, it could be challenging to pinpoint the root cause. Could you shed light on how the community has considered addressing this phenomenon?
The text was updated successfully, but these errors were encountered:
I have re-evaluated the issue and found that it is not related to the debug parameters. I can still see the function names using cargo build --release. However, when I copied jeprof, the binary file, and the out heap file to another machine that is nearly identical, executing jeprof --dot only displays memory addresses. Therefore, the problem arises due to a change in the environment.However, it is still worth exploring what information in the environment leads to this problem.
I have come across a closed issue(#33 ) that described the phenomenon. Upon verification, it seems that it is necessary to enable the debug=true option in the cargo build command. When using the release option, the debug parameter defaults to false. I have two concerns regarding this observation:
The text was updated successfully, but these errors were encountered: