Operating System - HP-UX
1752865 Members
3993 Online
108791 Solutions
New Discussion юеВ

Core dump with BUS_ADRALN error

 
SOLVED
Go to solution
K!rn Kumr
Frequent Advisor

Core dump with BUS_ADRALN error

Hi, I am working on HP-UX B.11.23 U ia64 platform. I have trying to port 32 bit code to 64 bit. I have compiled it run. It dumps a core when the control branches from my file to another file which is a third party libraries via function call it fails. And during debugging i see that the value of a variable rqst is not available. I am not able to get a concrete picture of the reason for crash. As the application is crashing when a function in third party library is called, is it possible to say that there is a problem with that code and mine is clean.


HP gdb 5.7 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.7 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
Core was generated by `4telback'.
Program terminated with signal 10, Bus error.
BUS_ADRALN - Invalid address alignment. Please refer to the following link that helps in handling unaligned data: http://docs.hp.com/en/7730/newhelp0610/pragmas.htm#pragma-pack-ex3

warning: Load module /hubd/environ/hubdaec1/HLLIB/lib/libhublog.sl has been stripped.
Debugging information is not available.

#0 get_tcp_service (service=0x400000000000b990 "TSC720",
ip_addr=0x9fffffffffffe158, port=0x9fffffffffffe150) at min_tcp_serv.c:146
146 min_tcp_serv.c: No such file or directory.
in min_tcp_serv.c
(gdb) bt
#0 get_tcp_service (service=0x400000000000b990 "TSC720",
ip_addr=0x9fffffffffffe158, port=0x9fffffffffffe150) at min_tcp_serv.c:146
#1 0x400000000001f6f0:0 in connect_ipc (service=0x400000000000b990 "TSC720",
qos=0x0, timeout=60, connection_id=0x9fffffffffffe7d8) at conn_ipc.c:335
#2 0x40000000000261f0:0 in ti_start_line_test (line=0x9fffffffffffe860,
timeout=50, session=0x9fffffffffffe7d8) at ti_asynch.c:153
#3 0x40000000000251c0:0 in ti_line_test (line=0x9fffffffffffe860,
progress_update=0x9fffffffef6a6460, check_for_cancel=0, timeout=50,
result=0x9fffffffffffe900) at ti_synch.c:241
#4 0x4000000000023970:0 in line_test (rqst=)
at /hubd/home/id817019/4TEL/src/svc.c:377
#5 0xc0000000045c8d30:0 in _tmsvcdsp () at tmsvcdsp.c:475
#6 0xc00000000461b8e0:0 in _tmrunserver () at tmrunsvr.c:1882
#7 0xc0000000045c7300:0 in _tmstartserver () at tmstrtsrvr.c:141
warning:
ERROR: Use the "objectdir" command to specify the search
path for objectfile BS-47bc.o.
If NOT specified will behave as a non -g compiled binary.

#8 0x400000000000c8c0:0 in main+0x60 ()
53 REPLIES 53
Dennis Handly
Acclaimed Contributor

Re: Core dump with BUS_ADRALN error

>I have trying to port 32 bit code to 64 bit.

Have you read all of the documentation about porting and alignment issues? Have you compiled with +w64bit +wlint?

>And during debugging I see that the value of a variable rqst is not available.

Have you compiled with -g and NO optimization options? Why is rqst important? Where is the last frame of your code?

>I am not able to get a concrete picture of the reason for crash. As the application is crashing when a function in third party library is called, is it possible to say that there is a problem with that code and mine is clean.

Of course not. An alignment trap is a user problem. Typically when porting from 32 to 64 bit, if you pass an address of an int to a function that wants a long*, you will get this trap 50% of the time.
It could also be due to using pragma pack on structs.
K!rn Kumr
Frequent Advisor

Re: Core dump with BUS_ADRALN error

No I have not compiled my code using +W64bit +WIint, but I have used +DD64 flag.

Yes I have compiled it with -g (debug)flag but with more flags like +p +O2 +Ofltacc=relaxed +Onolimit +DSmontecito +FPD -Wl,+pi,1M -Wl,+pd,1M -Wl,+mergeseg -Wl,+s +w1.

I have checked the datatypes of the aruguments with the datatypes of the arguments that the funuction is expected

This is frame0

#0 get_tcp_service (service=0x400000000000b990 "TSC720",
ip_addr=0x9fffffffffffe158, port=0x9fffffffffffe150) at min_tcp_serv.c:146
146 min_tcp_serv.c: No such file or directory.
in min_tcp_serv.c

And this is the last frame.

#8 0x400000000000c8c0:0 in main+0x60 ()

rqst is an argument for a funtions in my code for which i am not able to find the value while debugging. Later in the code it is being accessed. But it is not crashing the place where it is being accessed.

There is no pragma pack used in the code too....

Below is the frame that belongs to my code

#4 0x4000000000023970:0 in line_test (rqst=)
at /hubd/home/id817019/4TEL/src/svc.c:377

But the line no 377 is just a debug statement which is getting printed in the log.

After this line I have a function call of 3rd party library.
Laurent Menase
Honored Contributor

Re: Core dump with BUS_ADRALN error

min_tcp_serv.c:146 look line 146 of min_tcp_serv.c

what is the line you can see?
how buffers on that line are allocated?
what are the types of those buffers in that line.
if you examine the values of those params, what do you find?

K!rn Kumr
Frequent Advisor

Re: Core dump with BUS_ADRALN error

Except this frame

#4 0x4000000000023970:0 in line_test (rqst=)
at /hubd/home/id817019/4TEL/src/svc.c:377

rest all belong to 3rd party libraries on which I dont have any control....
Laurent Menase
Honored Contributor

Re: Core dump with BUS_ADRALN error

so you need to contact your lib vendor for help on this debug or debug at assembly level to identify where the buffer comes from, is it a global or a param which you could have not aligned properly.
Dennis Handly
Acclaimed Contributor

Re: Core dump with BUS_ADRALN error

>I have not compiled my code using +w64bit +wlint

Don't even think about porting until you have done this. What version of aCC6 do you have?

>but with more flags like +p +O2 +Ofltacc=relaxed +Onolimit +DSmontecito +FPD -Wl,+pi,1M -Wl,+pd,1M -Wl,+mergeseg -Wl,+s +w1.

Don't use +O2 until you are done, it prevents debugging. +w1 is obsolete, replace by just +w on IPF.

>I have checked the datatypes of the arguments with the datatypes of the arguments that the function is expected

No structs being passed?

>This is frame 0, And this is the last frame.

(This was in your initial message.)

>rqst is an argument for a functions in my code for which I am not able to find the value while debugging.

Remove that +O2.

>Below is the frame that belongs to my code
#4 0x4000000000023970:0 in line_test (rqst=) svc.c:377
>But the line 377 is just a debug statement which is getting printed in the log.
>After this line I have a function call of 3rd party library.

Do you pass rqst to that ti_line_test?

>Laurent: what is the line you can see?

All good questions. If you don't have the source you will have to debug in assembly mode:
(gdb) frame 0
(gdb) disas $pc-16*8 $pc+16*4
(gdb) info reg
Laurent Menase
Honored Contributor

Re: Core dump with BUS_ADRALN error

(gdb) frame 0
(gdb) disas $pc-16*8 $pc+16*4
(gdb) info reg

exactly what I meant!
K!rn Kumr
Frequent Advisor

Re: Core dump with BUS_ADRALN error

I have a doubt. I have gone through many of the docs from hp site. All of them say to use +DD64 for 64bit compilation on itanium platform. I have no idea of +w64bit and +wlint.

I am using A.06.15 version of aCC.

Yeah I am passing pointers to structures.

No I do not pass rqst to the function.

Can you please help by suggesting some site or some info on how to debug in assembly mode.

Thanks in advance
K!rn Kumr
Frequent Advisor

Re: Core dump with BUS_ADRALN error

Yeah I have learnt that +w64bit and +wlint are for enabling the warning messages during porting to 64bit thanks for that....