- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - Linux
- >
- Re: JNI programming through aCC on HP-UX 11.00
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-17-2008 01:14 AM
тАО01-17-2008 01:14 AM
JNI programming through aCC on HP-UX 11.00
I've got clients working correctly, however when the library is run in the 3rd party app, it just stops (after the JNI calls finish successfully).
However, it does not abort (no core!). No exceptions are thrown, nothing.
I don't have access to the 3rd party app's code, nor runtime evvironment, so I'm relying on cout statements (non-buffered). I've traced the failure to where it's coming out of a try block, however it never reaches the code after the try block.
.
.
try
{
.
.
cout << "LIBSCM MSG.25 - finishing try block" << endl;
cout.flush();
}
catch (...)
{
.
.
}
cout << "LIBSCM MSG.29 - About to return [" << status << "]" << endl;
cout.flush();
return status;
}
I see MSG.25, but not MSG.29. I've tried moving msg 29 and tghe return into the try block and the cout displays, but nothing returns.
I suspect a stack issue, but without diagnostics (stack trace, or stepping through the executable, etc.) I can't find the issue.
I've 2 questions, has anyone come against a similar issue before? How can I output a stack trace at various points in the app (I suspect the Java call may be corrupting the stack)?
I've tried the following (as recommended on a HP website I found :
#include
extern void U_STACK_TRACE();
.
.
signal(SIGSEGV, U_STACK_TRACE);
However, I get a compile issue saying the following:
Error 212: "scmie.cxx", line 911 # Argument type 'void ()' does not match expected parameter type 'void (*)(int)'.
signal(SIGSEGV, U_STACK_TRACE);
^^^^^^^^^^^^^
Any help appreciated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-17-2008 01:21 AM
тАО01-17-2008 01:21 AM
Re: JNI programming through aCC on HP-UX 11.00
I'd suggest a debugger like gdb
SEP
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-17-2008 01:52 AM
тАО01-17-2008 01:52 AM
Re: JNI programming through aCC on HP-UX 11.00
Unfortunately, I can't use a debugger, I have no access to the 3rd parties runtime environment, nor their code. Also, the app in question is running on a tuxedo environment.
I can run my own clients through a debugger, however, they are working OK.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-17-2008 04:11 AM
тАО01-17-2008 04:11 AM
Re: JNI programming through aCC on HP-UX 11.00
Both are obsolete and no longer supported.
>relying on cout statements (non-buffered).
The proper debug tool is fprintf(stderr,), not iostream.
>cout.flush();
Why are you doing flush? Evil endl does this.
>but without diagnostics (stack trace, or stepping through the executable, etc.) I can't find the issue.
What's why you use a debugger as SEP says. You can attach to the process to see where it is.
>How can I output a stack trace at various points in the app (I suspect the Java call may be corrupting the stack)?
You can create a signal handler for SIGINT and call U_STACK_TRACE. If the stack is corrupted, you won't be successful.
>I've tried the following (as recommended on a HP website I found:
extern void U_STACK_TRACE();
For C++ you must use: extern "C" void U_STACK_TRACE();
signal(SIGSEGV, U_STACK_TRACE);
This is illegal. You must create a signal handler that calls U_STACK_TRACE, then aborts/exits.
>I get a compile issue saying the following:
Error 212: # Argument type 'void ()' does not match expected parameter type 'void (*)(int)'.
signal(SIGSEGV, U_STACK_TRACE);
You must use a hammer to make it work, since it doesn't have the right signature:
signal(SIGSEGV, (void(*)(int))U_STACK_TRACE);
>I can't use a debugger, I have no access to the 3rd parties runtime environment, nor their code. Also, the app in question is running on a tuxedo environment.
None of these things will stop you from using the debugger. Either start from the beginning or attach to the process.
The latter should be easy since you mentioned you can put printf calls in the try/catch, just add a read or a long pause so you can attach.
- Tags:
- U_STACK_TRACE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-18-2008 02:08 AM
тАО01-18-2008 02:08 AM
Re: JNI programming through aCC on HP-UX 11.00
try {
{
// original block ...
fprintf(stderr, "LIBSCM MSG.25 - finishing try block\n");
}
fprintf(stderr, "LIBSCM MSG.25a - finishing try block, locals destroyed\n");
} catch