On Thu, Jun 27, 2013 at 9:11 PM, <[email protected]> wrote: > On Thu, 27 Jun 2013 18:29:48 +0700, Mulyadi Santosa said: > > On Thu, Jun 27, 2013 at 1:23 PM, Mohammed Shafi <[email protected]> > 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;
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
