Core dump with BUS_ADRALN error

[K!rn Kumr]

You are really amazing and awesome your knowledge and at responding. Its really pleasure to interact with people like you.

Could you please help me learning that by sharing info like who to develop such kind of art of debugging. Please suggest any book or online guide anything for me to get this knowledge.

[Dennis Handly]

>host_entry = (struct hostent*) 0x60000000000c9f18

This is the return value. You can print some fields out:
p host_entry->h_aliases[0]
p host_entry->h_aliases[1]
(If the above doesn't fail, you can do more.)

x /4gx host_entry->h_addr_list

x /4bu host_entry->h_addr_list[0]
x /4bu host_entry->h_addr_list[1]

[K!rn Kumr]

(gdb) p host_entry->h_aliases[2]
$4 = 0x0

(gdb) x /4bu host_entry->h_addr_list[1]
0x0: Cannot access memory at address 0x0

But how can we know the root cause for the crash

[Dennis Handly]

>You are really amazing and ...

Please read the following about assigning points:
http://forums.itrc.hp.com/service/forums/helptips.do?#33

>Could you please help me learning that by sharing info like who to develop such kind of art of debugging.

wdb has a bunch of documentation and whitepapers:
http://www.hp.com/go/wdb
Debugging core files using HP WDB
Debugging dynamic memory usage errors using HP WDB
Debugging threads with HP Wilde Beest debugger

And Intel has various manuals about the Itanium instruction set.
Basically you need to know assembly language, procedure calling conventions, etc.

>But how can we know the root cause for the crash?

I already mentioned my guess:
Basically it seems the code in get_tcp_service thinks that h_addr_list can be treated as a unsigned long instead of an unsigned int. Or a struct in_addr.

gethostent(3n) has an example how to format h_addr_list:
http://docs.hp.com/en/B2355-60130/gethostent.3N.html

It would be helpful if you could provide the definition of struct in_addr. Probably in /usr/include/netinet/in.h.
struct in_addr {
in_addr_t s_addr;
};

Where in_addr_t should be uint32_t.

This old document mentions what happens in 64 bit mode: Chapter 4 64-Bit Capable Implementation, BSD Sockets: IP Addresses
http://docs.hp.com/en/B3782-90716/ch04s11.html

[Dennis Handly]

Some compiler documentation links:
http://www.hp.com/go/aCC
HP compilers for HP Integrity servers
Optimizing Itanium®-based applications
Inline assembly for Itanium®-based HP-UX

The first explains predication and speculation.

[Dennis Handly]

If you have nothing better to do while waiting for your third party vendor to fix their h_addr_list coding problem, you could do what is suggested in the gdb abort message:
BUS_ADRALN - Invalid address alignment. Please refer to the following link that helps in handling unaligned data:
http://docs.hp.com/en/14487/pragmas.htm#pragma-pack-ex4

By calling allow_unaligned_data_access and linking with -lunalign, you can get past that alignment fault and find the next problem.

[K!rn Kumr]

I have already given it a try by compiling my code with -lunalign. But its not my code accessing it. So it is again the 3rd party code that has to be fixed either by changing the code or compiling it with flag -lunalign(donno if it really works. So I really have nothing to do. Meanwhile I have one more doubt by looking at the frame0 how can you decide its fault in that frame. Can that be a repurcusion of fault occuring in someother frame before that. Actually frame3 and frame2 are third party code is for sure and frame1 and frame0 must be code on hp builtin source i guess...

[Dennis Handly]

>I have already given it a try by compiling my code with -lunalign. But it's not my code accessing it.

It doesn't matter who is messing up, calling allow_unaligned_data_access will handle it. (You would have to do it for each thread.)

>So it is again the 3rd party code that has to be fixed either by changing the code or compiling it with flag -lunalign

No, they must fix it by changing the code. Using libunalign is only a kludge so you can make progress and find your bugs.

>I have one more question by looking at the frame 0 how can you decide its fault in that frame?

That's how the hardware works and the debugger said so. If you get a fault/signal, it stops there. Unless you have a signal handler, then it can be deeper.

>Can that be a repercussion of fault occurring in some other frame before that?

Yes a bug in a previous frame could pass a bad address to the final frame.

>Actually frame 3 and frame 2 are third party code is for sure and frame 1 and frame 0 must be code on HP builtin source I guess.

No, frame 1 and frame 0 are likely third party code too. You can get some idea by:
(gdb) frame 0
(gdb) info source
...

[K!rn Kumr]

Hi...

I need your help again...my does not crash when i create a string and reserve a space for it.

string *str = new str;
str->reserve(3000);

If i dont reserve it is crashing. I need to append a values to that string dynamically with the values that i get from some server reponse. Do you have any idea why is it happening so. and from disas how do i know which register is what. pls help me in learning by telling few steps hw to start with assembly mode debugging...intial steps...

[Dennis Handly]

>does not crash when I create a string and reserve a space for it.
>string *str = new string;
>str->reserve(3000);

Note that using new on a string isn't that useful, since it only allocates 8 bytes, then later the space in a separate chunk.

>If I don't reserve it is crashing.
>I need to append a values to that string dynamically with the values that I get from some server response.

How are you accessing/appending to the string? Using str->append or str->operator+?

>Do you have any idea why is it happening so? and from disas how do I know which register is what?

Typically this is heap corruption and the string operation is the victim. Try compiling with +check=malloc,bounds

>pls help me in learning by telling few steps how to start with assembly mode debugging... initial steps.

You should start with a stack trace. Since C++ has lots of inlining, you may want to compile with +d so you see the names all of the functions. And remove +O2.