Recieving BUS Error in execution

[Asish]

Hi Everyone,
First, let me give some details about this product. This product (written in C++) uses TCL/TK libraries (version 8.3.3) and extends it by adding new commands to it. It runs on a NCLASS machine (OS --> HP-UX 11.00). Recently we had added some code to improve its functionality but after this code was added it recieves a SIGBUS signal when it executes a particular tcl script (containing nothing but TCl commmands and user added commands). Below is the backtrace obtained in gdb for the concerned core file.

#0 GarudaTclWorld::executeGarudaTickLoop (this=0x401f5170)
at src/Garuda/GarudaTclWorld.C:357
357 while (!getclock(TIMEOFDAY,&abstime))
#0 GarudaTclWorld::executeGarudaTickLoop (this=0x401f5170)
at src/Garuda/GarudaTclWorld.C:357
357 while (!getclock(TIMEOFDAY,&abstime))
(gdb)
(gdb) bt
#0 GarudaTclWorld::executeGarudaTickLoop (this=0x401f5170)
at src/Garuda/GarudaTclWorld.C:357
#1 0xd86b0 in GarudaAttrInfo::operator= ()
#2 0x152bc8 in GarudaTclContext::getAttributeInfo (this=0x4114d758,
mode=@0x400c1188, errorData=@0x25c,
attrName=0x1

, attrInfo=@0x401f5088, context=0,
lockReqd=0x0)
at libsrc/Garudautil/GarudaBS/TclContext.C:1469
#3 0x25da84 in Tcl_DbCkfree (ptr=0x4063c0e8 "",
file=0x400c3a90 "libsrc/Garudautil/tcl/generic/tclLiteral.c", line=486)
at libsrc/Garudautil/tcl/generic/tclCkalloc.c:525
#4 0x2c4500 in TclAddLiteralObj (envPtr=0x7b02ef5c, objPtr=0x0, litPtrPtr=0x0)
at libsrc/Garudautil/tcl/generic/tclLiteral.c:486
#5 0xc014c254 in _p_mutex_unlock () from /usr/lib/libc.1
#6 0xc00a0350 in malloc () from /usr/lib/libc.1
#7 0xc00a0aa8 in free () from /usr/lib/libc.1
#8 0x4096d090 in ?? ()
#9 0x8528c in GarudaTclWorld::executeGarudaTickLoop (this=0x0)
at src/Garuda/GarudaTclWorld.C:366



But this did not help as the functions listed in backtrace are kind of generic and have never been touched for a very long time. I have checked all the code added but everything seems to be allright.


The most absurd part is that i don't get a BUS error if i remove a piece of code which is never getting executed throughout the execution of the program. I am suspecting that something is wrong with the HP-UX aCC compiler that i am using but i can't shift to another compiler.

I have tried compiling the code by giving options like +unum.

I have also tried including call to the function allow_unaligned_access() in my code then linked it with -lhppa option but all this was of no use.

I have also read most of the posting on BUS error in this forum and i tried it in my case but none of them helped.


Please help me.

[Steven E. Protter]

If the code is never executed whats it doing in the program?

This may be a problem with the compiler. Perhaps you should check for patches and isntall them.

Perhaps also run your code through a debugger and see if any errors or warnings or bad pointers pop up.

SEP

[Asish]

Hi Steven,
First of all thanks for responding.

The piece of code that i mentioned earlier gets executed in a particular scenario. During the execution of this particular tcl script this code does not get executed. I was able to verify this by putting a breakpoint in gdb at the starting of the concerned code.

Actually, the code is something of the form
if (condition)
{
....
....
....
}
else
{
if (condition)
{
....
....
....
}
else
{
if (condition)
{
....
....
....
}
it goes on like this.

Can there be an upper limit on the number of if - else if constructs that i can have?

Even executing the whole program under gdb did not help. Under gdb I was able to figure out where exactly i get a SIGBUS signal but the piece of code has never been touched for years and moreover the code looks perfectly allright.

I also tried placing debug messages throughout the program but each time my program cores at a different place. Is it because of some delay in propagating the SIGBUS signal?

Asish

[A. Clay Stephenson]

attrName=0x1

,

This is the error that jumps out at me because if this argument is a pointer that's a bogus address. Without knowing the protoype for this function, I can't say more.

The levels of if's should not be a problem. In all cases that I have ever seen, the level of nested if's is limited by the compiler and not by the run-time stack.

Yours is the kind of problem that is very difficult to find because I suspect the memory is that is being overwritten is nowhere near the code you think is executing. The actual damage may have been done at some point much earlier in the execution.

[Asish]

Hi,
I know that in the backtrace "attrName=0x1

". So i had placed a breakpoint at the place where this function is being called to check whether attrName is being correctly passed to the function.
The last call to this fuction passes *attrName="Name". Is gdb playing games with me??

The output of gdb --version is :

$ /usr/local/bin/gdb --version

Hewlett-Packard Wildebeest 1.0 (based on GDB 4.16)
(built for PA-RISC 1.1 or 2.0 (narrow), HP-UX 10.20)
Copyright 1996, 1997 Free Software Foundation, Inc.



The function prototype is

void GarudaTclContext::getAttributeInfo(int &mode, aecErrorData &errorData, const char *attrName, auiAttrInfo &attrInfo, int context, int *lockReqd);



Asish