HP IA64- runtime error "si_code: 1 - SEGV_MAPERR - Address not mapped to object" on memcpy

[maitri]

We are migrating from SGI to HP, and as a part of this migration we have moved from oracle 7 to oracle 10.
Environment :
Platform : HP-UX 11.23, Itanium Platform.
Compiler (aCC) version : CC: HP aC++/ANSI C B3910B A.06.10 [Mar 22 2006] Ulimit settings on the machine :
Ulimit settings :
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 1992292
stack(kbytes) 131072
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 8192

We are having a problem fetching LONG data greater than 16.7 Meg from the database. It errors out with ORA-1062 .
works: a select of (17-50 meg) of LONG data on SGI platform using oracle 7.33 pro-C precompiled C code talking to a remote 10i database
doesn't work: a select of (over 16.7 Meg) of LONG data on HP Itanium-2 platform 10i pro-C precompiled C code talking to a remote 10i database

One of the solutions we are looking into is to use 64 bit version of oracle 10.2.0.3 library instead of 32 bit version. The reason we are going for this is, when linking to 64 bit oracle library we do not encounter ORA-1062 error.
To validate that 64 bit version actually works we need to write the data fetched to disk, but not getting any further there because the application core dumps with SIGV_MAPERR


We have a sql embedded c code that works fine when built as 32 bit application but 64 bit version of the same errors out on memcpy.

Global declaration:
typedef struct blob
{
long len;
char *startBLOBdata;
} *bBLOB;

EXEC SQL BEGIN DECLARE SECTION;
EXEC SQL TYPE bBLOB is LONG VARCHAR (16777167) REFERENCE;
EXEC SQL END DECLARE SECTION;

Inside the static getGraphicData method:

EXEC SQL BEGIN DECLARE SECTION;
bogartBLOB theBLOB; /* the typedef is defined globally */
EXEC SQL END DECLARE SECTION; /* the BLOB is a SQL host variable */


if ((theBLOB = (bogartBLOB) malloc(malloc_bytes + sizeof(long))) == NULL) /* allocate memory */
{
return -1;
}

if ((dbdata->db_data_ptr = (char *) malloc(malloc_bytes)) == NULL) /* allocate memory */
{
return -1;
}

/* fetch data into the memory*/
EXEC SQL
SELECT GRAPHIC_DATA
INTO :theBLOB
FROM GRAPHIC
WHERE STUDIO_NO = :GRAPHICS_STUDIO_NO

memcpy(dbdata->db_data_ptr,&(theBLOB->startBLOBdata), theBLOB->len);/******************************** bombs here**************************************/

Terminates with :
Program received signal SIGSEGV, Segmentation fault
si_code: 1 - SEGV_MAPERR - Address not mapped to object.
(gdb) where
#0 0x8003ffffbf5a6630:0 in memmove+0xaf0 () from /usr/lib/hpux64/libc.so.1
#1 0x4000000000196a30:0 in getGraphicData (dbdata=0x600000000005f360) at /vobs/bogey7/src/BDB/cora.pc:6532
#2 0x4000000000072cc0:0 in doGet (dbdata=0x600000000005f360) at /vobs/bogey7/src/BDB/cora.pc:718
#3 0x400000000006f410:0 in cora2 (dbdata=0x600000000005f360, fp=0) at /vobs/bogey7/src/BDB/cora.pc:318
#4 0x400000000006eab0:0 in cora (dbdata=0x600000000005f360) at /vobs/bogey7/src/BDB/cora.pc:207
#5 0x400000000025a3c0:0 in read_graphic () at /vobs/bogey7/src/dbdownload/dbget.c:458
#6 0x400000000006c760:0 in dbget () at /vobs/bogey7/src/dbdownload/dbget.c:201
#7 0x400000000006c310:0 in main () at /vobs/bogey7/src/dbdownload/dbget_main.c:

When I print theBLOB->startBLOBdata, this is what I get(both 32 bit app and 64 bit app give the same error message)
theBLOB->startBLOBdata= 0x2000084a00e053a

Command to build as 32 bit application :

cc -O2 -DVOS_B1123 -DVAT_HPUXia64 -DCCVER_aCCA0610 -I /vobs/bogey7/build/include -I /usr/include -c dbget.c
aCC -O2 -DVOS_B1123 -DVAT_HPUXia64 -DCCVER_aCCA0610 -I /vobs/bogey7/build/include -I /usr/include -c dbget_main.c
cc -O2 -DVOS_B1123 -DVAT_HPUXia64 -DCCVER_aCCA0610 -I /vobs/bogey7/build/include -I /usr/include -c dbaccess.c
aCC -O2 -DVOS_B1123 -DVAT_HPUXia64 -DCCVER_aCCA0610 -o dbget dbget.o dbget_main.o dbaccess.o -lc /vobs/bogey7/build/lib/libcdev.a -lc /vobs/bogey7/build/lib/BOG_sqllib.a -lc -lc -L /opt/oracle/product/10.2.0.3/lib -lclntsh -lc /vobs/bogey7/build/lib/libcdev.a -lc /vobs/bogey7/build/lib/libbhl.a -lc /vobs/bogey7/build/lib/libbdl.a -lc -lc /vobs/bogey7/build/lib/libutil.a

Command to build as 64 bit application :

cc +DD64 -O2 -DVOS_B1123 -DVAT_HPUXia64 -DCCVER_aCCA0610 -I /vobs/bogey7/build/include -I /usr/include -c dbget.c
aCC +DD64 -O2 -DVOS_B1123 -DVAT_HPUXia64 -DCCVER_aCCA0610 -I /vobs/bogey7/build/include -I /usr/include -c dbget_main.c
cc +DD64 -O2 -DVOS_B1123 -DVAT_HPUXia64 -DCCVER_aCCA0610 -I /vobs/bogey7/build/include -I /usr/include -c dbaccess.c

aCC +DD64 -O2 -DVOS_B1123 -DVAT_HPUXia64 -DCCVER_aCCA0610 -o dbget dbget.o dbget_main.o dbaccess.o -lc /vobs/bogey7/build/lib/libcdev.a -lc /vobs/bogey7/build/lib/BOG_sqllib.a -lc -lc -L /opt/oracle/product/10.2.0.3/lib -lclntsh -lc /vobs/bogey7/build/lib/libcdev.a -lc /vobs/bogey7/build/lib/libbhl.a -lc /vobs/bogey7/build/lib/libbdl.a -lc -lc /vobs/bogey7/build/lib/libutil.a

The libraries dbget application links to were built with +DD64 flag. This is the only compiler option change between 32 and 64 version of the libs.


How can I resolve SEGV_MAPERR?Am I missing any compiler/linker option?Do any kernel parameters require tuning?
Any pointers to get the oracle 10, 32 bit libraries to work for us?


-Maitri

[Don Morris_1]

Whenever I see the return value of malloc() being cast and hear "it works 32-bit but doesn't in 64-bit!" there's only one thing I can think.

You need to do:

#include

somewhere to get the declaration of malloc(). Since I have to assume from what you've said you haven't done this, the compiler is using the default interpretation of undeclared functions in your code... and hence malloc is assumed by the compiler to be returning an int type instead of the proper void * type. The return of malloc is used as an int and *then* cast to your pointer... which for 64-bit programs loses the upper 32-bits. When you have a malloc() which gets a virtual address above 4Gb in this scenario, the value is misinterpreted as some <4Gb virtual address... which may or may not be mapped. And in your case it wasn't, so boom.

Note the address clearly has a very low offset:

0x600000000005f360

(the 0x6 is added by the system to specify your octant... so the real pointer was just 0x5f360).

Check to make sure is properly included, and lose the cast. void * is guaranteed by the standard to be convertible to any valid pointer type... hence the return value of malloc never needs a cast. Doing so hides the warning the compiler would have given you about an int type being implicitly cast on assignment to a pointer type.

[Dennis Handly]

>Compiler version: A.06.10

You might want to patch to A.06.14: PHSS_35974 & PHSS_35975
But you really need to get to A.06.15 where Don's assumed diagnosis is now an error.

>Command to build as 64 bit application:

You can't just use +DD64. You must port your application. Also, you can use +w64bit to flag bad constructs.

>aCC +DD64 -O2 ... -lc ... -lc

You need to remove ALL of these -lc. On A.06.20 you'll get a warning for each. You also shouldn't have the default -I/usr/include, we may warn on that for the the next release,

>This is the only compiler option change between 32 and 64 version of the libs.

How about source changes?

>Don: Whenever I see the return value of malloc() being cast and hear "it works 32-bit but doesn't in 64-bit!" there's only one thing I can think.

(You forgot to mention that it is C.)
Also, this can no longer happen in A.06.15, it is now an error.

>lose the cast. void* is guaranteed by the standard to be convertible to any valid pointer type... hence the return value of malloc never needs a cast.

In C++ the cast is required because of C++'s strong type safety. But so is the header.

>Doing so hides the warning the compiler would have given you about an int type being implicitly cast on assignment to a pointer type.

+w64bit will still warn.

>Note the address clearly has a very low offset: 0x600000000005f360

I'm not sure what your point is here?? This is a perfectly valid pointer, unrelated to the abort or that malloc call.