Hi all,
I am developing openwrt on ARMv7, and the "vfork" function in popen sometimes
cause segfault.
I have traced with gdb, but I can't find the root cause.
However, I doubt the problem is related with uClibc.
The function call chain in my test is as follows:
Netifd (main.c:335) --> netifd_init_script_handlers (handler.c:133) -->
proto_shell_add_handler (handler.c:93) --> popen (libc/stdio/popen.c:72) -->
vfork
(libpthread/nptl/sysdeps/unix/sysv/linux/arm/../../../../../../../libc/sysdeps/linux/arm/vfork.S:71)
--> SAVE_PID (and segfault here)
And following is my gdb debug trace flow.
(gdb) target remote 192.168.1.1
192.168.1.1: No such file or directory.
(gdb) target remote 192.168.1.1:1234
Remote debugging using 192.168.1.1:1234
Reading symbols from
/home/qi/work/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_uClibc-0.9.33.2_eabi/root-mmp/lib/ld-uClibc.so.0...(no
debugging symbols found)...done.
Loaded symbols for
/home/qi/work/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_uClibc-0.9.33.2_eabi/root-mmp/lib/ld-uClibc.so.0
0xb6ff1e38 in _start ()
from
/home/qi/work/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_uClibc-0.9.33.2_eabi/root-mmp/lib/ld-uClibc.so.0
......
step or next and continue operations, until I get into popen.
......
(gdb) where
#0 0xb6f6a960 in popen (command=0x6 <Address 0x6 out of bounds>,
command@entry=0xbefffc68 "./3g.sh '' dump",
modes=modes@entry=0x1c37d "r") at libc/stdio/popen.c:72
#1 0x0000b544 in netifd_parse_script_handler (name=0x37688 "./3g.sh",
cb=cb@entry=0x113ac <proto_shell_add_handler>)
at
/home/qi/work/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_uClibc-0.9.33.2_eabi/netifd-2014-05-10/handler.c:93
#2 0x0000b74c in netifd_init_script_handlers (dir_fd=<optimized out>,
cb=0x113ac <proto_shell_add_handler>)
at
/home/qi/work/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_uClibc-0.9.33.2_eabi/netifd-2014-05-10/handler.c:133
#3 0x0000a8c4 in main (argc=1, argv=<optimized out>)
at
/home/qi/work/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_uClibc-0.9.33.2_eabi/netifd-2014-05-10/main.c:335
......
"next" to vfork, and then the segment comes in following stepi.
......
(gdb) next
90 if ((pid = vfork()) == 0) { /* Child of vfork... */
(gdb) stepi
vfork () at
libpthread/nptl/sysdeps/unix/sysv/linux/arm/../../../../../../../libc/sysdeps/linux/arm/vfork.S:71
71 SAVE_PID
(gdb) l
66
67 #else
68 __vfork:
69
70 #ifdef __NR_vfork
71 SAVE_PID
72 DO_CALL (vfork)
73 RESTORE_PID
74 cmn r0, #4096
75 IT(t, cc)
(gdb) disassemble
Dump of assembler code for function vfork:
=> 0xb6f7bf50 <+0>: push {lr} ; (str lr, [sp, #-4]!)
0xb6f7bf54 <+4>: mvn r0, #61440 ; 0xf000
0xb6f7bf58 <+8>: mov lr, pc
0xb6f7bf5c <+12>: sub pc, r0, #31
0xb6f7bf60 <+16>: pop {lr} ; (ldr lr, [sp], #4)
0xb6f7bf64 <+20>: mov r2, r0
(gdb) stepi
0xb6f7bf54 71 SAVE_PID
(gdb) disassemble
Dump of assembler code for function vfork:
0xb6f7bf50 <+0>: push {lr} ; (str lr, [sp, #-4]!)
=> 0xb6f7bf54 <+4>: mvn r0, #61440 ; 0xf000
0xb6f7bf58 <+8>: mov lr, pc
0xb6f7bf5c <+12>: sub pc, r0, #31
0xb6f7bf60 <+16>: pop {lr} ; (ldr lr, [sp], #4)
0xb6f7bf64 <+20>: mov r2, r0
0xb6f7bf68 <+24>: ldr r3, [r2, #-964] ; 0x3c4
(gdb) stepi
0xb6f7bf58 71 SAVE_PID
(gdb) disassemble
Dump of assembler code for function vfork:
0xb6f7bf50 <+0>: push {lr} ; (str lr, [sp, #-4]!)
0xb6f7bf54 <+4>: mvn r0, #61440 ; 0xf000
=> 0xb6f7bf58 <+8>: mov lr, pc
0xb6f7bf5c <+12>: sub pc, r0, #31
0xb6f7bf60 <+16>: pop {lr} ; (ldr lr, [sp], #4)
0xb6f7bf64 <+20>: mov r2, r0
0xb6f7bf68 <+24>: ldr r3, [r2, #-964] ; 0x3c4
(gdb) stepi
0xb6f7bf5c 71 SAVE_PID
(gdb) disassemble
Dump of assembler code for function vfork:
0xb6f7bf50 <+0>: push {lr} ; (str lr, [sp, #-4]!)
0xb6f7bf54 <+4>: mvn r0, #61440 ; 0xf000
0xb6f7bf58 <+8>: mov lr, pc
=> 0xb6f7bf5c <+12>: sub pc, r0, #31
0xb6f7bf60 <+16>: pop {lr} ; (ldr lr, [sp], #4)
0xb6f7bf64 <+20>: mov r2, r0
0xb6f7bf68 <+24>: ldr r3, [r2, #-964] ; 0x3c4
(gdb) stepi
Program received signal SIGSEGV, Segmentation fault.
0xffff0fe0 in ?? ()
Has anyone encountered with this problem? any sort of help will be much
appreaciated.
Thanks.
Qi
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
