I write a script to change the hostapd mode ap to sta and sta to ap which lasts running for serval hours and the process of netifd hanged up.
cat proc/id/maps
0400000-0041f000 r-xp 00000000 1f:06 1176 /sbin/netifd
0042f000-00430000 rw-p 0001f000 1f:06 1176 /sbin/netifd
**00430000-00476000 rwxp 00000000 00:00 0 [heap]**
772af000-7730a000 r-xp 00000000 1f:06 144 /lib/libuClibc-0.9.33.2.so
00400000-0041f000 r-xp 00000000 1f:06 1176 /sbin/netifd
0042f000-00430000 rw-p 0001f000 1f:06 1176 /sbin/netifd
**00430000-00477000 rwxp 00000000 00:00 0 [heap]**
772af000-7730a000 r-xp 00000000 1f:06 144 /lib/libuClibc-0.9.33.2.so
I find that heap of the process is constantly rising.
could not fix it.
Change mode of ap, hostapd will teardown and setup.
and the process heap of netifd is rising.
finally it cause
netifd/wireless.c
wireless_device_run_handler()->netifd_start_process()
netifd/main.c
netifd_start_process()->
if ((pid = fork()) < 0)
goto error;
fork fail because
log
netifd_start_process>>>>>>>>after fork create
error on triggering 12: Cannot allocate memory
(netifd heap use more and more memories with the script running)
part of the script
uci set wireless.#wifi-iface[$1].mode="$apmode"
uci commit wireless
/sbin/wifi reload
Related
I'm upgrading to Ruby 2.5.1 and when a unicorn worker crashed during testing, I got a ton of output that I'm not sure how to interpret.
Does anyone know what each of these columns means? I think if I understood this better, I'd be able to find what caused the issue, as the output is rather larger than what I pasted here.
* Process memory map:
55d388ebb000-55d3891db000 r-xp 00000000 ca:01 4623622 /opt/ruby-2.5.1/bin/ruby
55d3893db000-55d3893e0000 r--p 00320000 ca:01 4623622 /opt/ruby-2.5.1/bin/ruby
55d3893e0000-55d3893e1000 rw-p 00325000 ca:01 4623622 /opt/ruby-2.5.1/bin/ruby
55d3893e1000-55d3893f2000 rw-p 00000000 00:00 0
55d38b066000-55d38bdf9000 rw-p 00000000 00:00 0 [heap]
55d38bdf9000-55d38d1a9000 rw-p 00000000 00:00 0 [heap]
55d38d1a9000-55d3a1258000 rw-p 00000000 00:00 0 [heap]
7f1bcc000000-7f1bcc021000 rw-p 00000000 00:00 0
7f1bcc021000-7f1bd0000000 ---p 00000000 00:00 0
7f1bd0e68000-7f1bd1031000 r--s 00000000 ca:01 13016
/lib/x86_64-linux-gnu/libc-2.23.so
....
I am trying to compile with -msecure-plt, and although compilation is completing just fine, when looking at the memory maps it doesn't look like the flag is actually doing anything. I am assuming it is not doing anything because the got and plt sections are both still in RWXP segements.
Dump of assembler code for function main:
0x1000061c <+0>: stwu r1,-16(r1)
0x10000620 <+4>: mflr r0
0x10000624 <+8>: stw r0,20(r1)
0x10000628 <+12>: stw r31,12(r1)
0x1000062c <+16>: mr r31,r1
0x10000630 <+20>: bl 0x1001096c <libfunc#plt>
0x10000634 <+24>: mr r10,r3
0x10000638 <+28>: lis r9,4096
0x1000063c <+32>: addi r3,r9,2048
0x10000640 <+36>: mr r4,r10
0x10000644 <+40>: crclr 4*cr1+eq
0x10000648 <+44>: bl 0x10010964 <printf#plt>
=> 0x1000064c <+48>: li r9,1
0x10000650 <+52>: mr r3,r9
0x10000654 <+56>: addi r11,r31,16
0x10000658 <+60>: lwz r0,4(r11)
0x1000065c <+64>: mtlr r0
0x10000660 <+68>: lwz r31,-4(r11)
0x10000664 <+72>: mr r1,r11
0x10000668 <+76>: blr
with /proc/<pid>/maps showing a memory map of
00100000-00103000 r-xp 00000000 00:00 0 [vdso]
0fe40000-0ffb8000 r-xp 00000000 00:01 6285 /lib/libc-2.22.so
0ffb8000-0ffc7000 ---p 00178000 00:01 6285 /lib/libc-2.22.so
0ffc7000-0ffc9000 r--p 00177000 00:01 6285 /lib/libc-2.22.so
0ffc9000-0ffcd000 rwxp 00179000 00:01 6285 /lib/libc-2.22.so
0ffcd000-0ffcf000 rwxp 00000000 00:00 0
0ffdf000-0ffe0000 r-xp 00000000 00:01 5928 /lib/libmaintest.so
0ffe0000-0ffef000 ---p 00001000 00:01 5928 /lib/libmaintest.so
0ffef000-0fff0000 rwxp 00000000 00:01 5928 /lib/libmaintest.so
10000000-10001000 r-xp 00000000 00:01 5934 /root/main
10010000-10011000 rwxp 00000000 00:01 5934 /root/main
b7860000-b7882000 r-xp 00000000 00:01 6240 /lib/ld-2.22.so
b7890000-b7892000 rw-p 00000000 00:00 0
b7892000-b7893000 r--p 00022000 00:01 6240 /lib/ld-2.22.so
b7893000-b7895000 rwxp 00023000 00:01 6240 /lib/ld-2.22.so
bff1a000-bff3b000 rw-p 00000000 00:00 0 [stack]
which sticks both of the plot jumps right into the middle of a rwx section. Am I misinterpreting this information?
I think that might be a kernel limitation: see e.g. https://lkml.org/lkml/2016/8/8/354 - it looks like the kernel maps things in ways you wouldn't expect for what I understand to be historical reasons.
It may be changing soon, given that the patch above was sent yesterday.
Depending on your version of gcc, the -msecure-plt flag might be ignored if any libraries you linked to were not also compiled with -msecure-plt (including glibc). See this.
i developed a static library, and a test application to call its
functions.
Now, when i am executing the test application, it was able to get in to
the function and calculate the required values, but when the return is
called it is giving stack smash error
./test_app
USB Handle opened SUCCESSFULLY
*** stack smashing detected ***: /home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7ffff7b25807]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x0)[0x7ffff7b257d0]
/home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app[0x4008ec]
/home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app[0x4006ed]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7ffff7a3c76d]
/home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app[0x400619]
======= Memory map: ========
00400000-00402000 r-xp 00000000 08:08 1186 /home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app
00601000-00602000 r--p 00001000 08:08 1186 /home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app
00602000-00603000 rw-p 00002000 08:08 1186 /home/avinay/Documents/iProbe/Experiments/iProbe_linux_lib/test_app
00603000-00624000 rw-p 00000000 00:00 0 [heap]
7ffff7805000-7ffff781a000 r-xp 00000000 08:05 658720 /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff781a000-7ffff7a19000 ---p 00015000 08:05 658720 /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7a19000-7ffff7a1a000 r--p 00014000 08:05 658720 /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7a1a000-7ffff7a1b000 rw-p 00015000 08:05 658720 /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7a1b000-7ffff7bd0000 r-xp 00000000 08:05 658699 /lib/x86_64-linux-gnu/libc-2.15.so
7ffff7bd0000-7ffff7dcf000 ---p 001b5000 08:05 658699 /lib/x86_64-linux-gnu/libc-2.15.so
7ffff7dcf000-7ffff7dd3000 r--p 001b4000 08:05 658699 /lib/x86_64-linux-gnu/libc-2.15.so
7ffff7dd3000-7ffff7dd5000 rw-p 001b8000 08:05 658699 /lib/x86_64-linux-gnu/libc-2.15.so
7ffff7dd5000-7ffff7dda000 rw-p 00000000 00:00 0
7ffff7dda000-7ffff7dfc000 r-xp 00000000 08:05 658679 /lib/x86_64-linux-gnu/ld-2.15.so
7ffff7fdd000-7ffff7fe0000 rw-p 00000000 00:00 0
7ffff7ff6000-7ffff7ffb000 rw-p 00000000 00:00 0
7ffff7ffb000-7ffff7ffc000 r-xp 00000000 00:00 0 [vdso]
7ffff7ffc000-7ffff7ffd000 r--p 00022000 08:05 658679 /lib/x86_64-linux-gnu/ld-2.15.so
7ffff7ffd000-7ffff7fff000 rw-p 00023000 08:05 658679 /lib/x86_64-linux-gnu/ld-2.15.so
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0 [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Here is the test application
#include <stdio.h>
#include "leapfrog.h"
void main()
{
unsigned int mid=0x0;
USB_Init();
mid = Read_MID();
printf("\n mid = 0x%x\n",mid);
USB_Deinit();
return;
}
The above was the test application and it was referencing this function in the library
uint16 Read_MID(void)
{
int8 buf[8]={0};
uint16 mid;
//Read Vendor id
buf[0] = 0xFE;
msp_write(0x41,buf,1);
msp_read(0x41,buf,2);
mid = buf[0];
mid <<= 8;
mid |= buf[1];
return mid;
}
till the "mid" calculation i could get the correct values. it is reaching till the end while debugging with insight debugger. just after "}" in the console i see the stack smash error.
what might be the cause of the stack smash.
Thank you for time and patience.
I resolved it by adding more array space.
int8 buf[8]={0};
i made it as
int8 buf[10]={0};
my question is not relative to the error itself (I know what is the reason for it).
I would instead like to know how to read this dump (meaning of the fields, flags and so on), where it is produced (glibc, or gcc libraries) and how I can infer what's wrong from it at a higher level (e.g. some tool that might find this output useful).
*** glibc detected *** python: double free or corruption (fasttop): 0x0000000006c4eb90 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7f6c3a0a1b96]
/usr/lib/nvidia-current-updates/tls/libnvidia-tls.so.304.88(+0x1cc1)[0x7f6c2e544cc1]
======= Memory map: ========
00400000-00401000 r-xp 00000000 08:07 2238049 /build/bin/python
00600000-00601000 r--p 00000000 08:07 2238049 /build/bin/python
00601000-00602000 rw-p 00001000 08:07 2238049 /build/bin/python
00954000-07625000 rw-p 00000000 00:00 0 [heap]
40c14000-40c92000 rw-p 00000000 00:00 0
7f6c04000000-7f6c041bc000 rw-p 00000000 00:00 0
7f6c041bc000-7f6c08000000 ---p 00000000 00:00 0
7f6c08000000-7f6c081bc000 rw-p 00000000 00:00 0
7f6c081bc000-7f6c0c000000 ---p 00000000 00:00 0
7f6c0c000000-7f6c0c1bc000 rw-p 00000000 00:00 0
7f6c0c1bc000-7f6c10000000 ---p 00000000 00:00 0
7f6c14000000-7f6c14021000 rw-p 00000000 00:00 0
7f6c14021000-7f6c18000000 ---p 00000000 00:00 0
7f6c1ab5a000-7f6c1ab5b000 ---p 00000000 00:00 0
7f6c1ab5b000-7f6c1af5b000 rwxp 00000000 00:00 0
7f6c1af5b000-7f6c1af5c000 ---p 00000000 00:00 0
7f6c1af5c000-7f6c1b35c000 rwxp 00000000 00:00 0
7f6c1b35c000-7f6c1b35d000 ---p 00000000 00:00 0
7f6c1b35d000-7f6c1b75d000 rwxp 00000000 00:00 0
7f6c1b75d000-7f6c1b767000 r-xp 00000000 08:05 1314563 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f6c1b767000-7f6c1b967000 ---p 0000a000 08:05 1314563 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f6c1b967000-7f6c1b968000 r--p 0000a000 08:05 1314563 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f6c1b968000-7f6c1b969000 rw-p 0000b000 08:05 1314563 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f6c1b969000-7f6c1b980000 r-xp 00000000 08:05 1314576 /lib/x86_64-linux-gnu/libnsl-2.15.so
The man page for proc has the answer. The memory map output format is given in the entry for /proc/[pid]/maps.
The short summary is going across the columns it is: memory range, permissions, offset, device (major:minor), inode, and pathname.
my program was compiled properly with "make" on Ubuntu 11.04, but when i run it, it give error.
is this a bug on Ubuntu? or this is difference in variable types between compilers?
pls help me
*** buffer overflow detected ***: src/trilearn_player terminated
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x50)[0x9cd0a0]
/lib/i386-linux-gnu/libc.so.6(+0xe5f7a)[0x9cbf7a]
/lib/i386-linux-gnu/libc.so.6(__strcpy_chk+0x3f)[0x9cb30f]
src/trilearn_player[0x804dd24]
src/trilearn_player[0x808b2d5]
src/trilearn_player[0x80920cf]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x8fce37]
src/trilearn_player[0x804a421]
======= Memory map: ========
00139000-0015d000 r-xp 00000000 08:0b 6060 /lib/i386-linux-gnu/libm-2.13.so
0015d000-0015e000 r--p 00023000 08:0b 6060 /lib/i386-linux-gnu/libm-2.13.so
0015e000-0015f000 rw-p 00024000 08:0b 6060 /lib/i386-linux-gnu/libm-2.13.so
001b4000-001b5000 r-xp 00000000 00:00 0 [vdso]
00488000-0049d000 r-xp 00000000 08:0b 6831 /lib/i386-linux-gnu/libpthread-2.13.so
0049d000-0049e000 r--p 00015000 08:0b 6831 /lib/i386-linux-gnu/libpthread-2.13.so
0049e000-0049f000 rw-p 00016000 08:0b 6831 /lib/i386-linux-gnu/libpthread-2.13.so
0049f000-004a1000 rw-p 00000000 00:00 0
00558000-00637000 r-xp 00000000 08:0b 134145
00637000-0063b000 r--p 000de000 08:0b 134145 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.14
0063b000-0063c000 rw-p 000e2000 08:0b 134145 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.14
0063c000-00643000 rw-p 00000000 00:00 0
0087b000-00885000 r-xp 00000000 08:0b 6826 /lib/i386-linux-gnu/libnss_files-2.13.so
00885000-00886000 r--p 00009000 08:0b 6826 /lib/i386-linux-gnu/libnss_files-2.13.so
00886000-00887000 rw-p 0000a000 08:0b 6826 /lib/i386-linux-gnu/libnss_files-2.13.so
008e6000-00a42000 r-xp 00000000 08:0b 5792 /lib/i386-linux-gnu/libc-2.13.so
/lib/i386-linux-gnu/libc.so.6(__strcpy_chk+0x3f)[0x9cb30f]
Looks like you copy too many chars to the destination.