Hi John,
This also crashes on the Blackfin BF537 Stamp (2008R1)
Here is the (very nice) crash dump
/var/SigTest
NULL pointer access (probably)
Defered Exception context
CURRENT PROCESS:
COMM=ls PID=105
TEXT = 0x01100040-0x01151560 DATA = 0x01151564-0x01167864
BSS = 0x01167864-0x0116eec4 USER-STACK = 0x01176f90
return address: [0x0110bf3e]; contents of:
0x0110bf10: 0c00 17f5 6000 e801 0000 0528 0010 434b
0x0110bf20: c682 8043 5603 c682 8280 e146 7efe e147
0x0110bf30: 8101 3212 5748 e106 feff e107 0100 [9012]
0x0110bf40: 5032 43d1 5808 5438 0c00 1408 5815 5070
SEQUENCER STATUS: Not tainted
SEQSTAT: 00000027 IPEND: 0030 SYSCFG: 0006
HWERRCAUSE: 0x0
EXCAUSE : 0x27
RETE: <0x00000000> /* Maybe null pointer? */
RETN: <0x00720000> [ SigTest + 0x0 ]
RETX: <0x0110bf3e> [ ls + 0xbefe ]
RETS: <0x0110c448> [ ls + 0xc408 ]
PC : <0x0110bf3e> [ ls + 0xbefe ]
DCPLB_FAULT_ADDR: <0x00000000> /* Maybe null pointer? */
ICPLB_FAULT_ADDR: <0x0110bf3e> [ ls + 0xbefe ]
PROCESSOR STATE:
R0 : 00002f2f R1 : 2f2f0000 R2 : 00000000 R3 : 0000002f
R4 : 01119428 R5 : 2f2f2f2f R6 : 7efefeff R7 : 81010100
P0 : 01176f09 P1 : 00000003 P2 : 00000000 P3 : 01176f94
P4 : 00730234 P5 : 01151564 FP : 01176f14 SP : 0071ff24
LB0: 0110be09 LT0: 0110be08 LC0: 00000000
LB1: 007204a7 LT1: 007204a6 LC1: 00000000
B0 : 00000000 L0 : 00000000 M0 : 00000000 I0 : 01176ea9
B1 : 00000000 L1 : 00000000 M1 : 00000000 I1 : 00000000
B2 : 00000000 L2 : 00000000 M2 : 00000000 I2 : 00000000
B3 : 00000000 L3 : 00000000 M3 : 00000000 I3 : 00000000
A0.w: 00000000 A0.x: 00000000 A1.w: 00000000 A1.x: 00000000
USP : 01176f14 ASTAT: 02002020
Hardware Trace:
0 Target : <0x0000483c> { _trap_c + 0x0 }
Source : <0xffa0076c> { _exception_to_level5 + 0xb4 }
1 Target : <0xffa006b8> { _exception_to_level5 + 0x0 }
Source : <0xffa00614> { _ex_trap_c + 0x5c }
2 Target : <0xffa005b8> { _ex_trap_c + 0x0 }
Source : <0xffa00442> { _ex_workaround_261 + 0x22 }
3 Target : <0xffa00420> { _ex_workaround_261 + 0x0 }
Source : <0xffa0080c> { _trap + 0x28 }
4 Target : <0xffa007e4> { _trap + 0x0 }
Source : <0xffa0055a> { _bfin_return_from_exception + 0xe }
5 Target : <0xffa0054c> { _bfin_return_from_exception + 0x0 }
Source : <0xffa00432> { _ex_workaround_261 + 0x12 }
6 Target : <0xffa00420> { _ex_workaround_261 + 0x0 }
Source : <0xffa0080c> { _trap + 0x28 }
7 Target : <0xffa007e4> { _trap + 0x0 }
Source : <0x0110bf3a> [ ls + 0xbefa ]
8 Target : <0x0110bf1e> [ ls + 0xbede ]
Source : <0x0110beee> [ ls + 0xbeae ]
9 Target : <0x0110bee0> [ ls + 0xbea0 ]
Source : <0x0110c444> [ ls + 0xc404 ]
10 Target : <0x0110c440> [ ls + 0xc400 ]
Source : <0x0110c438> [ ls + 0xc3f8 ]
11 Target : <0x0110c428> [ ls + 0xc3e8 ]
Source : <0x0111431a> [ ls + 0x142da ]
12 Target : <0x011142fe> [ ls + 0x142be ]
Source : <0x0110a5bc> [ ls + 0xa57c ]
13 Target : <0x0110a5aa> [ ls + 0xa56a ]
Source : <0x0110c93c> [ ls + 0xc8fc ]
14 Target : <0x0110c934> [ ls + 0xc8f4 ]
Source : <0x0110ca64> [ ls + 0xca24 ]
15 Target : <0x0110ca5c> [ ls + 0xca1c ]
Source : <0x0110be0a> [ ls + 0xbdca ]
Stack from 0071ff04:
00000000 ffa00770 0014456c 0014456c 00144568 01176f08 01119428
0110200c
0110bf3e 00000030 00000027 00000000 00720000 0110bf3e 0110bf3e
0110c448
00002f2f 02002020 007204a7 0110be09 007204a6 0110be08 00000000
00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
00000000 00000000 00000000 01176ea9 01176f14 01176f14 01151564
00730234
Call Trace:
[<00002f2f>] _do_signal+0x2df/0xd74
[<00002f2f>] _do_signal+0x2df/0xd74
NO time at the moment to look any deeper.
Regards
Phil WIlshire
John Williams wrote:
Hi,
We've had a problem reported on MicroBlaze arch and I was wondering if
someone with access to another NOMM Uarch could run the same test, see
if the result is duplicated.
It's a simple test case attached (don't forget to link pthreads library).
Basically we have parent that
1. blocks all signals
2. spawns a thread (SigHandler)
3. vforks()
- child does execve("/bin/ls",NULL)
- parent sleep() loops forever
The SigHandler thread
1. blocks all signals
2. does a sigwait() loop
if SIGCHLD delivered,
_exit()
On regular PC, this runs as expected - as soon as 'ls' completes,
everything shuts down.
However on MicroBlaze / noMMU, the child of the vfork() ('ls') becomes a
Zombie and never exits, thus SIGCHLD never gets raised, and it all hangs.
Reports of behaviour on another noMMU arch would be greatly appreciated.
Is this a noMMU-ism? If so, any simple workarounds ? Otherwise, I'll
have to go digging in arch/microblaze :(
Thanks,
John
------------------------------------------------------------------------
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
