ARM porters: can you shed any light on this? If I compile libcap-ng0 on armel, then run "make check", the segfault described in the bug appears:
> make[3]: Entering directory `/home/smcv/bugsquash/libcap-ng-0.6.1/src/test'
> Doing basic bit tests...
> /bin/bash: line 5: 25105 Segmentation fault ${dir}$tst
On further investigation it appears that whenever &m.something is passed to
memset, I get the segfault. In unmodified source, I get:
> ./libtool --mode=execute gdb ./src/test/lib_test
> GNU gdb (GDB) 6.8.50.20090628-cvs-debian
> ...
> (gdb) run
> Starting program:
> /home/smcv/bugsquash/libcap-ng-0.6.1/src/test/.libs/lt-lib_test
> Doing basic bit tests...
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x40027630 in init () at cap-ng.c:139
> 139 memset(&m.hdr, 0, sizeof(m.hdr));
> (gdb) thread apply all bt full
>
> Thread 1 (process 31033):
> #0 0x40027630 in init () at cap-ng.c:139
> No locals.
> #1 0x40027ad4 in capng_clear (set=CAPNG_SELECT_BOTH) at cap-ng.c:159
> No locals.
> #2 0x0000893c in main () at lib_test.c:37
> rc = <value optimized out>
> i = <value optimized out>
> last = <value optimized out>
> text = <value optimized out>
> saved = <value optimized out>
If I patch out the calls to memset(&m.hdr, ...) and memset(&m.data, ...)
in init(), replacing them with a single call to memset(&m, 0, sizeof(m)),
then the segfault is delayed until a later call to memset(&m.data, ...).
This ld warning seen during the build seems likely to be related:
> gcc -shared .libs/cap-ng.o .libs/lookup_table.o -Wl,-z -Wl,relro -Wl,-z
> -Wl,defs -Wl,-soname -Wl,libcap-ng.so.0 -o .libs/libcap-ng.so.0.0.0
> /usr/bin/ld: .libs/cap-ng.o(.text+0x810): R_ARM_GOTOFF32 used with TLS symbol
> m
> /usr/bin/ld: .libs/cap-ng.o(.text+0xc1c): R_ARM_GOTOFF32 used with TLS symbol
> m
Any ideas?
Simon
signature.asc
Description: Digital signature
