Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VSZ raised 8M after every control time, is it normal? #69

Open
robot0518 opened this issue Mar 29, 2017 · 9 comments
Open

VSZ raised 8M after every control time, is it normal? #69

robot0518 opened this issue Mar 29, 2017 · 9 comments

Comments

@robot0518
Copy link

Hello.
I ran it on an openwrt, and with cmd top I found that VSZ raised high, every time it increased 8M,
is this a problem?

Greeting

@etwmc
Copy link
Owner

etwmc commented Mar 30, 2017

From what I can gather in Instruments for a short period of time, it seems that controlling accessory doesn't cause any leak. The leak on OSX w/ OpenSSL seems to focus on the session pairing. My OpenWRT routers only seeing 2MB per command (then again, mine is mostly binary switches)
So, I guess the problem maybe be the underlying OpenSSL? I will check once I got my Linux platform back in order

@etwmc
Copy link
Owner

etwmc commented Mar 30, 2017

But in the meantime, I don't think it will be a big matter. In order to fill your VM, it would probably takes awhile?

@robot0518
Copy link
Author

my openwrt meminfo:
cat /proc/meminfo
MemTotal: 60784 kB
MemFree: 16968 kB
Buffers: 6652 kB
Cached: 14496 kB
SwapCached: 0 kB
Active: 19660 kB
Inactive: 9712 kB
Active(anon): 8276 kB
Inactive(anon): 64 kB
Active(file): 11384 kB
Inactive(file): 9648 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 8256 kB
Mapped: 4760 kB
Shmem: 116 kB
Slab: 7668 kB
SReclaimable: 2180 kB
SUnreclaim: 5488 kB
KernelStack: 408 kB
PageTables: 372 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 30392 kB
Committed_AS: 32680 kB
VmallocTotal: 1048372 kB
VmallocUsed: 5336 kB
VmallocChunk: 1029616 kB
only have small memory

@etwmc
Copy link
Owner

etwmc commented Mar 30, 2017

Consider your system not having swap, wouldn't 4 more instruction and your system crashed already?
I think some resource is pre-allocated by pthread, hence high VSZ (virtual address). I will see if different compiler would help. (Like I said, I don't have my Linux box up yet. I think it's still in my suitcase somewhere. 😅)

@etwmc
Copy link
Owner

etwmc commented Mar 30, 2017

Can you try putting pthread_detach(pthread_self()); on the line 273 of PHKNetworkIP.cpp?
I wonder if it's just pthread doesn't clean up on openwrt.

@robot0518
Copy link
Author

robot0518 commented Mar 30, 2017

it doesn't work,
Mem: 45676K used, 15108K free, 0K shrd, 6708K buff, 14496K cached
CPU: 2% usr 4% sys 0% nic 90% idle 0% io 0% irq 0% sirq
Load average: 0.07 0.12 0.13 2/56 28944
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
1805 1208 root S 7952 13% 1% {SHGuarder.sh} /bin/sh /root/bin/SHGu
28796 15832 root S 697m1171% 1% /home/homebridge/PHK
27246 1 root S 24160 40% 0% ./teleport
15247 15232 root R 3648 6% 0% top
1 0 root S 2812 5% 0% /sbin/procd
110 2 root SW 0 0% 0% [kworker/0:1]
186 2 root RW 0 0% 0% [mmcqd/0]
1391 1 root S 3812 6% 0% /usr/sbin/ntpd -n -p 0.openwrt.pool.n
1171 1 root S 3648 6% 0% /usr/sbin/telnetd -F -l /bin/login.sh
15419 1171 root S 3648 6% 0% -ash
15832 1171 root S 3648 6% 0% -ash
15232 1171 root S 3648 6% 0% -ash
32302 1 avahi S 3588 6% 0% avahi-daemon: running [CCUW.local]
1154 1 root S 3584 6% 0% /usr/sbin/crond -f -c /etc/crontabs -
28736 10410 root S 3536 6% 0% {exe} ftpd -w /home
10410 1 root S 3472 6% 0% {exe} tcpsvd -vE 0.0.0.0 21 ftpd -w /
1208 1 root S 3472 6% 0% {AutoRun.sh} /bin/sh /bin/AutoRun.sh
22608 22503 root S 3472 6% 0% udhcpc -p /var/run/udhcpc-apcli0.pid
22611 22503 root S 3472 6% 0% udhcpc -p /var/run/udhcpc-apcli0.pid
28936 1805 root S 3340 5% 0% sleep 3

I found it increased because the code in PHKAccessory.cpp line 553-568, if i make the updateNotify = true , the VSZ wouldn't raise, but I know it should not be so

@etwmc
Copy link
Owner

etwmc commented Apr 7, 2017

Add the pthread_detach() at the beginning of broadcastMessage and connectionLoop, then recompile.
void broadcastMessage(void *sender, char *resultData, size_t resultLen) {
pthread_detach(pthread_self());
...

and also
void *connectionLoop(void *threadInfo) {
pthread_detach(pthread_self());

It works on Ubuntu (basically halves the amount since the program gets memory only if it's needed, but virutal page size = sum of all thread theortical stack size)
I'm going to look for actual memory usage to shrink the size, but it will take a while

@etwmc
Copy link
Owner

etwmc commented Apr 7, 2017

I just take a look at the meminfo (really busy this week):
VmallocTotal: 1048372 kB
VmallocUsed: 5336 kB
VmallocUsed is the actual page used, which is 5MB, so the underlining memory used is below 5MB (again, pthread_detach would help)
So, unless the memory space runs out (which is solved by pthread_detach), it should be okay

I have one running in a house in Hong Kong, and under the optimized version it takes about 13MB in 21% of virtual memory space. I know it's not in the KB boundary, but it does not grow, and most of the space is reserved in case of pthread grow (which means the space is not taken), or just dynamic library (which means the space is used by loading the library, which takes about 10MB thanks to OpenSSL etc)

@robot0518
Copy link
Author

Hello @etwmc .
thank you very much.
i just coded according to your information and i cross-compiled the code.
but my OpenWrt was taken away by my colleague, so this moment i can't check the result.
anyway, thank you !

Greeting

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants