JNI programming through aCC on HP-UX 11.00

[Graham Kelly_1]

Hi, I'm currently writing a library for 3rd party applications to access internal Web Services and EJBs on our network. The 3rd party apps are written in Cobol and C, so I'm creating the library using aCC (version 3.37).

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.

[Steven E. Protter]

Shalom,

I'd suggest a debugger like gdb

SEP

[Graham Kelly_1]

Thanks for replying.

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.

[Dennis Handly]

>A.03.37 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.

[Dennis Handly]

If you have troubles going from the end of the try to after the catch, it could be having problems destroying locals. You could do this to check:
try {
{
// original block ...
fprintf(stderr, "LIBSCM MSG.25 - finishing try block\n");
}
fprintf(stderr, "LIBSCM MSG.25a - finishing try block, locals destroyed\n");
} catch