2009-04-03 01:01:12     possible misaligned access

Document created by Aaronwu Employee on Aug 14, 2013
Version 1Show Document
  • View in full screen mode

2009-04-03 01:01:12     possible misaligned access

dean skuldt (UNITED STATES)

Message: 72083   

 

Hi there,

 

I'm experiencing SIGSEGV when running my app on a bf561 built with

version blackfin_uclinux_2008R1.5-RC3 of the tools (bfin-uclinux-g++)

and I'm having some trouble diagnosing the problem.

 

I am suspecting that this is related to a memory misalignment.  I've

read the debugging_applications doc, I've looked at my call trace and

objdump output, but I'm not seeing the answer and haven't identified

the offending code.

 

Any help is much appreciated, thanks,

 

Dean

 

root:/> NULL pointer access (probably)

Defered Exception context

CURRENT PROCESS:

COMM=test_b PID=168

TEXT = 0x02000040-0x02018de0        DATA = 0x02018df0-0x0202d360

BSS = 0x0202d360-0x02f72440  USER-STACK = 0x02fb2ecc

 

return address: [0x02001ff4]; contents of:

0x02001fd0:  2f7b  0000  05eb  e800  0000  aefd  3410  3419

0x02001fe0:  3402  3265  6c24  6005  e131  0080  e120  0124

0x02001ff0:  3218  328a [932d] 3290  9325  5a19  e129  0100

0x02002000:  e0b2  100d  9111  9442  40d1  9128  5008  9328

 

SEQUENCER STATUS:               Not tainted

SEQSTAT: 00060027  IPEND: 0030  SYSCFG: 0006

  HWERRCAUSE: 0x18

  EXCAUSE   : 0x27

RETE: <0x00000000> /* Maybe null pointer? */

RETN: <0x00906000> /* unknown address */

RETX: <0x02001ff4> [ test_b + 0x1fb4 ]

RETS: <0x02002208> [ test_b + 0x21c8 ]

PC  : <0x02001ff4> [ test_b + 0x1fb4 ]

DCPLB_FAULT_ADDR: <0x00000000> /* Maybe null pointer? */

ICPLB_FAULT_ADDR: <0x02001ff4> [ test_b + 0x1fb4 ]

 

PROCESSOR STATE:

R0 : 00000124    R1 : 00000001    R2 : 00000001    R3 : 02f6d478

R4 : 00000000    R5 : 00000000    R6 : 00000000    R7 : 00000001

P0 : 02f6d878    P1 : 008f0008    P2 : 02f71fe8    P3 : 00000124

P4 : 00000004    P5 : 00000000    FP : 02fb2d10    SP : 00905f24

LB0: 02003f9b    LT0: 02003f74    LC0: 00000000

LB1: 02003f8f    LT1: 02003f82    LC1: 00000000

B0 : 02fb2a50    L0 : 00000000    M0 : 00008004    I0 : 00000001

B1 : 0000001c    L1 : 00000000    M1 : 00000004    I1 : 00000080

B2 : 00940004    L2 : 00000000    M2 : 00008000    I2 : 008f0008

B3 : 00940004    L3 : 00000000    M3 : 00000000    I3 : 00000001

A0.w: 00000000   A0.x: 00000000   A1.w: 00000000   A1.x: 00000000

USP : 02fb2d10  ASTAT: 02002020

 

Hardware Trace:

   0 Target : <0x000046c4> { _trap_c + 0x0 }

     Source : <0xffa00794> { _exception_to_level5 + 0xb4 }

   1 Target : <0xffa006e0> { _exception_to_level5 + 0x0 }

     Source : <0xffa0063c> { _ex_trap_c + 0x5c }

   2 Target : <0xffa005e0> { _ex_trap_c + 0x0 }

     Source : <0xffa0046a> { _ex_workaround_261 + 0x22 }

   3 Target : <0xffa00448> { _ex_workaround_261 + 0x0 }

     Source : <0xffa00834> { _trap + 0x28 }

   4 Target : <0xffa0080c> { _trap + 0x0 }

     Source : <0x02001ff2> [ test_b + 0x1fb2 ]

   5 Target : <0x02001fd4> [ test_b + 0x1f94 ]

     Source : <0x02002204> [ test_b + 0x21c4 ]

   6 Target : <0x020021bc> [ test_b + 0x217c ]

     Source : <0x020036dc> [ test_b + 0x369c ]

   7 Target : <0x020036ca> [ test_b + 0x368a ]

     Source : <0x02003fa2> [ test_b + 0x3f62 ]

   8 Target : <0x02003f38> [ test_b + 0x3ef8 ]

     Source : <0x02003f4e> [ test_b + 0x3f0e ]

   9 Target : <0x02003f38> [ test_b + 0x3ef8 ]

     Source : <0x02003f4e> [ test_b + 0x3f0e ]

  10 Target : <0x02003f38> [ test_b + 0x3ef8 ]

     Source : <0x02003f4e> [ test_b + 0x3f0e ]

  11 Target : <0x02003f38> [ test_b + 0x3ef8 ]

     Source : <0x02003f4e> [ test_b + 0x3f0e ]

  12 Target : <0x02003f38> [ test_b + 0x3ef8 ]

     Source : <0x02003f4e> [ test_b + 0x3f0e ]

  13 Target : <0x02003f38> [ test_b + 0x3ef8 ]

     Source : <0x02003f4e> [ test_b + 0x3f0e ]

  14 Target : <0x02003f38> [ test_b + 0x3ef8 ]

     Source : <0x02003f4e> [ test_b + 0x3f0e ]

  15 Target : <0x02003f38> [ test_b + 0x3ef8 ]

     Source : <0x02003f4e> [ test_b + 0x3f0e ]

Stack from 00905f04:

        ffa00b4a ffa00798 ff8016a8 ff8016a8 ff8016a8 0201b940 00000019 000084f8

        02001ff4 00000030 00060027 00000000 00906000 02001ff4 02001ff4 02002208

        00000124 02002020 02003f8f 02003f9b 02003f82 02003f74 00000000 00000000

        00000000 00000000 00000000 00000000 00940004 00940004 0000001c 02fb2a50

        00000000 00000000 00000000 00000000 00000000 00008000 00000004 00008004

        00000001 008f0008 00000080 00000001 02fb2d10 02fb2d10 00000000 00000004

 

Call Trace:

 

QuoteReplyEditDelete

 

 

2009-04-03 01:47:40     Re: possible misaligned access

Robin Getz (UNITED STATES)

Message: 72084   

 

Dean:

 

Use addr2line, like it is described in the documetation you claim you read.

 

https://docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:debugging_applications#unaligned_data_access

QuoteReplyEditDelete

 

 

2009-04-03 09:13:24     Re: possible misaligned access

dean skuldt (UNITED STATES)

Message: 72108   

 

Actually, addr2line provides me with no line number for some reason, and in general (even if it did work in my case) seems to provide less useful info than objdump.

 

I can map objdump's output to my code, but I'm still having trouble finding the cause.  Three (* int32)'s are passed into this method, all pointing to int32 arrays -- I don't see that the pointers have been mishandled prior to passing them to the method, and I don't see that they're being mishandled inside the method.  Each of these arrays was defined staticly with aligned (4).  Since I'm not finding any mishandling of these pointers by inspecting the code, I'm wondering if there is some other cause of misalignment.  So hopefully someone can see it clearly by looking at my objdump output...

 

I'm not experienced with reading output from objdump --- there are several dereferences (P5,P4,P2).  P4 and P2 both look misaligned to me, but I'm not sure that I'm reading that correctly.  Here is the objdump output (with class and method names changed in the label name for LSETUP):

 

    1f94:    eb 05           [--SP] = (R7:5, P5:3);

    1f96:    00 e8 00 00     LINK 0x0;        /* (0) */

    1f9a:    fd ae           P5 = [FP + 0x2c];

    1f9c:    10 34           I2 = R0;

    1f9e:    19 34           I3 = R1;

    1fa0:    02 34           I0 = R2;

    1fa2:    65 32           P4 = P5;

    1fa4:    24 6c           P4 += 0x4;        /* (  4) */

    1fa6:    05 60           R5 = 0x0 (X);        /*        R5=0x0(  0) */

    1fa8:    31 e1 80 00     I1 = 0x80 (X);        /*        I1=0x80(128) */

    1fac:    20 e1 24 01     R0 = 0x124 (X);        /*        R0=0x124(292) */

    1fb0:    18 32           P3 = R0;

    1fb2:    8a 32           P1 = I2;

    1fb4:    2d 93           [P5] = R5;

    1fb6:    90 32           P2 = I0;

    1fb8:    25 93           [P4] = R5;

    1fba:    19 5a           P0 = P1 + P3;

    1fbc:    29 e1 00 01     P1 = 0x100 (X);        /*        P1=0x100 <__ZN11system_timeC2Ev>(256) */

    1fc0:    b2 e0 0d 10     LSETUP(0x1fc4 <__ZN13class_name11method_nameEPKlS1_Pl+0x30>, 0x1fda <__ZN13class_name11method_nameEPKlS1_Pl+0x46>) LC1 = P1;

    1fc4:    11 91           R1 = [P2];

 

 

Thanks again for any help.

QuoteReplyEditDelete

 

 

2009-04-03 09:20:12     Re: possible misaligned access

Mike Frysinger (UNITED STATES)

Message: 72110   

 

the kernel tells you the answer already like the doc Robin pointed out

 

this isnt an alignment bug.  the kernel told you:

NULL pointer access

 

then if you look at where the kernel said it happened:

ICPLB_FAULT_ADDR: <0x02001ff4> [ test_b + 0x1fb4 ]

 

and use the code you posted:

    1fb4:    2d 93           [P5] = R5;

 

and the register the kernel said:

P5 : 00000000

 

dont dereference NULL pointers and your app wont crash

Attachments

    Outcomes