使用 Java 1.6 调用 magic_buffer 的 Redhat AS 4 seg 错误
我有一个 java 类，它通过 JNI C++ 类调用 C++ 类来访问 libmagic.so 提供的“文件”命令功能。
- C++ 类作为 C++ main() 编译并运行良好
- 它在运行 java 1.5 和 1.6 的 RHEL 5 上运行良好；
- 它在运行 java 1.5 的 RHEL 4 上工作正常
- 它在运行 java 1.6 的 RHEL 4 上抛出 seg 错误 26234
seg 错误：
在调用时发生 char* retptr = magic_buffer(cookie, bigbuf, 1000); 没有故障时 char* retptr = “一个不错的安全字符串”;被替换。这就是为什么我得出结论，seg 错误发生在这次调用处。
我使用另一种调用，char* retptr = magic_file(cookie,”/usr/include/magic.h”);调试缓冲区问题，因为此调用返回相同的文件类型消息，仅需要文件的完全限定路径名，而不是充满文件内容的缓冲区。它还会在 RHEL4/java 1.6 测试虚拟机上引发 seg 错误。因此，我得出的结论是，问题似乎不是代码中的错误指针或缓冲区溢出。
magic_buffer 是对 libmagic.so 的调用。在前面的代码中，对该库进行了其他成功的调用。但是，此调用涉及 lib magic 数据库 /usr/share/file/magic。
将 C++ 编译为可执行文件并在有问题的计算机上运行它效果很好。
以下是一些结论：
A. 由于 #4，存在 JNI 参与
B. 由于 #1/#2，我不认为这是 JNI 实现问题。
C. 由于 #1、#2 和 #4，我不认为这是 C++ 实现问题。
有什么建议或意见吗？ （最初在 VMWare 上运行，现在在没有 VM 参与的情况下进行测试）
I have a java class that calls a C++ class via a JNI C++ class to access the 'file' command functionality provided by libmagic.so.
- The C++ class compiles and run fine as a C++ main()
-It works fine on RHEL 5 running java 1.5 and 1.6;
-it works fine on RHEL 4 running java 1.5
-it throws a seg fault 26234 on the RHEL 4 with java 1.6
The seg fault:
Occurs at the call char* retptr = magic_buffer(cookie, bigbuf, 1000);
No fault when
char* retptr = “a nice safe character string”; is substituted. This is why I conclude that the seg fault occurs at this call.I use an alternative call, char* retptr = magic_file(cookie,”/usr/include/magic.h”); to debug buffer problems, as this call returns the same file type message requiring only the fully qualified path name of the file, rather than a buffer full of the file content. It also throws the seg fault on the RHEL4/java 1.6 test VM. Thus, I conclude the problem does not appear to be bad pointers or overflowing buffers in my code.
magic_buffer is a call to libmagic.so. In the code previously, other successful calls to this lib are made. This call, however, involves the lib magic database /usr/share/file/magic.
Compiling the C++ as an executable and running it on the problem machine works just fine.
Here's some conclusions:
A. There is JNI involvement, because of #4
B. Because of #1/#2, I don't believe it is a JNI implementation issue.
C. Because of #1, #2, and #4 I don't believe it is a c++ implementation issue.
Any suggestions or comments? (initially run on VMWare, now tested with no VM involvement)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我的第一个建议是尝试找到一个纯 Java 的替代方案。 此页面列出了许多替代方案。 Apache Tika 和 JMimeMagic 看起来很有前途。
我的第二个建议是使用
Process在单独的进程中运行file命令，并从命令的标准输出中获取所需的信息。如果您需要每秒执行数百次，这可能会出现（咳咳）性能问题，但对于偶尔使用应该没问题。My first suggestion is to try and find a pure Java alternative. This page lists a number of alternatives. Apache Tika and JMimeMagic look promising.
My second suggestion is to use
Processto run thefilecommand in a separate process and scrape the information you need from the command's standard output. This may have (ahem) performance issues if you need to do this hundreds of times a second, but for occasional use it should be fine.