On Thu, Jun 27, 2013 at 9:11 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 27 Jun 2013 18:29:48 +0700, Mulyadi Santosa said:
On Thu, Jun 27, 2013 at 1:23 PM, Mohammed Shafi <shafi.kernel@gmail.com> wrote:
[ 486.447220] [<c000de98>] (__dabt_svc+0x38/0x60) from [<bf05c324>]
If you find that name through grepping kernel source tree, you shall find the culprit. The next number "0x38/0x60" AFAIK is the offset that shall point you to more exact location
To be more specific, the function is 0x60 (decimal 96) bytes long, and the pointer is at 0x38 (decimal 56) bytes into it. So even without a disassembly, you know its somewhere between 1/2 and 2/3 of the way through the code.
thanks Prasad, Mulyadi, Valdis (ath6kl_deliver_frames_to_nw_stack+0xac/0xf0 [ath6kl_core]) with the arm gdb, am able to find the exact line and based on the test engineers inputs, found the fix for crash. seems fuzzy testing sends a destination mac address as zero, while we initialize the list with mac address as zero, and memcmp returns a pointer, which inturn de-references to an uninitialized pointer. below is the fix :-) » if (is_zero_ether_addr(node_addr))66 » » return NULL;