On Monday 01 June 2009 20:03:43 Nathan Wharton wrote:
I had to copy the patches out of the e-mail.
Here is the back trace: #0 list_add_tail (new=0x29bf0, head=0x298c9) at list-batman.c:68 #1 0x0000ee7c in _hna_global_add (orig_node=0x29f80, hna_element=0x29ba8) at hna.c:371 #2 0x0000f160 in hna_global_add (orig_node=0x29f80, new_hna=<value optimized out>, new_hna_len=<value optimized out>) at hna.c:529 #3 0x000099c8 in update_routes (orig_node=0x29f80, neigh_node=0x2a080, hna_recv_buff=0xbead1591 "\n\002\001", hna_buff_len=10) at batman.c:377 #4 0x0000c730 in update_orig (orig_node=0x29f80, in=0xbead157f, neigh=167772673, if_incoming=0x27678, hna_recv_buff=0xbead1591 "\n\002\001", hna_buff_len=-16723, is_duplicate=0 '\0', curr_time=3199014207) at originator.c:227 #5 0x0000a7e0 in batman () at batman.c:956 #6 0x000148d4 in main (argc=14, argv=0xbead1e14) at posix/posix.c:629
Looks like debugMalloc didn't return an aligned value for head. I'll step through that and see what I see.
Ok, I think I see the problem. The malloc returned a valid aligned adress. list_add_tail will get a pointer to an element in hna_global_entry. This structure is packed and all operations on it should be non-alignment safe. If you look at it further you will notice that orig_list is at position 9 (assuming 4 bytes for a pointer) - which will not be aligned to 4 bytes of course..... And here comes the problem: the compiler will only do the safe operations on non-aligned data if it knows that it is not alignent. Since a cast is done by calling list_add_tail it will not know that this parameter is not aligned and the non-alignment bug will occur.
So my question to marek: Is it really needed to have "struct hna_global_entry" packed in hna.h:57? If not then we should remove it and this problem should be gone. And what is with "struct hna_element".
Thank you for your work, Nathan :)
Regards, Sven