在 Valgrind 下的 Sun VM 中运行 JNI 应用程序
在 valgrind 下运行时，sun JVM 会发出大量额外的噪音，这使得跟踪应用程序中的内存问题非常具有挑战性。
我想找到一个抑制文件或虚拟机运行时模式，它将消除虚假的内存错误，以便在这种情况下将小麦与谷壳分开。 有什么建议么？
The sun JVM spits out a LOT of extra noise when run under valgrind, which makes tracking memory problems in the application very challenging.
I'd like to find either a suppression file, or a VM runtime mode, that will strip out spurious memory errors in order to separate the wheat from the chaff in this situation. Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在 Java 应用程序之外分析此本机代码怎么样？ 通常，JNI 代码是一些非 Java 特定库的包装器。 不确定对于您的具体情况是否如此，但如果是这样，那么也许可以通过围绕该库编写一个简单的 C 或 C++ 测试框架来隔离内存问题？
如果您的框架采用 C++，那么您也许还可以提供自己的 new 和 delete 运算符并自行跟踪内存使用情况。 您必须收集统计数据并使用一些脚本处理它们，但它可以很好地工作。
What about profiling this native code outside of the Java application? Usually the JNI code is a wrapper around some library that is not Java specific. Not sure if that is true for your specific case, but if it is then maybe the memory problems can be isolated by writing a plain C or C++ test framework around that library?
If your framework is in C++ then you might also be able to supply your own new and delete operators and track memory usage yourself. You'll have to collect statistics and process them with some scripts but it can work well.
我无法回答您发布的问题，但您能详细说明您遇到的问题吗？
换句话说，您能否告诉我们它是否是...
我最近不得不调试一个有问题的 Java/C（运行了 30 多分钟后），结果发现它正在使用释放后的内存。 我尝试使用 dmalloc（我的自定义内存泄漏库 Valgrind），但没有一个能按我的需要工作。
最终，我围绕 free、malloc、calloc、realloc 创建了一组简单的包装器，它们只是将内存地址和大小打印到文件中。 在它中止之后（在 GDB 内），我可以及时回溯并找出内存何时被释放以及未删除的引用在哪里。
如果您的问题是在 C/C++ 中，并且您可以在调试器中捕获错误，这可能对您有用。 是的，这很乏味，但也许并不比筛选兆字节的 Valgrind 输出更糟糕。
希望有帮助& 祝你好运。
I can't answer your posted question, but can you elaborate on what problem you're having?
In other words, can you tell us if it is...
I recently had to debug a Java/C that had issues (after 30+ minutes into its run), which it turns out was using memory after it had been free'd. I tried using dmalloc, a custom memory leak library of mine, Valgrind and none worked as I needed.
Eventually I created a simple set of wrappers around free, malloc, calloc, realloc that simply printed memory addresses and sizes to a file. After it aborted (within GDB) I could backtrack in time and figure out when the memory was free'd and where the references were that did not get removed.
IF your issue is in C/C++ and you can trap the error in a debugger this might work for you. Yes, it's tedious, but maybe no worse than sifting through megabytes of Valgrind output.
Hope that helps & good luck.
虽然不像 valgrind 那么漂亮（根据我读过的内容），但您可以尝试 jmap 和 jhat。 这些工具允许您拍摄正在运行的进程的快照并查看发生了什么。 我已经使用这种技术来解决简单的内存泄漏问题，而且效果很好。 但是，如果内存问题是由非 jvm 分配引起的，这将无济于事。
While not as spiffy as valgrind (based on what I've read), you might try jmap and jhat. These tools allow you to take a snapshot of the running process and see what's going on. I've used this technique for simple memory leaks and it's worked well. However, if the memory problems are caused by non-jvm allocations, this won't help.