* [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: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
* 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 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 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 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
* 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
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.