Re: Migrate code from 10.20 to 11i: Bus error core dump (533 Views)
Reply
Occasional Advisor
Richard Sun
Posts: 9
Registered: ‎04-23-2003
Message 1 of 9 (533 Views)

Migrate code from 10.20 to 11i: Bus error core dump

I need help in resolving the core dump (bus error) problem in our application problem.

We have an application which is using hp-ux 10.20 as the os to control a automation machine tool. The GUI is one process developed in Motif library while the control code is another process developed in c++. In 10.20 the HP cfont C++ compiler is used and there is no problem. After we are using hp-ux 11i os (the HP B2600 workstation (PA-RISC) is used), we modify our source code a little and use aCC to compile the code. We get the following warning message:
"At least one PA 2.0 object file (xxxx.o) was detected. The linked output may not run on a PA 1.0 system".

When we run our program, there is frequent core dump (BUS ERROR, 1 to 3 times in 12 hour shift). Sometimes, the GUI will disappear so that we cannot control our machine and have to kill the control process.

If we use option DA2.0W to compile the code, there is following error message:
"Mismatch ABI, 64-bit PA object file found in 32-bit link".

Here is the make file:

1. GUI

LIBS = -lil -lXm -lXt -lX11 -lSM -lICE -lmalloc -l++
OTHER = -L/usr/lib/Motif2.1 -L/usr/lib/X11R6

gui : cxxx.o display.o comm.o menu.o\
aCC cxxx.o display.o comm.o menu.o\
$(OTHER) $(LIBS) -o gui

CC = aCC -c +ESnolit +inst_implicit_include +W829 +p -I/usr/include/Motif2.1 -I/usr/include/X11R6/X11

cxxx.o : ....

"

2. Control
"
INCLUDES=./msgque

CFLAGS= -I $(INCLUDES) -g

CC = aCC $(CFLAGS) -c +p +W829 $<

OBJ=control.o run_xxx.o xxx_funct.o dio.o comm.o

proc : $(OBJ) $(LIB)
aCC $(OBJ) $(LIB) -lSM -lm -o proc
"

Thank you in advance for any help.
Trusted Contributor
Manish Srivastava
Posts: 170
Registered: ‎05-24-2004
Message 2 of 9 (533 Views)

Re: Migrate code from 10.20 to 11i: Bus error core dump

Hi,

can you compile it with -g and use gdb to do a bt to find out where is it dumping core.
the warning you see is not a problem.

manish
Occasional Advisor
Richard Sun
Posts: 9
Registered: ‎04-23-2003
Message 3 of 9 (533 Views)

Re: Migrate code from 10.20 to 11i: Bus error core dump

How to debug the program with multiple process?

Our GUI is a process (make file 1), which will create control process (make file 2). They will communicate with each other via pipe. In such case, WDB or GDB can debug for both process?

Thanks!
Acclaimed Contributor
A. Clay Stephenson
Posts: 17,825
Registered: ‎07-16-1998
Message 4 of 9 (533 Views)

Re: Migrate code from 10.20 to 11i: Bus error core dump

It doesn't matter if there are multiple processes. Simply let the process die and dump core and then use gdb to examine the core file and do a stack trace. That should zero in on the problem. Your linking problems
are expected. All the modules must be either 32-bit code or 64-bit code; mixing and matching is not allowed. Use the -g option to add debug infomation to the executable and turn off all optimization. Gdb should then be able to identify the exact line in your source code (unless the failure is in a library for which you do not have the source). In any event, you should be able to see the offending function and its arguments.
If it ain't broke, I can fix that.
Frequent Advisor
Craig Smith_13
Posts: 56
Registered: ‎01-29-2001
Message 5 of 9 (533 Views)

Re: Migrate code from 10.20 to 11i: Bus error core dump

On the C compiler, there is an option to force the executable to a particular system / processor, basically the lowest common denominator...

CFLAGS = +DS110 (i.e. C110 system), there may be something similar in the aCC compiler....
Honored Contributor
Kent Ostby
Posts: 1,836
Registered: ‎09-26-2000
Message 6 of 9 (533 Views)

Re: Migrate code from 10.20 to 11i: Bus error core dump

Richard --

Are you recompiling the various .o files listed ?

If not then one of those may be the object module in question.

Best regards,

Kent M. ostby
"Well, actually, she is a rocket scientist" -- Steve Martin in "Roxanne"
Occasional Advisor
Richard Sun
Posts: 9
Registered: ‎04-23-2003
Message 7 of 9 (533 Views)

Re: Migrate code from 10.20 to 11i: Bus error core dump

Hello, Thank you all for your advice.

We compiled the object ourselves, no other 3rd party library except the X11. Use gdb to debug the software found the core dump problem happen when call XtManageChild a widget delared in following class.
Class myClass{
Public: Widget a, b, c, d, e, f, g, h;
Widget i, j, King, Last;
Display * myDisplay;
Window window;
GC gc;
...
}
When run program, after press buttons to envoke the myClass window pop up for certain times, there is BUSERROR core dumpe, found Widget Last has the same address as myDisplay. The system will core dump when call XtManageChild(Last).

If swap King and Last delcaration sequence in myclass.h,
Class myClass{
Public: Widget a, b, c, d, e, f, g, h;
Widget i, j, Last, King;
Display * myDisplay;
Window window;
GC gc;
...
}
the Widget k will has the same address as myDisplay. The system will core dump when call XtManageChild(k).

Same code is running in hp-ux 10.20 for long period no such problem. Please give any advice. Thanks in advance.

Honored Contributor
Mike Stroyan
Posts: 888
Registered: ‎11-22-1996
Message 8 of 9 (533 Views)

Re: Migrate code from 10.20 to 11i: Bus error core dump

How are you finding the addresses of the different fields? Could you use

printf("%p %p\n", &instance.Last, &instance.myDisplay);

to confirm that two different fields have the same address?

Could you then reduce that to a small test case that you could share with us?
Occasional Advisor
Richard Sun
Posts: 9
Registered: ‎04-23-2003
Message 9 of 9 (533 Views)

Re: Migrate code from 10.20 to 11i: Bus error core dump

Thank you Mike. I found the same address when I use wdg to debug the program. In local variable, I found the Widget Last and Display has the same value. Explore the Last widget further, found the self value is 0xffff0000 (address error). If I swap King and Last widget in class declaration, the same problem goes to Widget King, Last is ok. It seems the ememory boundary problem.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.