[#4051] single stepping userspace sometimes hangs the system

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

[#4051] single stepping userspace sometimes hangs the system

Submitted By: Mike Frysinger

Open Date

2008-04-23 00:58:33     Close Date

2008-05-20 19:09:11

Priority:

Medium     Assignee:

Jie Zhang

Status:

Closed     Fixed In Release:

N/A

Found In Release:

N/A     Release:

svn trunk 4651

Category:

N/A     Board:

N/A

Processor:

N/A     Silicon Revision:

Is this bug repeatable?:

Yes     Resolution:

Fixed

Uboot version or rev.:

    Toolchain version or rev.:

App binary format:

N/A     

Summary: single stepping userspace sometimes hangs the system

Details:

 

before the recent trap updates, when single stepping through the fixed code section, we'd randomly (but quite frequently) get the "Undefined instruction" trap below ... but things would continue to run in userspace without a problem (in other words, the application that was being debugged would not get killed and things appeared to still work properly; kind of odd).  with current svn trunk though, the kernel just hangs and then the watchdog kicks it.

 

Undefined instruction

- May be used to emulate instructions that are not defined for

   a particular processor implementation.

Deferred Exception context

CURRENT PROCESS:

COMM=a.out PID=143

TEXT = 0x00a59000-0x00a5975c        DATA = 0x00a5675c-0x00a568bc

BSS = 0x00a568bc-0x00a20000  USER-STACK = 0x00a3fed0

 

return address: [0xffa00612]; contents of:

0xffa005f0:  017e  0179  0140  0140  6000  3620  3628  3630

0xffa00600:  3638  3046  6fa6  e330  1f95  6c66  2000  0000

0xffa00610:  017a [0148] 0140  05c0  014f  0178  0150  0151

0xffa00620:  0152  0153  0154  0155  0156  0157  015c  015d

 

SEQUENCER STATUS:               Not tainted

SEQSTAT: 00062021  IPEND: 0030  SYSCFG: 0007

  HWERRCAUSE: 0x18

  EXCAUSE   : 0x21

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

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

RETX: <0xffa00612> { _exception_to_level5 + 0x2 }

RETS: <0x0062a7b6> [ /lib/libuClibc-0.9.29.so + 0x2a7b6 ]

PC  : <0x0314216e> [ /lib/libgcc_s.so.1 + 0x216e ]

DCPLB_FAULT_ADDR: <0x0015f16c> /* unknown address */

ICPLB_FAULT_ADDR: <0xffa00612> { _exception_to_level5 + 0x2 }

 

PROCESSOR STATE:

R0 : fffffe00    R1 : 00000001    R2 : 00000000    R3 : 00000000

R4 : 00a5942c    R5 : 00a3ff80    R6 : 00a59730    R7 : 00401808

P0 : 00000020    P1 : 03142164    P2 : 00400e0c    P3 : 0316f300

P4 : 00a59428    P5 : 00a55298    FP : 00a3fd9c    SP : 00a1bf24

LB0: 03142179    LT0: 0314216c    LC0: 00000018

LB1: 03504569    LT1: 0350453a    LC1: 00000001

B0 : 00000000    L0 : 00000000    M0 : 00000000    I0 : 00a3ff58

B1 : 00000000    L1 : 00000000    M1 : 00000000    I1 : 00a59758

B2 : 00000000    L2 : 00000000    M2 : 00000000    I2 : 0350713c

B3 : 00000000    L3 : 00000000    M3 : 00000000    I3 : 00000000

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

USP : 00a3fd88  ASTAT: 02003025

 

Hardware Trace:

Stack from 00a1bf04:

        0316f300 ffa006c8 0015f184 0015f184 0015f17c 7fffffff 00a5942c 03142170

        ffa00612 00000030 00062021 00000000 00a1bffc ffa00612 0314216e 0062a7b6

        fffffe00 02003025 03504569 03142179 0350453a 0314216c 00000001 00000018

        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

        00000000 0350713c 00a59758 00a3ff58 00a3fd88 00a3fd9c 00a55298 00a59428

 

Call Trace:                                                                                                                                                               

 

 

note that single stepping the fixed code section seems to make the error happen much more frequently, but if i put gdb into single stepping normal code, i can eventually get it to die.

 

the way to reproduce is to make an app with an infinite loop like so:

int main() { asm volatile("jump.s 0;"); }

and then connect to it with gdb and just do:

define f

  stepi

  f

end

f

f

f

...

 

for the faster method, you can call the CAS32 fixed code:

int main()

{

        int i = 0;

        __asm__ __volatile__ (

                "1:"

                "R0 = 1;"

                "[%0] = R0;"

 

                "R1 = 1;"

                "R2 = 0;"

 

                "P0.l = 0x420;"

                "P0.h = 0;"

                "call (P0);"

                "jump 1b;"

                :

                : "a"(&i)

        );

        return 0;

}

put a watchpoint on &i, and have gdb automatically continue when the watchpoint is hit:

 

$ bfin-uclinux-gdb ./a.out.gdb

_stext () at libc/sysdeps/linux/bfin/crt1.S:84

84              FP = 0;

Current language:  auto; currently asm

(gdb) b main

Breakpoint 1 at 0x3780140: file cas.c, line 3.

(gdb) c

Continuing.

 

Breakpoint 1, main () at cas.c:3

3               int i = 0;

Current language:  auto; currently c

(gdb) print &i

$1 = (int *) 0x3781f30

(gdb) watch *(int *)0x3781f30

Watchpoint 2: *(int *) 0x3781f30

(gdb) commands 2

Type commands for when breakpoint 2 is hit, one per line.

End with a line saying just "end".

>bt 2

>c

>end

(gdb) c

Continuing.

Watchpoint 2: *(int *) 0x3781f30

 

Old value = 0x3780292

New value = 0x0

main () at cas.c:4

4               __asm__ __volatile__ (

#0  main () at cas.c:4

Watchpoint 2: *(int *) 0x3781f30

 

Old value = 0x0

New value = 0x1

0x0378014c in main () at cas.c:4

4               __asm__ __volatile__ (

#0  0x0378014c in main () at cas.c:4

<the board should hang fairly quickly>

 

Follow-ups

 

--- Mike Frysinger                                           2008-05-20 19:09:11

Bernd fixed this some time ago when he was banging on the traps code

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

No Files Were Found

Attachments

    Outcomes