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

[Richard Sun]

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.

[Manish Srivastava]

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

[Richard Sun]

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!

[A. Clay Stephenson]

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.

[Craig Smith_13]

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....

[Kent Ostby]

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

[Richard Sun]

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.

[Mike Stroyan]

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?

[Richard Sun]

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.