* Re: [Xenomai-help] NULL pointer access on bfin when linking with xenomai and pthread
2011-01-25 9:31 [Xenomai-help] NULL pointer access on bfin when linking with xenomai and pthread Kolja Waschk
@ 2011-01-25 9:28 ` Gilles Chanteperdrix
2011-01-25 9:46 ` Kolja Waschk
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Gilles Chanteperdrix @ 2011-01-25 9:28 UTC (permalink / raw)
To: xenoka09; +Cc: xenomai
Kolja Waschk wrote:
> Ok, I'll start a new thread with the details. I'm not so sure if this is actually
> related to Xenomai, but until now I was only able to reproduce it in conjunction with
> xenomai libs, so ...
>
> The example is already reduced to a minimum. I'm working with a Blackfin-based
> board like BF537-STAMP, with 2010R1-RC5 blackfin-linux-dist on it and stock kernel
> as it comes with the dist (2.6.34.7-ADI-2010R1). Just Xenomai 2.5.3 was replaced
> by 2.5.5.2. Toolchain is 2010R1-RC4 taken as binary from blackfin.uclinux.org.
>
> The code itself actually doesn't seem to matter. The problem can be reproduced with an
> example as simple as this "a.c":
>
>> int main (void) { return 0; }
>
> Normally, this can be started on the target via gdbserver and debugged from the host.
> I used the gdb command script
>
>> file a.out
>> target remote 10.0.10.9:2222
>> break main
>> cont
>
> The target would run the example, and stop, e.g. at "Breakpoint 1, 0x00b7b626 in main ()"
>
> These compile commands produce a working a.out:
>
>> bfin-linux-uclibc-gcc -L/opt/uClinux/blackfin-linux-dist/staging/usr/lib -lpthread a.c
>
> or
>
>> bfin-linux-uclibc-gcc -L/opt/uClinux/blackfin-linux-dist/staging/usr/lib -lpthread_rt -lxenomai a.c
>
> but this one that combines all -l options above doesn't:
>
>> bfin-linux-uclibc-gcc -L/opt/uClinux/blackfin-linux-dist/staging/usr/lib -lpthread_rt -lxenomai -lpthread a.c
>
> (Adding -lrt, to complete the suggested posix-ldflags, doesn't help, so I omit
> it here for shortness)
>
> The result on the target, when started with gdbserver and as soon as the host
> says "cont", is a NULL pointer access. It seems to occur even before main() is
> reached.
Some Xenomai code is executed before the main function is called. What I
do not understand is why gdb does not stop at the place of the segfault?
--
Gilles.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Xenomai-help] NULL pointer access on bfin when linking with xenomai and pthread
@ 2011-01-25 9:31 Kolja Waschk
2011-01-25 9:28 ` Gilles Chanteperdrix
0 siblings, 1 reply; 11+ messages in thread
From: Kolja Waschk @ 2011-01-25 9:31 UTC (permalink / raw)
To: xenomai
Ok, I'll start a new thread with the details. I'm not so sure if this is actually
related to Xenomai, but until now I was only able to reproduce it in conjunction with
xenomai libs, so ...
The example is already reduced to a minimum. I'm working with a Blackfin-based
board like BF537-STAMP, with 2010R1-RC5 blackfin-linux-dist on it and stock kernel
as it comes with the dist (2.6.34.7-ADI-2010R1). Just Xenomai 2.5.3 was replaced
by 2.5.5.2. Toolchain is 2010R1-RC4 taken as binary from blackfin.uclinux.org.
The code itself actually doesn't seem to matter. The problem can be reproduced with an
example as simple as this "a.c":
> int main (void) { return 0; }
Normally, this can be started on the target via gdbserver and debugged from the host.
I used the gdb command script
> file a.out
> target remote 10.0.10.9:2222
> break main
> cont
The target would run the example, and stop, e.g. at "Breakpoint 1, 0x00b7b626 in main ()"
These compile commands produce a working a.out:
> bfin-linux-uclibc-gcc -L/opt/uClinux/blackfin-linux-dist/staging/usr/lib -lpthread a.c
or
> bfin-linux-uclibc-gcc -L/opt/uClinux/blackfin-linux-dist/staging/usr/lib -lpthread_rt -lxenomai a.c
but this one that combines all -l options above doesn't:
> bfin-linux-uclibc-gcc -L/opt/uClinux/blackfin-linux-dist/staging/usr/lib -lpthread_rt -lxenomai -lpthread a.c
(Adding -lrt, to complete the suggested posix-ldflags, doesn't help, so I omit
it here for shortness)
The result on the target, when started with gdbserver and as soon as the host
says "cont", is a NULL pointer access. It seems to occur even before main() is
reached.
Following is the complete output on the target:
/tmp # gdbserver :2222 ./a.out
Process ./a.out created; pid = 320
Listening on port 2222
Remote debugging from host 10.0.10.10
NULL pointer access
Deferred Exception context
CURRENT PROCESS:
COMM=a.out PID=320 CPU=0
TEXT = 0x00ea9000-0x00ea96c8 DATA = 0x00eaa6c8-0x00eaa834
BSS = 0x00eaa834-0x013a0000 USER-STACK = 0x013bfe60
return address: [0x01666f10]; contents of:
0x01666ef0: e42f 0015 0c07 1405 3047 67f8 e628 0015
0x01666f00: 320e 3044 300d 3014 e50a 003a 5ea2 9153
0x01666f10: [9159] ac5b 0061 0c07 1404 6000 e628 0015
0x01666f20: e801 0000 05a4 0010 e51a 0016 05f4 e800
ADSP-BF537-0.3 533(MHz CCLK) 133(MHz SCLK) (mpu off)
Linux version 2.6.34.7-ADI-2010R1-svn10663 (kawk@domain.hid) (gcc version 4.3.5 (ADI-2010R1-RC4) ) #58 Mon Jan 24 17:24:55 CET 2011
SEQUENCER STATUS: Not tainted
SEQSTAT: 00060027 IPEND: 0008 IMASK: ffff SYSCFG: 0006
EXCAUSE : 0x27
physical IVG3 asserted : <0xffa0076c> { _trap + 0x0 }
RETE: <0x00000000> /* Maybe null pointer? */
RETN: <0x00b8a000> /* kernel dynamic memory */
RETX: <0x00000480> /* Maybe fixed code section */
RETS: <0x01666eda> [ /lib/libpthread.so.0 + 0x6eda ]
PC : <0x01666f10> [ /lib/libpthread.so.0 + 0x6f10 ]
DCPLB_FAULT_ADDR: <0x00000000> /* Maybe null pointer? */
ICPLB_FAULT_ADDR: <0x01666f10> [ /lib/libpthread.so.0 + 0x6f10 ]
PROCESSOR STATE:
R0 : 0000001c R1 : 013bd374 R2 : 013bd3f4 R3 : 00000008
R4 : 013bd3f4 R5 : 013bd374 R6 : 015e9448 R7 : 00000000
P0 : 000000ae P1 : 015e9448 P2 : 015e9650 P3 : 00000000
P4 : 0000001c P5 : 015e8b40 FP : 013bd340 SP : 00b89f24
LB0: 01620483 LT0: 01620482 LC0: 00000000
LB1: 016675a1 LT1: 01667578 LC1: 000003ff
B0 : 00000137 L0 : 00000000 M0 : 000000b4 I0 : 013bd6bc
B1 : 000000c0 L1 : 00000000 M1 : 00000001 I1 : 00000001
B2 : 7ffff000 L2 : 00000000 M2 : 00001802 I2 : 00000002
B3 : 00000000 L3 : 00000000 M3 : 0000005b I3 : 00000006
A0.w: 00000000 A0.x: 00000000 A1.w: 00000000 A1.x: 00000000
USP : 013bd330 ASTAT: 02003064
Hardware Trace:
0 Target : <0x00003bf8> { _trap_c + 0x0 }
Source : <0xffa00700> { _exception_to_level5 + 0xa4 } JUMP.L
1 Target : <0xffa0065c> { _exception_to_level5 + 0x0 }
Source : <0xffa00510> { _bfin_return_from_exception + 0x18 } RTX
2 Target : <0xffa004f8> { _bfin_return_from_exception + 0x0 }
Source : <0xffa005b4> { _ex_trap_c + 0x74 } JUMP.S
3 Target : <0xffa00540> { _ex_trap_c + 0x0 }
Source : <0xffa007c4> { _trap + 0x58 } JUMP (P4)
4 Target : <0xffa0076c> { _trap + 0x0 }
FAULT : <0x01666f10> [ /lib/libpthread.so.0 + 0x6f10 ] P1 = [P3]
Source : <0x01666f0e> [ /lib/libpthread.so.0 + 0x6f0e ] P3 = [P2]
5 Target : <0x01666eee> [ /lib/libpthread.so.0 + 0x6eee ]
Source : <0x01666ee2> [ /lib/libpthread.so.0 + 0x6ee2 ] IF CC JUMP pcrel (BP)
6 Target : <0x01666eda> [ /lib/libpthread.so.0 + 0x6eda ]
Source : <0x01666e64> [ /lib/libpthread.so.0 + 0x6e64 ] RTS
7 Target : <0x01666e60> [ /lib/libpthread.so.0 + 0x6e60 ]
Source : <0x01666e3c> [ /lib/libpthread.so.0 + 0x6e3c ] JUMP.S
8 Target : <0x01666e18> [ /lib/libpthread.so.0 + 0x6e18 ]
Source : <0x01666ed6> [ /lib/libpthread.so.0 + 0x6ed6 ] CALL pcrel
9 Target : <0x01666ec8> [ /lib/libpthread.so.0 + 0x6ec8 ]
Source : <0xffa00d12> { __common_int_entry + 0xce } RTI
10 Target : <0xffa00cb0> { __common_int_entry + 0x6c }
Source : <0xffa00f80> { _evt_system_call + 0x64 } JUMP.S
11 Target : <0xffa00f80> { _evt_system_call + 0x64 }
Source : <0xffa00982> { _system_call + 0xee } RTS
12 Target : <0xffa0097c> { _system_call + 0xe8 }
Source : <0x000031fe> { _do_notify_resume + 0x52 } RTS
13 Target : <0x000031fa> { _do_notify_resume + 0x4e }
Source : <0x000031dc> { _do_notify_resume + 0x30 } IF CC JUMP pcrel (BP)
14 Target : <0x000031ce> { _do_notify_resume + 0x22 }
Source : <0x000031aa> { _do_signal + 0x126 } RTS
15 Target : <0x000031a0> { _do_signal + 0x11c }
Source : <0x00003118> { _do_signal + 0x94 } IF CC JUMP pcrel (BP)
Userspace Stack
Stack info:
SP: [0x013bd330] <0x013bd330> [ a.out + 0x1d330 ]
Memory from 0x013bd330 to 013be000
013bd330:[00000000] 00000000 00000000 00000000 013bd4d8 00000400 013bd638 00b8595c
013bd350: 013bd580 01599628 0000001c 013be86c 0000001c 013bd374 013bd3f4 00000000
013bd370: 00000000 0000001c 00000000 ffffffff 00000000 00000000 00000002 00000000
013bd390: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
013bd3b0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
...
013bdfb0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
013bdfd0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
013bdff0: 00000000 00000000 00000000 00000000
Return addresses in stack:
address : <0x01665f66> [ /lib/libpthread.so.0 + 0x5f66 ]
address : <0x0166759a> [ /lib/libpthread.so.0 + 0x759a ]
The specified locations RETS and PC
> RETS: <0x01666eda> [ /lib/libpthread.so.0 + 0x6eda ]
> PC : <0x01666f10> [ /lib/libpthread.so.0 + 0x6f10 ]
resolve to
> 0x6eda libpthread/linuxthreads.old/signals.c:113
> 0x6f10 libpthread/linuxthreads.old/signals.c:127
Kolja
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] NULL pointer access on bfin when linking with xenomai and pthread
2011-01-25 9:28 ` Gilles Chanteperdrix
@ 2011-01-25 9:46 ` Kolja Waschk
2011-01-25 9:48 ` Kolja Waschk
2011-01-25 9:50 ` Kolja Waschk
2 siblings, 0 replies; 11+ messages in thread
From: Kolja Waschk @ 2011-01-25 9:46 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
> Some Xenomai code is executed before the main function is called. What I
> do not understand is why gdb does not stop at the place of the segfault?
Good point. Sorry, it does, but I fail to get useful information from there. Even
with -g and
> set solib-absolute-prefix notexistent
> set solib-search-path /opt/uClinux/blackfin-linux-dist/staging/usr/lib:/opt/uClinux/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib
..gdb doesn't seem to be able to resolve the addresses in the library:
Program received signal SIGSEGV, Segmentation fault.
0x01666f10 in ?? ()
(gdb) bt
#0 0x01666f10 in ?? ()
#1 0x01666eda in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info sharedlibrary
>From To Syms Read Shared Object Library
0x016c33cc 0x016c8244 No /opt/uClinux-2010R1-RC5_tools-RC4/blackfin-linux-dist/staging/usr/lib/libpthread_rt.so.1
0x00ea936c 0x00eab048 No /opt/uClinux-2010R1-RC5_tools-RC4/blackfin-linux-dist/staging/usr/lib/libxenomai.so.0
0x01664108 0x016689ec No /opt/uClinux-2010R1-RC5_tools-RC4/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib/libpthread.so.0
0x0152060c 0x01520a54 No /opt/uClinux-2010R1-RC5_tools-RC4/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib/librt.so.0
0x016523d4 0x0165dd88 No /opt/uClinux-2010R1-RC5_tools-RC4/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib/libgcc_s.so.1
0x0160ca24 0x01636df8 No /opt/uClinux-2010R1-RC5_tools-RC4/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib/libc.so.0
0x019c0c60 0x019c4634 No /opt/uClinux-2010R1-RC5_tools-RC4/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib/ld-uClibc.so.0
(gdb)
Kolja
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] NULL pointer access on bfin when linking with xenomai and pthread
2011-01-25 9:28 ` Gilles Chanteperdrix
2011-01-25 9:46 ` Kolja Waschk
@ 2011-01-25 9:48 ` Kolja Waschk
2011-01-25 9:50 ` Kolja Waschk
2 siblings, 0 replies; 11+ messages in thread
From: Kolja Waschk @ 2011-01-25 9:48 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
> Some Xenomai code is executed before the main function is called. What I
> do not understand is why gdb does not stop at the place of the segfault?
Ahm, well, I should look for libs with debug info included. I don't think the
precanned toolchains come with those. So if necessary, this will now take a while... K.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] NULL pointer access on bfin when linking with xenomai and pthread
2011-01-25 9:28 ` Gilles Chanteperdrix
2011-01-25 9:46 ` Kolja Waschk
2011-01-25 9:48 ` Kolja Waschk
@ 2011-01-25 9:50 ` Kolja Waschk
2011-01-25 9:52 ` Gilles Chanteperdrix
2 siblings, 1 reply; 11+ messages in thread
From: Kolja Waschk @ 2011-01-25 9:50 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
> Some Xenomai code is executed before the main function is called. What I
> do not understand is why gdb does not stop at the place of the segfault?
One step further. After issuing "sharedlibrary" the syms are read. The backtrace then is
#0 0x01666f10 in pthread_sighandler_rt (signo=28, si=0x13bd374, uc=0x13bd3f4)
at libpthread/linuxthreads.old/signals.c:127
#1 <signal handler called>
#2 0x0160cf1e in __syscall_rt_sigaction (signum=<value optimized out>, act=0x13bd580, oldact=0x13bd4f4, size=8)
at libc/sysdeps/linux/common/__syscall_rt_sigaction.c:17
#3 0x0162f482 in __libc_sigaction (sig=28, act=0x13bd638, oact=0xb8995c) at libc/signal/sigaction.c:58
#4 0x01666fba in *___GI_sigaction (sig=28, act=0x13bd6e8, oact=0xb8995c) at libpthread/linuxthreads.old/signals.c:163
#5 0x00b71c9a in xeno_sigshadow_install () at ../../../../xenomai-2.5.5.2/src/skins/common/sigshadow.c:70
#6 0x01665f66 in __pthread_once (once_control=0xb89958, init_routine=@0x1545bc4: 0xb71c64 <xeno_sigshadow_install>)
at libpthread/linuxthreads.old/mutex.c:315
#7 0x016c4132 in __wrap_pthread_setschedparam (thread=1024, policy=0, param=0x13bf9c8)
at ../../../../xenomai-2.5.5.2/src/skins/posix/thread.c:71
#8 0x016c376a in __init_posix_interface () at ../../../../xenomai-2.5.5.2/src/skins/posix/init.c:90
#9 0x016c8234 in __do_global_ctors_aux ()
from /opt/uClinux-2010R1-RC5_tools-RC4/blackfin-linux-dist/staging/usr/lib/libpthread_rt.so.1
#10 0x016c2cb6 in _init () from /opt/uClinux-2010R1-RC5_tools-RC4/blackfin-linux-dist/staging/usr/lib/libpthread_rt.so.1
#11 0x019c41b6 in _dl_get_ready_to_run (tpnt=0xb8836c, load_addr=<value optimized out>, auxvt=0x13bfda0, envp=0x13bfe6c,
argv=0x13bfe64, dl_boot_progmap=0x13bff40, dl_boot_got_pointer=21056480) at ldso/ldso/ldso.c:836
#12 0x019c44a4 in ?? ()
from /opt/uClinux-2010R1-RC5_tools-RC4/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib/ld-uClibc.so.0
#13 0x019c0cb0 in _dl_boot () at ./ldso/ldso/bfin/dl-inlines.h:31
Cannot access memory at address 0x16ffc78
Kolja
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] NULL pointer access on bfin when linking with xenomai and pthread
2011-01-25 9:50 ` Kolja Waschk
@ 2011-01-25 9:52 ` Gilles Chanteperdrix
2011-01-25 10:15 ` Kolja Waschk
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Gilles Chanteperdrix @ 2011-01-25 9:52 UTC (permalink / raw)
To: xenoka09; +Cc: xenomai
Kolja Waschk wrote:
>> Some Xenomai code is executed before the main function is called. What I
>> do not understand is why gdb does not stop at the place of the segfault?
>
> One step further. After issuing "sharedlibrary" the syms are read. The backtrace then is
>
> #0 0x01666f10 in pthread_sighandler_rt (signo=28, si=0x13bd374, uc=0x13bd3f4)
> at libpthread/linuxthreads.old/signals.c:127
> #1 <signal handler called>
> #2 0x0160cf1e in __syscall_rt_sigaction (signum=<value optimized out>, act=0x13bd580, oldact=0x13bd4f4, size=8)
> at libc/sysdeps/linux/common/__syscall_rt_sigaction.c:17
> #3 0x0162f482 in __libc_sigaction (sig=28, act=0x13bd638, oact=0xb8995c) at libc/signal/sigaction.c:58
> #4 0x01666fba in *___GI_sigaction (sig=28, act=0x13bd6e8, oact=0xb8995c) at libpthread/linuxthreads.old/signals.c:163
> #5 0x00b71c9a in xeno_sigshadow_install () at ../../../../xenomai-2.5.5.2/src/skins/common/sigshadow.c:70
> #6 0x01665f66 in __pthread_once (once_control=0xb89958, init_routine=@0x1545bc4: 0xb71c64 <xeno_sigshadow_install>)
> at libpthread/linuxthreads.old/mutex.c:315
> #7 0x016c4132 in __wrap_pthread_setschedparam (thread=1024, policy=0, param=0x13bf9c8)
> at ../../../../xenomai-2.5.5.2/src/skins/posix/thread.c:71
> #8 0x016c376a in __init_posix_interface () at ../../../../xenomai-2.5.5.2/src/skins/posix/init.c:90
> #9 0x016c8234 in __do_global_ctors_aux ()
> from /opt/uClinux-2010R1-RC5_tools-RC4/blackfin-linux-dist/staging/usr/lib/libpthread_rt.so.1
> #10 0x016c2cb6 in _init () from /opt/uClinux-2010R1-RC5_tools-RC4/blackfin-linux-dist/staging/usr/lib/libpthread_rt.so.1
> #11 0x019c41b6 in _dl_get_ready_to_run (tpnt=0xb8836c, load_addr=<value optimized out>, auxvt=0x13bfda0, envp=0x13bfe6c,
> argv=0x13bfe64, dl_boot_progmap=0x13bff40, dl_boot_got_pointer=21056480) at ldso/ldso/ldso.c:836
> #12 0x019c44a4 in ?? ()
> from /opt/uClinux-2010R1-RC5_tools-RC4/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib/ld-uClibc.so.0
> #13 0x019c0cb0 in _dl_boot () at ./ldso/ldso/bfin/dl-inlines.h:31
> Cannot access memory at address 0x16ffc78
First, you should print the stack pointer, and cat /proc/$pid/map while
the process is stopped inside gdb, to see if you would not have a stack
overflow.
If not, recompile xenomai with --enable-debug, try and put a breakpoint
on the function xeno_sigshadow_handler. If you hit the breakpoint, try
and execute the function step by step, looking whether a pointer could
be invalid.
--
Gilles.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] NULL pointer access on bfin when linking with xenomai and pthread
2011-01-25 9:52 ` Gilles Chanteperdrix
@ 2011-01-25 10:15 ` Kolja Waschk
2011-01-25 11:22 ` Kolja Waschk
2011-01-25 11:32 ` Kolja Waschk
2 siblings, 0 replies; 11+ messages in thread
From: Kolja Waschk @ 2011-01-25 10:15 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
Hi,
> First, you should print the stack pointer, and cat /proc/$pid/map while
> the process is stopped inside gdb, to see if you would not have a stack
> overflow.
(gdb) info registers
...
p5 0x15e8b40 0x15e8b40
sp 0x13bd330 0x13bd330
fp 0x13bd340 0x13bd340
...
cat /proc/$pid/maps says
...
013a0000-013c0000 rw-p 00000000 00:00 0 [stack]
...
So I assume the SP is okay
> If not, recompile xenomai with --enable-debug, try and put a breakpoint
I'll do. For now thanks for the good tips up to here!
Kolja
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] NULL pointer access on bfin when linking with xenomai and pthread
2011-01-25 11:22 ` Kolja Waschk
@ 2011-01-25 11:21 ` Gilles Chanteperdrix
2011-01-25 12:37 ` Kolja Waschk
0 siblings, 1 reply; 11+ messages in thread
From: Gilles Chanteperdrix @ 2011-01-25 11:21 UTC (permalink / raw)
To: xenoka09; +Cc: xenomai
Kolja Waschk wrote:
> Hi,
>
>> If not, recompile xenomai with --enable-debug, try and put a breakpoint
>> on the function xeno_sigshadow_handler. If you hit the breakpoint, try
>> and execute the function step by step, looking whether a pointer could
>
> The breakpoint isn't hit...
>
> With following setup:
>
> # continue to "_dl_get_ready_to_run" to be able to load symbols
> break *($pc - 0xC60 + 0x41B6)
> cont
>
> sharedlibrary
> break xeno_sigshadow_handler
> break main
>
> ... the output is as quoted below. Should xeno_sigshadow_handler be called as an
> immediate result of xeno_sigshadow_install? If I break on xeno_sigshadow_install,
> the fault doesn't occur and execution continues without problems to main()...
Well, I am not sure about this. A signal should be received as a result
of the call to __wrap_pthread_setschedparam, but the application should
receive it well before the handler is installed. So, this signal is
probably ignored by default, which somehow makes the thing work.
Anyway, what you can try to do is to mask the SIGSHADOW signal with
pthread_sigmask around the call to sigaction, in order to avoid whatever
race seems to happen with the libpthread library.
--
Gilles.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] NULL pointer access on bfin when linking with xenomai and pthread
2011-01-25 9:52 ` Gilles Chanteperdrix
2011-01-25 10:15 ` Kolja Waschk
@ 2011-01-25 11:22 ` Kolja Waschk
2011-01-25 11:21 ` Gilles Chanteperdrix
2011-01-25 11:32 ` Kolja Waschk
2 siblings, 1 reply; 11+ messages in thread
From: Kolja Waschk @ 2011-01-25 11:22 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
Hi,
> If not, recompile xenomai with --enable-debug, try and put a breakpoint
> on the function xeno_sigshadow_handler. If you hit the breakpoint, try
> and execute the function step by step, looking whether a pointer could
The breakpoint isn't hit...
With following setup:
# continue to "_dl_get_ready_to_run" to be able to load symbols
break *($pc - 0xC60 + 0x41B6)
cont
sharedlibrary
break xeno_sigshadow_handler
break main
... the output is as quoted below. Should xeno_sigshadow_handler be called as an
immediate result of xeno_sigshadow_install? If I break on xeno_sigshadow_install,
the fault doesn't occur and execution continues without problems to main()...
Breakpoint 1, 0x017ac1b6 in ?? ()
Breakpoint 2 at 0x1745d58: file ../../../../xenomai-2.5.5.2/src/skins/common/sigshadow.c, line 41.
Breakpoint 3 at 0x161f646: file a.c, line 3.
(gdb) cont
Continuing.
[New Thread 329]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 329]
0x01796f10 in pthread_sighandler_rt (signo=28, si=0x177d3ac, uc=0x177d42c) at libpthread/linuxthreads.old/signals.c:127
127 libpthread/linuxthreads.old/signals.c: No such file or directory.
in libpthread/linuxthreads.old/signals.c
(gdb) bt
#0 0x01796f10 in pthread_sighandler_rt (signo=28, si=0x177d3ac, uc=0x177d42c)
at libpthread/linuxthreads.old/signals.c:127
#1 <signal handler called>
#2 0x017ccf1e in __syscall_rt_sigaction (signum=<value optimized out>, act=0x177d5b8, oldact=0x177d52c, size=8)
at libc/sysdeps/linux/common/__syscall_rt_sigaction.c:17
#3 0x017ef482 in __libc_sigaction (sig=28, act=0x177d670, oact=0x159a95c) at libc/signal/sigaction.c:58
#4 0x01796fba in *___GI_sigaction (sig=28, act=0x177d720, oact=0x159a95c) at libpthread/linuxthreads.old/signals.c:163
#5 0x01745c9a in xeno_sigshadow_install () at ../../../../xenomai-2.5.5.2/src/skins/common/sigshadow.c:70
.... as before
Kolja
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] NULL pointer access on bfin when linking with xenomai and pthread
2011-01-25 9:52 ` Gilles Chanteperdrix
2011-01-25 10:15 ` Kolja Waschk
2011-01-25 11:22 ` Kolja Waschk
@ 2011-01-25 11:32 ` Kolja Waschk
2 siblings, 0 replies; 11+ messages in thread
From: Kolja Waschk @ 2011-01-25 11:32 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
> If not, recompile xenomai with --enable-debug, try and put a breakpoint
> on the function xeno_sigshadow_handler. If you hit the breakpoint, try
> and execute the function step by step, looking whether a pointer could
I can only make it halt at pthread_sighandler_rt. To me it seems the attempt
to call the user handler fails, not the call itself
Breakpoint 2, pthread_sighandler_rt (signo=28, si=0x16bd3ac, uc=0x16bd42c) at libpthread/linuxthreads.old/signals.c:112
112 {
(gdb) next
113 pthread_descr self = thread_self();
(gdb) next
117 if (THREAD_GETMEM(self, p_sigwaiting)) {
(gdb) next
124 in_sighandler = THREAD_GETMEM(self, p_in_sighandler);
(gdb) next
125 if (in_sighandler == NULL)
(gdb) next
126 THREAD_SETMEM(self, p_in_sighandler, CURRENT_STACK_FRAME);
(gdb) next
127 sighandler[signo].rt(signo, si, uc);
(gdb) print signo
$1 = 28
(gdb) print si
$2 = (struct siginfo *) 0x16bd3ac
(gdb) print *si
$4 = {si_signo = 28, si_errno = 0, si_code = -1, _sifields = {_pad = {0, 0, 2, 0 <repeats 26 times>}, _kill = {
si_pid = 0, si_uid = 0}, _timer = {si_tid = 0, si_overrun = 0, si_sigval = {sival_int = 2, sival_ptr = 0x2}},
_rt = {si_pid = 0, si_uid = 0, si_sigval = {sival_int = 2, sival_ptr = 0x2}}, _sigchld = {si_pid = 0, si_uid = 0,
si_status = 2, si_utime = 0, si_stime = 0}, _sigfault = {si_addr = 0x0}, _sigpoll = {si_band = 0, si_fd = 0}}}
(gdb) print uc
$3 = (struct ucontext *) 0x16bd42c
(gdb) print *uc
$5 = {uc_flags = 0, uc_link = 0x0, uc_stack = {ss_sp = 0x0, ss_flags = 2, ss_size = 0}, uc_mcontext = {gregs = {0,
23844280, 23844140, 8, 23849124, 28, 23598632, 23844280, 174, 31, 23844140, 23598632, 23640412, 23844464, 23844100,
0, 0, 0, 0, 33562689, 25097346, 24956702, 24956702, 23844112, 23844596, 1, 2, 6, 180, 1, 6146, 91, 0, 0, 0, 0, 311,
192, 2147479552, 0, 0, 1023, 25035906, 24737144, 25035907, 24737185, 393216}}, uc_sigmask = {__val = {2147483648,
0, 0, 0, 0, 23844420, 25097346, 23844280, 0, 0, 0, 8, 0, 0, 23139796, 0 <repeats 17 times>}}}
(gdb) print sighandler[signo]
$2 = {old = <error reading variable>, rt = <error reading variable>}
(gdb) print sighandler
$3 = {{old = <error reading variable>, rt = <error reading variable>} <repeats 24 times>, {
old = @0x204a94: 0x15c965c <xeno_handle_mlock_alert>, rt = @0x204a94: 0x15c965c <xeno_handle_mlock_alert>}, {
old = <error reading variable>, rt = <error reading variable>} <repeats 40 times>}
(gdb) step
Program received signal SIGSEGV, Segmentation fault.
Kolja
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] NULL pointer access on bfin when linking with xenomai and pthread
2011-01-25 11:21 ` Gilles Chanteperdrix
@ 2011-01-25 12:37 ` Kolja Waschk
0 siblings, 0 replies; 11+ messages in thread
From: Kolja Waschk @ 2011-01-25 12:37 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
> Anyway, what you can try to do is to mask the SIGSHADOW signal with
> pthread_sigmask around the call to sigaction, in order to avoid whatever
> race seems to happen with the libpthread library.
You're right: after doing so the problem doesn't occur anymore.
--- xenomai-2.5.5.2/src/skins/common/sigshadow.c.orig 2011-01-25 13:25:01.000000000 +0100
+++ xenomai-2.5.5.2/src/skins/common/sigshadow.c 2011-01-25 13:25:57.000000000 +0100
@@ -62,6 +62,12 @@
void xeno_sigshadow_install(void)
{
struct sigaction new_sigshadow_action;
+ sigset_t saved_sigset;
+ sigset_t mask_sigset;
+
+ sigemptyset(&mask_sigset);
+ sigaddset(&mask_sigset, SIGSHADOW);
+ pthread_sigmask(SIG_BLOCK, &mask_sigset, &saved_sigset);
new_sigshadow_action.sa_flags = SA_SIGINFO | SA_RESTART;
new_sigshadow_action.sa_sigaction = xeno_sigshadow_handler;
@@ -71,6 +77,8 @@
&new_sigshadow_action, &xeno_saved_sigshadow_action);
if (!(xeno_saved_sigshadow_action.sa_flags & SA_NODEFER))
sigaddset(&xeno_saved_sigshadow_action.sa_mask, SIGSHADOW);
+
+ pthread_sigmask(SIG_SETMASK, &saved_sigset, NULL);
}
void xeno_sigshadow_install_once(void)
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-01-25 12:37 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-25 9:31 [Xenomai-help] NULL pointer access on bfin when linking with xenomai and pthread Kolja Waschk
2011-01-25 9:28 ` Gilles Chanteperdrix
2011-01-25 9:46 ` Kolja Waschk
2011-01-25 9:48 ` Kolja Waschk
2011-01-25 9:50 ` Kolja Waschk
2011-01-25 9:52 ` Gilles Chanteperdrix
2011-01-25 10:15 ` Kolja Waschk
2011-01-25 11:22 ` Kolja Waschk
2011-01-25 11:21 ` Gilles Chanteperdrix
2011-01-25 12:37 ` Kolja Waschk
2011-01-25 11:32 ` Kolja Waschk
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.