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

Devel fix valgrind #77

Merged
merged 4 commits into from
Oct 1, 2015
Merged

Devel fix valgrind #77

merged 4 commits into from
Oct 1, 2015

Conversation

yousong
Copy link
Contributor

@yousong yousong commented Sep 19, 2015

This series started because a few memory corruption was observed when running xl2tpd under OpenWrt causing many segmentation fault errors.

The series was made on a x86_64 host with help of valgrind.

sudo valgrind -v --tool=memcheck --leak-check=full --log-file=valgrind.xl2tpd ./xl2tpd -C l2tp-control -c xl2tpd.conf -D -p xl2tpd.pid

Then tested with xl2tpd-control by adding and removing lac to false lns.

while true; do
sudo ./xl2tpd-control -c ./l2tp-control add l2tp-xxxxx pppoptfile=$(pwd)/options.xl2tpd lns='99.8.99.8'
sudo ./xl2tpd-control -c ./l2tp-control connect l2tp-xxxxx
sleep 0.5
sudo ./xl2tpd-control -c ./l2tp-control remove l2tp-xxxxx
sleep 0.5
done

This should fix 2 errors reported by valgrind about accessing already free'd
memory.  We should not try to touch the memory pointed by t->lac after the lac
was removed by xl2tpd-control.

Relevant valgrind for the record

  ==27360== 2 errors in context 1 of 2:
  ==27360== Invalid write of size 8
  ==27360==    at 0x402D3F: destroy_tunnel (xl2tpd.c:663)
  ==27360==    by 0x40DF5B: control_xmit (network.c:260)
  ==27360==    by 0x40F696: process_schedule (scheduler.c:47)
  ==27360==    by 0x40E1D5: network_thread (network.c:457)
  ==27360==    by 0x401C35: main (xl2tpd.c:1881)
  ==27360==  Address 0x51bbbe0 is 608 bytes inside a block of size 624 free'd
  ==27360==    at 0x4C27D4E: free (vg_replace_malloc.c:427)
  ==27360==    by 0x403661: control_handle_lac_remove (xl2tpd.c:1514)
  ==27360==    by 0x40462D: do_control (xl2tpd.c:1593)
  ==27360==    by 0x40E841: network_thread (network.c:481)
  ==27360==    by 0x401C35: main (xl2tpd.c:1881)
  ==27360==
  ==27360==
  ==27360== 2 errors in context 2 of 2:
  ==27360== Invalid read of size 4
  ==27360==    at 0x402D38: destroy_tunnel (xl2tpd.c:664)
  ==27360==    by 0x40DF5B: control_xmit (network.c:260)
  ==27360==    by 0x40F696: process_schedule (scheduler.c:47)
  ==27360==    by 0x40E1D5: network_thread (network.c:457)
  ==27360==    by 0x401C35: main (xl2tpd.c:1881)
  ==27360==  Address 0x51bbb74 is 500 bytes inside a block of size 624 free'd
  ==27360==    at 0x4C27D4E: free (vg_replace_malloc.c:427)
  ==27360==    by 0x403661: control_handle_lac_remove (xl2tpd.c:1514)
  ==27360==    by 0x40462D: do_control (xl2tpd.c:1593)
  ==27360==    by 0x40E841: network_thread (network.c:481)
  ==27360==    by 0x401C35: main (xl2tpd.c:1881)

Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
struct host was dynamically allocated, yet never released.

Valgrind report excerpt for the record

  ==15901== 8,928 bytes in 93 blocks are definitely lost in loss record 6 of 8
  ==15901==    at 0x4C28BED: malloc (vg_replace_malloc.c:263)
  ==15901==    by 0x40F9CB: set_lns (file.c:1108)
  ==15901==    by 0x4116C6: parse_one_option (file.c:1474)
  ==15901==    by 0x403FBC: parse_one_line (xl2tpd.c:992)
  ==15901==    by 0x404143: control_handle_lac_add_modify (xl2tpd.c:1456)
  ==15901==    by 0x40464D: do_control (xl2tpd.c:1594)
  ==15901==    by 0x40E861: network_thread (network.c:481)
  ==15901==    by 0x401C35: main (xl2tpd.c:1882)

Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
- Simply free(me) would lose reference to me->ppp_buf.
- Destroy_call(me) will do the job right (also free's up me->oldptyconf).
- Destroy_call(me) before free(t) to prevent incorrectly accessing already
  free'd data
- Struct call needs to be free'd in destroy_call.  The original free()
  call was commented out code in 7c3a27c "Some malloc/free sanity
  patches".  Not sure what the "totally wrong" referred to

Relevant valgrind report

  ==15901== 391,792 (6,768 direct, 385,024 indirect) bytes in 94 blocks are defi
  nitely lost in loss record 8 of 8
  ==15901==    at 0x4C28BED: malloc (vg_replace_malloc.c:263)
  ==15901==    by 0x405852: new_buf (misc.c:88)
  ==15901==    by 0x40CAF6: new_payload (call.c:33)
  ==15901==    by 0x40D5C0: new_call (call.c:549)
  ==15901==    by 0x40345B: new_tunnel (xl2tpd.c:927)
  ==15901==    by 0x40D7C9: get_call (call.c:665)
  ==15901==    by 0x402F26: l2tp_call (xl2tpd.c:723)
  ==15901==    by 0x403B47: control_handle_lac_connect (xl2tpd.c:1271)
  ==15901==    by 0x40464D: do_control (xl2tpd.c:1594)
  ==15901==    by 0x40E861: network_thread (network.c:481)
  ==15901==    by 0x401C35: main (xl2tpd.c:1882)

Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
References to lac structure should be cleared when removing the lac with
xl2tpd-control.

Relevant valgrind report

  ==22558== 1 errors in context 1 of 2:
  ==22558== Invalid write of size 8
  ==22558==    at 0x40D5C7: destroy_call (call.c:469)
  ==22558==    by 0x402DC2: destroy_tunnel (xl2tpd.c:691)
  ==22558==    by 0x40E762: control_xmit (network.c:260)
  ==22558==    by 0x40FF16: process_schedule (scheduler.c:47)
  ==22558==    by 0x40EA55: network_thread (network.c:457)
  ==22558==    by 0x401C35: main (xl2tpd.c:1894)
  ==22558==  Address 0x51bbbe8 is 616 bytes inside a block of size 624 free'd
  ==22558==    at 0x4C27D4E: free (vg_replace_malloc.c:427)
  ==22558==    by 0x40369C: control_handle_lac_remove (xl2tpd.c:1527)
  ==22558==    by 0x4047BD: do_control (xl2tpd.c:1606)
  ==22558==    by 0x40F0C1: network_thread (network.c:481)
  ==22558==    by 0x401C35: main (xl2tpd.c:1894)
  ==22558==
  ==22558==
  ==22558== 1 errors in context 2 of 2:
  ==22558== Invalid read of size 4
  ==22558==    at 0x40D5C1: destroy_call (call.c:470)
  ==22558==    by 0x402DC2: destroy_tunnel (xl2tpd.c:691)
  ==22558==    by 0x40E762: control_xmit (network.c:260)
  ==22558==    by 0x40FF16: process_schedule (scheduler.c:47)
  ==22558==    by 0x40EA55: network_thread (network.c:457)
  ==22558==    by 0x401C35: main (xl2tpd.c:1894)
  ==22558==  Address 0x51bbb74 is 500 bytes inside a block of size 624 free'd
  ==22558==    at 0x4C27D4E: free (vg_replace_malloc.c:427)
  ==22558==    by 0x40369C: control_handle_lac_remove (xl2tpd.c:1527)
  ==22558==    by 0x4047BD: do_control (xl2tpd.c:1606)
  ==22558==    by 0x40F0C1: network_thread (network.c:481)
  ==22558==    by 0x401C35: main (xl2tpd.c:1894)

Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
@yousong
Copy link
Contributor Author

yousong commented Sep 28, 2015

Hi, someone have a look at this please? Memory corruption and segmentation faults are really bad for a network service.

@shussain
Copy link
Collaborator

HI. Thank you for your commit. We will be testing your pull request soon.

@yousong
Copy link
Contributor Author

yousong commented Sep 30, 2015

Well, just to add that oom-killer came up after running lac remove/add for one night...

[334183.020000] Free swap  = 0kB
[334183.020000] Total swap = 0kB
[334183.020000] 65536 pages RAM
[334183.020000] 0 pages HighMem/MovableOnly
[334183.020000] 1508 pages reserved
[334183.020000] [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
[334183.020000] [ 1478]     0  1478      223      138       3        0             0 ubusd
[334183.020000] [ 1500]     0  1500      354      238       4        0             0 ash
[334183.020000] [ 1501]     0  1501      193      120       3        0             0 askfirst
[334183.020000] [ 1502]     0  1502      193      120       3        0             0 askfirst
[334183.020000] [ 1503]     0  1503      193      128       3        0             0 askfirst
[334183.020000] [ 2162]     0  2162      261      164       3        0             0 logd
[334183.020000] [ 2176]     0  2176      383      180       3        0             0 rpcd
[334183.020000] [ 2268]     0  2268      305      185       3        0             0 odhcpd
[334183.020000] [ 2346]     0  2346      341      207       4        0             0 telnetd
[334183.030000] [ 2378]     0  2378      379      173       3        0             0 uhttpd
[334183.030000] [ 2404]     0  2404    30323    30255      34        0             0 xl2tpd
[334183.030000] [ 2509]     0  2509      340      189       4        0             0 ntpd
[334183.030000] [ 2883]     0  2883      289      177       3        0             0 dropbear
[334183.030000] [ 3785]     0  3785      354      237       5        0             0 ash
[334183.030000] [ 8787]     0  8787      361      245       3        0             0 ash
[334183.030000] [15244] 65534 15244      235      172       5        0             0 dnsmasq
[334183.030000] [17775]     0 17775      342      226       3        0             0 ash
[334183.030000] [18668]     0 18668      393      225       4        0             0 netifd
[334183.030000] [28501]     0 28501      298      171       3        0             0 logread
[334183.030000] [28502]     0 28502      339      189       4        0             0 grep
[334183.030000] [29728]     0 29728      362      229       5        0             0 l2tp.sh
[334183.040000] [29731]     0 29731      362      167       5        0             0 l2tp.sh
[334183.040000] [29732]     0 29732      362      184       5        0             0 l2tp.sh
[334183.040000] [29733]     0 29733      362      210       5        0             0 l2tp.sh
[334183.040000] [29734]     0 29734      260      135       4        0             0 jshn
[334183.040000] Out of memory: Kill process 2404 (xl2tpd) score 458 or sacrifice child
[334183.040000] Killed process 2404 (xl2tpd) total-vm:121292kB, anon-rss:120500kB, file-rss:520kB

shussain pushed a commit that referenced this pull request Oct 1, 2015
@shussain shussain merged commit 5faece3 into xelerance:devel Oct 1, 2015
yousong added a commit to openwrt/packages that referenced this pull request Oct 2, 2015
The update is mainly for addressing some memory corruption and segementation
faults issues observed when running xl2tpd in OpenWrt.  The relevant upstream
pull request was at link [1]

 [1] Devel fix valgrind #77, xelerance/xl2tpd#77

Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
yousong added a commit to openwrt/packages that referenced this pull request Oct 2, 2015
The update is mainly for addressing some memory corruption and segementation
faults issues observed when running xl2tpd in OpenWrt.  The relevant upstream
pull request was at link [1]

 [1] Devel fix valgrind #77, xelerance/xl2tpd#77

Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
luizluca pushed a commit to luizluca/openwrt-packages that referenced this pull request Dec 16, 2015
The update is mainly for addressing some memory corruption and segementation
faults issues observed when running xl2tpd in OpenWrt.  The relevant upstream
pull request was at link [1]

 [1] Devel fix valgrind openwrt#77, xelerance/xl2tpd#77

Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
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

Successfully merging this pull request may close these issues.

None yet

2 participants