topic Re: How to resolve SIGBUS from $$dyncall_external in Operating System - Linux

How to resolve SIGBUS from $$dyncall_external

Steve Fiorelli — Thu, 04 Jan 2007 18:45:13 GMT

Hi,

{note: description below is also attached as a text file which may be easier to read)

On HP-UX 10.20, I am building a shareable library that contains a number of C and C++ modules.

The C modules are compiled in the following manner:

/opt/ansic/bin/cc -c -g -Ae +ESlit +Z -Iunix -Dhpux -DSYSV +DAportable -D_HPUX_SOURCE -DPTHREADFUNC
-DAPINODEBUFFERING -Dhppa -Dhpux -DUNIX -Dunix +Z apicomm.c

The C++ modules are compiled in the following manner:

rm -f piunixinterlock.o
/opt/aCC/bin/aCC -c -g -AA -Aa -ext +Z -Iunix -Dhpux -DSYSV +DAportable -D_HPUX_SOURCE -DPTHREADFUNC
-D__PLACEMENT_NEW_INLINE -DAPINODEBUFFERING -Dhppa -Dhpux -DUNIX -Dunix +Z piunixinterlock.cxx

The shareable library is put together in the following manner:

rm -f libpiapi.sl~
(cd .; /opt/aCC/bin/aCC -o ./libpiapi.sl~ -b -Wl,+s,-c,piapiexports.hpux -Wl,+h,libpiapi.sl allnet.o apicomm.o doclient.o hreverse.o piarsub.o pielsub.o pilgsub.o piptsub.o pisnsub.o pitmsub.o piutsub.o prof.o ioshmem.o msgq.o bufglob.o
bufmgr.o bufparms.o osutil.o piapix.o pibacl.o pigrdcl.o piliccl.o pisqlcl.o pterror.o ptextattrs.o qbind.o shmembuf.o
ptcacheimpl.o ptcachemgr.o piarg.o piargent.o pibookmark.o pidig.o pidir.o pievent.o pifile.o pigrid.o pilicense.o
pimoduledbnames.o pinttmpl.o pintutil.o piosinfo.o pipelib.o pipoint.o pirep.o pisecobj.o pishlib.o pistatus.o
pistring.o pistringw.o pitable.o pitime.o pitmplar.o pitxtprmpt.o pitzinfo.o piuid.o piunixfilemap.o pivalue.o pivariant.o pixmlutil.o pibackedupfile.o pibackedupfiles.o pivsselements.o piquicklock.o pisemaphore.o piunixcritsect.o piunixinterlock.o pthread_substitute.o -Wl,+b,.)

When executing a program that uses the shareable library I get a SIGBUS error with Frame 0 being that of $$dyncall_external.

gdb output below:

(gdb) i r
flags: 29000001 r18: 40006edd pcsqt: 5d1d ccr: 0
r1: 7a913ef3 r19: 7a7d1574 eiem: fffffffe cr12: ffffffff
rp: 7a9a2623 r20: 54000000 iir: 4 cr13: ffffffff
r3: 7b03ae48 r21: 7a80f158 isr: 6d2a cr24: 0
r4: 7b03a8b8 r22: 0 ior: 0 cr25: 1
r5: 7b03a818 r23: ff ipsw: 4000f cr26: 1
r6: 1f08 r24: 7a91b086 goto: 2 mpsfu_hi: 0
r7: 7b03a910 r25: 40003c18 sr4: 6d2a mpsfu_lo: 0
r8: 40 r26: 7a80f158 sr0: 5d1d mpsfu_ov: 0
r9: 40001250 dp: 40001638 sr1: 7313 pad: 0
r10: 74 ret0: 7a80f158 sr2: 6066 fpsr: 0
r11: 72 ret1: 3 sr3: 0 fpe1: 0
r12: 56 sp: 7b03ae48 sr5: 5d1d fpe2: 0
r13: 54 r31: 7a9a2623 sr6: 7313 fpe3: 0
r14: 52 sar: 18 sr7: 0 fpe4: 0
r15: 43 pcoqh: 7a913ef0 cr0: 0 fpe5: 0
r16: 3f pcsqh: 5d1d cr8: 0 fpe6: 0
r17: 4 pcoqt: 7a913ef4 cr9: 0 fpe7: 0
(gdb) x/i $pc
0x7a913ef0 <$$dyncall_external>: ldw 2(%sr0,%r22),%r19
(gdb) stepi

Program received signal SIGBUS, Bus error.
0x7a913ef0 in () from /home/piadmin/piapi/v1617_sf_debug/test/buftest/../../lib/libpiapi.sl
(gdb) bt
#0 0x7a913ef0 in () from /home/piadmin/piapi/v1617_sf_debug/test/buftest/../../lib/libpiapi.sl
#1 0x7a9a2620 in apifilebuf::initfilename (this=0x40003bfc) at shmembuf.cxx:670
#2 0x7a9a3640 in apifilebuf::initexisting (this=0x40003bfc) at shmembuf.cxx:870
#3 0x7a9a360c in apifilebuf::initexisting (this=0x40003bfc, newfname=0x7b03acd8 "APIBUF_SFIORELLIGX620.DAT") at

shmembuf.cxx:859
#4 0x7a971458 in bufservermgr::open (this=0x40003b00) at bufmgr.cxx:382
#5 0x7a96a110 in openbufmgr (pbufmgr=0x40003b00) at bufglob.cxx:254
#6 0x7a94aa50 in pisetactiveservernode (server=0x7b03a8b8 "testServer") at apicomm.c:2415
#7 0x7a9645d8 in piut_setservernode (servername=0x7b03a8b8 "testServer") at piutsub.c:548
#8 0x4800 in bufconnect () at buftest.c:601
#9 0x412c in main () at buftest.c:529
(gdb)

A chatr of the test program is below (libapiapi.sl is the shareable library I created):

peach> chatr testapi
testapi:
shared executable
shared library dynamic path search:
SHLIB_PATH enabled second
embedded path enabled first ../../lib:.
internal name:
testapi
shared library list:
dynamic ../../lib/libpiapi.sl
dynamic /usr/lib/libstd_v2.1
dynamic /usr/lib/libCsup_v2.1
dynamic /usr/lib/pa1.1/libcl.1
dynamic /usr/lib/libc.1
static /usr/lib/libdld.1
shared library binding:
deferred
global hash table disabled
plabel caching disabled
global hash array size:1103
global hash array nbuckets:3
shared vtable support disabled
static branch prediction disabled
kernel assisted branch prediction enabled
lazy swap allocation disabled
text segment locking disabled
data segment locking disabled
third quadrant private data space disabled
fourth quadrant private data space disabled
data page size: 4K
instruction page size: 4K
peach>

A build and execution of the test program (testapi) and shareable library on HP-UX 11.11 is sucessful. From searching the

web, I see that $$dyncall_external has something to do with dynamic calls and SIGBUS occurs in unaligned memory access.

However, I'm at a loss as to how to resolve this. Any suggestions would be appreciated.

Thanks--Steve

Re: How to resolve SIGBUS from $$dyncall_external

Dennis Handly — Thu, 04 Jan 2007 21:43:14 GMT

This says that frame #1 initfilename is either calling a virtual function or doing an indirect call. The value of R22 is the plabel. In your case it is 0. Something that hasn't been initialized.

What are you doing on shmembuf.cxx:670?

You may want to link your executable with -z so you abort on NULL pointer dereferences. Or use chatr -z executable.

Re: How to resolve SIGBUS from $$dyncall_external

Steve Fiorelli — Wed, 10 Jan 2007 14:11:32 GMT

Thanks. I compiled with -z and continued my investigation.

The dereferencing of the null pointer occurred at the last line of the following code snippet:

int32 apifilebuf::initfilename()
{
int32 retVal;
char testname[80];

osutil * osutils = getosutil();

/* get the PIHOME location. If not found get temp directory */
retVal = osutils->getpibasedir(name,"",sizeof(name));

Where getosutil() is implemented as:

#ifdef WIN32
NTosutil osutils;
NTosutil * getosutil()
#else
UNIXosutil osutils;
UNIXosutil * getosutil()
#endif
{
return & osutils;
}

with UNIXosutil defined as:

class UNIXosutil : public osutil
{
public:
int32 getpibasedir(char * basedir, char *defaultvalue, const uint32 len);
char * maketempfile(char * mask);
const char * safegetenv(const char * name);
virtual void grantfileaccess(char *name);
};

and getpibasedir implement as:

int32 UNIXosutil::getpibasedir(char * basedir,char *defaultvalue, const uint32 len)
{
strncpy(basedir,defaultvalue, len-1);
basedir[len-1] = 0;

strncpy(basedir,safegetenv("PIHOME"),(unsigned)(len-1));
basedir[len-1] = '\0';
return APIBUFERR_SUCCESS;
}

The assembler generated for the beginning of apifilebuf::initfilename:

.SPACE $TEXT$
.SUBSPA $CODE$,QUAD=0,ALIGN=4,ACCESS=0x2c,CODE_ONLY,SORT=24
; line 0
initfilename__10apifilebufFv
.PROC
.CALLINFO CALLER,FRAME=16,ENTRY_GR=%r4,SAVE_RP,ARGS_SAVED
.ENTRY
STW %r2,-20(%r30) ;offset 0xb9d4
STW,MA %r3,64(%r30) ;offset 0xb9d8
STW %r4,-60(%r30) ;offset 0xb9dc
STW %r19,-32(%r30) ;offset 0xb9e0
B,L .+8,%r3 ;offset 0xb9e4
$PIC$90
DEPWI 0,31,2,%r3 ;offset 0xb9e8
STW %r26,-100(%r30) ;offset 0xb9ec
; line 668
.CALL RTNVAL=GR ;out=28;
B,L getosutil__Fv,%r2 ;offset 0xb9f0
NOP ;offset 0xb9f4
LDW -32(%r30),%r19 ;offset 0xb9f8
STW %r28,-56(%r30) ;offset 0xb9fc
; line 671
LDW -56(%r30),%r21 ;offset 0xba00
LDW 0(%r21),%r22 ;offset 0xba04
LDW 16(%r22),%r22 ;offset 0xba08
COPY %r21,%r26 ;offset 0xba0c
LDW -100(%r30),%r1 ;offset 0xba10
LDO 28(%r1),%r25 ;offset 0xba14
ADDIL LR'C$2-$PIC$90-4,%r3,%r1 ;offset 0xba18
LDO RR'C$2-$PIC$90+26(%r1),%r24 ;offset 0xba1c
LDI 255,%r23 ;offset 0xba20
.CALL ARGW0=GR,ARGW1=GR,ARGW2=GR,ARGW3=GR,RTNVAL=GR ;in=22,23,24,25,26;out=28;
B,L $$dyncall,%r31 ;offset 0xba24
COPY %r31,%r2 ;offset 0xba28
LDW -32(%r30),%r19 ;offset 0xba2c
STW %r28,-52(%r30) ;offset 0xba30
; line 672

The instruction that produces a segmentation fault because of a null pointer is:

LDW 16(%r22),%r22 ;offset 0xba08

At the instruction before, %r21 contains osutils and the first word is zero which gets placed into %r22 and causes the null pointer dereference.

(gdb) p osutils
$2 = (class osutil *) 0x7a80f158
(gdb) x/x 0x7a80f158
0x7a80f158: 0x00000000
(gdb)
0x7a80f15c: 0x40003d90

I've been trying to find out what the first word of the object structure represents in the hope it will lead me to the problem. However, I haven't had any luck in searching the HP-UX documentation. Would you know? Or if you believe I am going down the wrong path any further suggestions would be appreciated.

Thanks--Steve

Re: How to resolve SIGBUS from $$dyncall_external

Dennis Handly — Sat, 22 Oct 2011 19:34:42 GMT

>The dereferencing of the null pointer occurred at the last line of the following code snippet:
retVal = osutils->getpibasedir(name,"",sizeof(name));

Ok, so -z did help you get closer to the problem. If osutils comes from the global:
return &osutils;
Then there is no way the the local pointer osutils can be NULL.

>The instruction that produces a segmentation fault because of a null pointer is: LDW 16(%r22),%r22
>At the instruction before, %r21 contains osutils and the first word is zero which gets placed into %r22 and causes the null pointer dereference.
>I've been trying to find out what the first word of the object structure represents in the hope it will lead me to the problem. However, I haven't had any luck in searching the HP-UX documentation. Would you know?

Naturally, that's my job to know. :-)
(If this was IPF, you can look up the ABI on the web.) This indicates the vtable pointer is NULL.

This probably occurs because you are assuming that the global osutils has been constructed before it is used in apifilebuf::initfilename.

What are the two source files?

The standard trick to make sure globals are constructed when you need them is to wrap them in a function. And you are already doing that!

You need to move the global to a function scope static:
UNIXosutil* getosutil() {
static UNIXosutil osutils;
return &osutils;
}

(The standard trick is to return a reference. Then you can use macros to change the other global references to a function call.)