Program execution hangs before entering function on HP-UX 11.0

[Mark Anderson_6]

We're in the process of porting an application from 10.20 to 11.0. We were using aCC 1.27 on 10.20. We are now using aCC 3.52 with all the up to date linker, support library, etc. patches. Our main application is a mix of C++, C, and FORTRAN (versions below). We're having a problem where our application just hangs when making certain function calls.

For instance, we have a function like so, prototyped in "Interpolation.h" and implemented in "Interpolation.cpp":

void GetInterpolationValueAt(void* iData,
const double x,
double* y,
double* dydx)
109 {
110 DynInterpFloat* interp = static_cast(iData);
111 interp->getValueAt(x, *y, *dydx);
112 }

When this function is called, the program just hangs. If we look in gdb, the stack frame seems to be pointing to the opening "{"; that is, it does not appear to actually be in the function.

A partial backtrace looks like this:
#0 0x670a3868 in GetInterpolationValueAt+0 () at Interpolation.cpp:109 <-- C++
#1 0x12fe58 in intrpv () <-- C
#2 0x26b4d8 in cdgte () <-- FORTRAN

Another example problem function, implemented in a "Utility.h" type file:

inline bool checkEqual(const double val1,
const double val2,
const int prec = 14)
{
return val1 == val2 || relPrecision(val1 - val2, val1, val2) <= -prec;
}

When called, the process will again appear to hang at the opening "{". If you look at the trace in gdb at this point, the stack will appear corrupted ("#0 checkEqual... #1 doThat... #2 ??") If we move this function out of the header and into a .cpp, it works fine. Unfortunately, in the first example, the function is already in the .cpp, so this won't work there...

Any ideas? This all worked fine on 10.20, and the code also runs fine when compiled on Visual C++ 6.0. We've pretty much run out of ideas!

Thanks in advance,
Mark

> what /usr/bin/cc
/usr/bin/cc:
LINT B.11.11.04 CXREF B.11.11.04
HP92453-01 B.11.11.26792.GP HP C Compiler
$ Sep 8 2000 23:13:51 $

> what /opt/aCC/bin/aCC
/opt/aCC/bin/aCC:
$Revision: 92453-07 linker linker crt0.o B.11.16.01 030316 $
HP aC++ B3910B A.03.52
HP aC++ B3910B A.03.52
HP aC++ B3910B X.03.37.01 Language Support Library

> what /opt/fortran/bin/f77
/opt/fortran/bin/f77:
HP-UX f77 971027 (162928) B3907CA/B3909CA B.11.00.01
CUPROS_IC23B //1
/ux/core/libs/libc/archive_pa1/libc.a_ID
Oct 21 1997 13:07:38

[Dave Olker]

Hi Mark,

You could try executing the program from tusc and then check the tusc output to see which system calls the program is making when it stops responding. Viewing it from the system call layer may provide some insight into why the application is stopped.

Regards,

Dave

[A. Clay Stephenson]

Nothing is glaringly obvious. What language is main() written in? When you are mixling languages, you have to play by a very tight set of rules. Read the aCC documentation where it describes Mixed-Language programs. I have a funny feeling that some initializations are not being called and thus come critical constructors are not invoked.

[Mark Anderson_6]

Wow, thanks for the quick responses!

I grabbed tusc; here's what I get at the end:

select(11, 0x680f2a80, NULL, NULL, NULL) ................. = 1
read(10, "01\013bd\0\0\0\0ffffffffffff\0\0".., 32) ....... = 32
lseek(12, 0, SEEK_CUR) ................................... = 32715
lseek(12, 0, SEEK_CUR) ................................... = 32715
read(12, "c l t _ 3 9 6 3 1 \n0 - 1 ".., 8192) ..... = 8192
brk(0x36ce000) ........................................... = 0
brk(0x36cf000) ........................................... = 0
brk(0x36d0000) ........................................... = 0
brk(0x36d2000) ........................................... = 0
brk(0x36d3000) ........................................... = 0
brk(0x36d4000) ........................................... = 0
brk(0x36d5000) ........................................... = 0
brk(0x36d6000) ........................................... = 0

I get this last line about 400 times, then it just hangs at

brk(0x3a2e000) ........................................... = 0


To the second suggestion: main is a C++ file. We link the application using aCC. I should have also noted that the checkEqual function *does* work from a smaller test application that doesn't use FORTRAN. I haven't tried adding FORTRAN into the mix for that application, but if you think it's worth trying, I'll pursue that.

[Mark Anderson_6]

My aplogies, I may have jumped the gun a bit on the tusc output. It actually ends with this:

brk(0x3a2e000) ........................................... = 0
brk(0x3a30000) ........................................... = 0
brk(0x3a31000) ........................................... = 0
lseek(12, 0, SEEK_CUR) ................................... = 40907
lseek(12, 0, SEEK_CUR) ................................... = 40907
read(12, "1 4 6 9 0 1 4 2 5 \n3 \n2 1 ".., 8192) ..... = 8192
read(12, "N C E L I N E S \n* * * * * * ".., 8192) ..... = 8192
read(12, "E R T I C A L R E F E R E N C ".., 8192) ..... = 1557
lseek(12, 0, SEEK_CUR) ................................... = 58848
lseek(12, 0, SEEK_CUR) ................................... = 58848
lseek(12, 0, SEEK_CUR) ................................... = 58848
lseek(12, 0, SEEK_CUR) ................................... = 58848
lseek(12, 0, SEEK_CUR) ................................... = 58848
lseek(12, 0, SEEK_CUR) ................................... = 58848
lseek(12, 33751, SEEK_SET) ............................... = 33751
In user-mode ............................................. [running]


Not sure what this tells me?

[ranganath ramachandra · Accepted solution]

what linker ? please make sure you have the latest: PHSS_30965/PHSS_30966 and NOT PHSS_30048/PHSS_30049. while it may not be the same problem, the linker version 11.38 has a bug that may result in application hangs when calling functions.

if that does not solve your problem, can you step through the assembly and post what you find - what is this looping in ?

[Mark Anderson_6]

Thanks, the patch did the trick! We were previously at the PHSS_30048 level. I'm a bit curious as to why the new patch (PHSS_30965) is not the "recommended" patch and the old one still is, though...

Thanks again.

[ranganath ramachandra]

oh! can you give me a pointer to where the old one is "recommended" ? i will get it corrected. thanks.

[Mark Anderson_6]

If you look up patch PHSS_in the Patch Database (http://www6.itrc.hp.com/service/patch/mainPage.do), you'll see what it lists as "Most recent" and "Recommended":

http://www6.itrc.hp.com/service/patch/patchDetail.do?BC=patch.breadcrumb.main|patch.breadcrumb.search|&patchid=PHSS_30048&context=hpux:800:11:00

It seems that recommended patches have to have a star rating of 2 or more. I would guess that this patch hasn't reached that level yet because it's so new... In which case, perhaps a more obvious defect in the patch's "Defect Description" would have led me to the patch myself :) Which defect exactly is this, "JAGaf19767"? Is there a way for end users to look up those JAG changes?

[ranganath ramachandra]

thanks for the pointer. yes, it is JAGaf19767. about accessing the defect information, i guess your hp support folks should be able to help you. i will let you know for sure in a day.