We might need -u option as well #3

cyrillos · 2011-12-17T13:53:06Z

This option should specify the UID for dump files owner and home directory

Right now we do syscall_seized for this, but we have the misc dumping command and the core is (after patch #3) dump after parasite, so we can get brk from the misc dump, thus avoiding one more switch to parasite. Signed-off-by: Pavel Emelyanov <xemul@parallels.com> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>

CID 996206 (cyrillos#3 of 3): Resource leak (RESOURCE_LEAK) 8. leaked_handle: Handle variable "sk" going out of scope leaks the handle.

It's opened in switch_ns. CID 996194 (cyrillos#3 of 5): Resource leak (RESOURCE_LEAK) 11. leaked_handle: Handle variable rst going out of scope leaks the handle.

CID 996206 (#3 of 3): Resource leak (RESOURCE_LEAK) 8. leaked_handle: Handle variable "sk" going out of scope leaks the handle. Signed-off-by: Andrey Vagin <avagin@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

It's opened in switch_ns. CID 996194 (#3 of 5): Resource leak (RESOURCE_LEAK) 11. leaked_handle: Handle variable rst going out of scope leaks the handle. Signed-off-by: Andrey Vagin <avagin@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

CID 996195 (cyrillos#1 of 1): Resource leak (RESOURCE_LEAK) 10. leaked_handle: Handle variable ask going out of scope leaks the handle. CID 996196 (cyrillos#3 of 3): Resource leak (RESOURCE_LEAK) 10. leaked_handle: Handle variable sk going out of scope leaks the handle.

CID 996195 (#1 of 1): Resource leak (RESOURCE_LEAK) 10. leaked_handle: Handle variable ask going out of scope leaks the handle. CID 996196 (#3 of 3): Resource leak (RESOURCE_LEAK) 10. leaked_handle: Handle variable sk going out of scope leaks the handle. Signed-off-by: Andrey Vagin <avagin@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

6. Condition "rst > 0", taking false branch 7. off_by_one: Testing whether handle "rst" is strictly greater than zero is suspicious. Did you intend to include equality with zero? "rst" leaks when it is zero. CID 1072986 (#3 of 4): Resource leak (RESOURCE_LEAK) 12. leaked_handle: Handle variable "rst" going out of scope leaks the handle. Signed-off-by: Andrey Vagin <avagin@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

6. Condition "rst > 0", taking false branch 7. off_by_one: Testing whether handle "rst" is strictly greater than zero is suspicious. Did you intend to include equality with zero? "rst" leaks when it is zero. CID 1072986 (cyrillos#3 of 4): Resource leak (RESOURCE_LEAK) 12. leaked_handle: Handle variable "rst" going out of scope leaks the handle.

It is called from prepare_cgroup_sfd() and cr_restore_tasks(). + criu restore --file-locks --tcp-established --evasive-devices --link-remap --root /var/lib/vz/root/101 --restore-detached --action-script /usr/local/libexec/vzctl/scripts/vps-rst-env -D /vz/dump/Dump.101 -o restore.log -vvvv --pidfile /var/lib/vzctl/vepid/101 *** Error in `criu': double free or corruption (fasttop): 0x00000000006bcd40 *** Program terminated with signal 6, Aborted. Missing separate debuginfos, use: debuginfo-install glibc-2.17-20.fc19.x86_64 libgcc-4.8.3-1.fc19.x86_64 protobuf-c-0.15-7.fc19.x86_64 (gdb) bt #0 0x00007ffff72179e9 in raise () from /lib64/libc.so.6 #1 0x00007ffff72190f8 in abort () from /lib64/libc.so.6 #2 0x00007ffff7257d17 in __libc_message () from /lib64/libc.so.6 #3 0x00007ffff725f0b8 in _int_free () from /lib64/libc.so.6 #4 0x0000000000426971 in cr_restore_tasks () at cr-restore.c:1833 #5 0x0000000000418426 in main (argc=<optimized out>, argv=0x7fffffffeb38, envp=<optimized out>) at crtools.c:479 Signed-off-by: Andrey Vagin <avagin@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>

If you call clone directly you are responsible for setting up the TLS area yourself. $ abrt-cli ls | grep different_creds | wc -l 39 $ gdb -c /var/spool/abrt/ccpp-2015-07-24-10\:21\:14-8014/coredump different_creds Core was generated by `./different_creds --pidfile=different_creds.pid --outfile=different_creds.out'. Program terminated with signal SIGILL, Illegal instruction. #0 0x00007f86e2d8c7d9 in _dl_x86_64_restore_sse () from /lib64/ld-linux-x86-64.so.2 Missing separate debuginfos, use: dnf debuginfo-install glibc-2.21-7.fc22.x86_64 libattr-2.4.47-9.fc22.x86_64 libcap-2.24-7.fc22.x86_64 (gdb) bt #0 0x00007f86e2d8c7d9 in _dl_x86_64_restore_sse () from /lib64/ld-linux-x86-64.so.2 #1 0x00007f86e2d84add in _dl_fixup () from /lib64/ld-linux-x86-64.so.2 #2 0x00007f86e2d8bbc0 in _dl_runtime_resolve () from /lib64/ld-linux-x86-64.so.2 #3 0x0000000000402da3 in sys_futex (val3=0, uaddr2=0x0, timeout=0x0, val=0, op=0, uaddr=0x6063f0 <sig_received>) at lock.h:29 #4 futex_wait_while (f=0x6063f0 <sig_received>, v=0) at lock.h:121 #5 test_waitsig () at test.c:367 #6 0x0000000000401c4b in main (argc=<optimized out>, argv=0x7ffce16432f8) at different_creds.c:82 Reported-by: Mr Jenkins Cc: Tycho Andersen <tycho.andersen@canonical.com> Signed-off-by: Andrew Vagin <avagin@openvz.org> Acked-by: Tycho Andersen <tycho.andersen@canonical.com> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

It can be dead-lokced: #0 0x00007fafbf49f6ac in __lll_lock_wait_private () from /lib64/libc.so.6 #1 0x00007fafbf44af1c in _L_lock_2460 () from /lib64/libc.so.6 #2 0x00007fafbf44ad57 in __tz_convert () from /lib64/libc.so.6 #3 0x00000000004022e2 in test_msg (format=0x404508 "Receive signal %d\n") at msg.c:51 #4 <signal handler called> #5 0x00007fafbf3f2483 in __GI__IO_vfscanf () from /lib64/libc.so.6 #6 0x00007fafbf408f27 in vsscanf () from /lib64/libc.so.6 #7 0x00007fafbf4032f7 in sscanf () from /lib64/libc.so.6 #8 0x00007fafbf449ba6 in __tzset_parse_tz () from /lib64/libc.so.6 #9 0x00007fafbf44c4cb in __tzfile_compute () from /lib64/libc.so.6 #10 0x00007fafbf44ae17 in __tz_convert () from /lib64/libc.so.6 #11 0x00000000004022e2 in test_msg (format=format@entry=0x40458c "PASS\n") at msg.c:51 #12 0x0000000000401ceb in main (argc=<optimized out>, argv=<optimized out>) at ptrace_sig.c:172 Signed-off-by: Andrey Vagin <avagin@openvz.org> Signed-off-by: Andrew Vagin <avagin@virtuozzo.com> Tested-by: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

The following error is emitted by clang: > CC criu/filesystems.o > criu/filesystems.c:280:13: error: variable 'ret' is used uninitialized > whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] > } else if (bme->extension) { > ^~~~~~~~~~~~~~ > criu/filesystems.c:287:6: note: uninitialized use occurs here > if (ret > 0) { > ^~~ > criu/filesystems.c:280:9: note: remove the 'if' if its condition is > always true > } else if (bme->extension) { > ^~~~~~~~~~~~~~~~~~~~ > criu/filesystems.c:272:9: note: initialize the variable 'ret' to silence > this warning > int ret; > ^ > = 0 > 1 error generated. This code was a result of commit 398e7d3. If we look closely, this is a false alarm, as "else if (bme->extension)" is always true as it was checked before. But this is not very clear, and the issue with clangs still needs to be fixed. There are many ways to do so: 1. Initialize ret to 0. This is what initial version of this patch did. 2. Remove the always-true condition, like this: - } else if (bme->extension) { + } else { In my opinion this would hurt readability. 3. Change the code flow, improving readability at the same time. I believe that #3 is what this patch does. In addition, it fixes handling of a few corner cases: - an overflow in snprintf(); - a case when bme->name is NULL (as it is used for strlen/snprintf, there is a potential for SIGSEGV); - a case of ret == 0 (currently there is no code flow that results in ret being 0, so it's just for the future). [v2: use linux kernel style for 'else' after a block] [xemul: Fix // comments ] Cc: Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by: Kir Kolyshkin <kir@openvz.org> Acked-by: Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

A root mount namespace list is used to resolve paths to unix sockets if they are placed on btrfs. This patch fixes a crash: #0 mount_resolve_path at criu/mount.c:213 #1 phys_stat_resolve_dev at criu/mount.c:240 #2 phys_stat_dev_match at criu/mount.c:256 #3 unix_process_name at criu/sk-unix.c:565 #4 unix_collect_one at criu/sk-unix.c:620 #5 unix_receive_one at criu/sk-unix.c:692 #6 nlmsg_receive at criu/libnetlink.c:45 #7 do_rtnl_req at criu/libnetlink.c:119 #8 do_collect_req at criu/sockets.c:610 #9 collect_sockets at criu/sockets.c:636 travis-ci: success for cr-check: fill up a root task mount namespace https://bugzilla.redhat.com/show_bug.cgi?id=1381351 Signed-off-by: Andrei Vagin <avagin@virtuozzo.com> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

The following error is emitted by clang: > CC criu/filesystems.o > criu/filesystems.c:280:13: error: variable 'ret' is used uninitialized > whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] > } else if (bme->extension) { > ^~~~~~~~~~~~~~ > criu/filesystems.c:287:6: note: uninitialized use occurs here > if (ret > 0) { > ^~~ > criu/filesystems.c:280:9: note: remove the 'if' if its condition is > always true > } else if (bme->extension) { > ^~~~~~~~~~~~~~~~~~~~ > criu/filesystems.c:272:9: note: initialize the variable 'ret' to silence > this warning > int ret; > ^ > = 0 > 1 error generated. This code was a result of commit 398e7d3. If we look closely, this is a false alarm, as "else if (bme->extension)" is always true as it was checked before. But this is not very clear, and the issue with clangs still needs to be fixed. There are many ways to do so: 1. Initialize ret to 0. This is what initial version of this patch did. 2. Remove the always-true condition, like this: - } else if (bme->extension) { + } else { In my opinion this would hurt readability. 3. Change the code flow, improving readability at the same time. I believe that #3 is what this patch does. In addition, it fixes handling of a few corner cases: - an overflow in snprintf(); - a case when bme->name is NULL (as it is used for strlen/snprintf, there is a potential for SIGSEGV); - a case of ret == 0 (currently there is no code flow that results in ret being 0, so it's just for the future). [v2: use linux kernel style for 'else' after a block] [xemul: Fix // comments ] Cc: Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by: Kir Kolyshkin <kir@openvz.org> Acked-by: Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

A root mount namespace list is used to resolve paths to unix sockets if they are placed on btrfs. This patch fixes a crash: #0 mount_resolve_path at criu/mount.c:213 #1 phys_stat_resolve_dev at criu/mount.c:240 #2 phys_stat_dev_match at criu/mount.c:256 #3 unix_process_name at criu/sk-unix.c:565 #4 unix_collect_one at criu/sk-unix.c:620 #5 unix_receive_one at criu/sk-unix.c:692 #6 nlmsg_receive at criu/libnetlink.c:45 #7 do_rtnl_req at criu/libnetlink.c:119 #8 do_collect_req at criu/sockets.c:610 #9 collect_sockets at criu/sockets.c:636 travis-ci: success for cr-check: fill up a root task mount namespace https://bugzilla.redhat.com/show_bug.cgi?id=1381351 Signed-off-by: Andrei Vagin <avagin@virtuozzo.com> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

Ghost file entry used right after it has been freed: ERROR: AddressSanitizer: heap-use-after-free on address 0x60700000dc50 READ of size 4 at 0x60700000dc50 thread T0 #0 0x46e819 in open_remap_ghost criu/files-reg.c:312 #1 0x46e819 in prepare_one_remap criu/files-reg.c:461 #2 0x46e819 in prepare_remaps criu/files-reg.c:507 #3 0x45af00 in root_prepare_shared criu/cr-restore.c:235 #4 0x45af00 in restore_task_with_children criu/cr-restore.c:1421 #5 0x7efc71e85f0c in clone (/lib64/libc.so.6+0xe7f0c) 0x60700000dc50 is located 32 bytes inside of 80-byte region [0x60700000dc30,0x60700000dc80) freed by thread T0 here: #0 0x7efc7305184a in __interceptor_free (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x9884a) #1 0x46e4df in open_remap_ghost criu/files-reg.c:309 #2 0x46e4df in prepare_one_remap criu/files-reg.c:461 #3 0x46e4df in prepare_remaps criu/files-reg.c:507 previously allocated by thread T0 here: #0 0x7efc73051b82 in malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x98b82) #1 0x7efc7277a8ea in protobuf_c_message_unpack (/usr/lib64/libprotobuf-c.so.1+0x48ea) #2 0xd528232002838017 (<unknown module>) Just move freeing after the last 'gfe' usage to fix this. Fixes: d0097b2 ("files: Support ghost directories restore") travis-ci: success for files-reg: fix use-after-free in open_remap_ghost() Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

'info' array is off-by-one, nla_parse_nested() requires destination array (i.e. 'info') to have maxtype+1 (i.e. IFLA_INFO_MAX+1) elements: ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffef823e3f8 WRITE of size 48 at 0x7ffef823e3f8 thread T0 #0 0x7f9ab7a3915b in __asan_memset (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x8d15b) #1 0x7f9ab6d4e553 in nla_parse (/usr/lib64/libnl-3.so.200+0xa553) #2 0x4acfb7 in dump_one_netdev criu/net.c:445 #3 0x4adb60 in dump_one_ethernet criu/net.c:594 #4 0x4adb60 in dump_one_link criu/net.c:665 #5 0x48af69 in nlmsg_receive criu/libnetlink.c:45 #6 0x48af69 in do_rtnl_req criu/libnetlink.c:119 #7 0x4b0e86 in dump_links criu/net.c:878 #8 0x4b0e86 in dump_net_ns criu/net.c:1651 #9 0x4a760d in do_dump_namespaces criu/namespaces.c:985 #10 0x4a760d in dump_namespaces criu/namespaces.c:1045 #11 0x451ef7 in cr_dump_tasks criu/cr-dump.c:1799 #12 0x424588 in main criu/crtools.c:736 #13 0x7f9ab67b171f in __libc_start_main (/lib64/libc.so.6+0x2071f) #14 0x4253d8 in _start (/criu/criu/criu+0x4253d8) Address 0x7ffef823e3f8 is located in stack of thread T0 at offset 264 in frame #0 0x4ac9ef in dump_one_netdev criu/net.c:364 This frame has 5 object(s): [32, 168) 'netdev' [224, 264) 'info' <== Memory access at offset 264 overflows this variable [320, 1040) 'req' [1088, 3368) 'path' [3424, 3625) 'stable_secret' Increase 'info' size to fix this. Fixes: b705dcc ("net: pass the struct nlattrs to dump() functions") travis-ci: success for net: fix stack out-of-bounds access in dump_one_netdev() Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Acked-by: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

Ghost file entry used right after it has been freed: ERROR: AddressSanitizer: heap-use-after-free on address 0x60700000dc50 READ of size 4 at 0x60700000dc50 thread T0 #0 0x46e819 in open_remap_ghost criu/files-reg.c:312 #1 0x46e819 in prepare_one_remap criu/files-reg.c:461 #2 0x46e819 in prepare_remaps criu/files-reg.c:507 #3 0x45af00 in root_prepare_shared criu/cr-restore.c:235 #4 0x45af00 in restore_task_with_children criu/cr-restore.c:1421 #5 0x7efc71e85f0c in clone (/lib64/libc.so.6+0xe7f0c) 0x60700000dc50 is located 32 bytes inside of 80-byte region [0x60700000dc30,0x60700000dc80) freed by thread T0 here: #0 0x7efc7305184a in __interceptor_free (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x9884a) #1 0x46e4df in open_remap_ghost criu/files-reg.c:309 #2 0x46e4df in prepare_one_remap criu/files-reg.c:461 #3 0x46e4df in prepare_remaps criu/files-reg.c:507 previously allocated by thread T0 here: #0 0x7efc73051b82 in malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x98b82) #1 0x7efc7277a8ea in protobuf_c_message_unpack (/usr/lib64/libprotobuf-c.so.1+0x48ea) #2 0xd528232002838017 (<unknown module>) Just move freeing after the last 'gfe' usage to fix this. Fixes: d0097b2 ("files: Support ghost directories restore") travis-ci: success for files-reg: fix use-after-free in open_remap_ghost() Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

'info' array is off-by-one, nla_parse_nested() requires destination array (i.e. 'info') to have maxtype+1 (i.e. IFLA_INFO_MAX+1) elements: ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffef823e3f8 WRITE of size 48 at 0x7ffef823e3f8 thread T0 #0 0x7f9ab7a3915b in __asan_memset (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x8d15b) #1 0x7f9ab6d4e553 in nla_parse (/usr/lib64/libnl-3.so.200+0xa553) #2 0x4acfb7 in dump_one_netdev criu/net.c:445 #3 0x4adb60 in dump_one_ethernet criu/net.c:594 #4 0x4adb60 in dump_one_link criu/net.c:665 #5 0x48af69 in nlmsg_receive criu/libnetlink.c:45 #6 0x48af69 in do_rtnl_req criu/libnetlink.c:119 #7 0x4b0e86 in dump_links criu/net.c:878 #8 0x4b0e86 in dump_net_ns criu/net.c:1651 #9 0x4a760d in do_dump_namespaces criu/namespaces.c:985 #10 0x4a760d in dump_namespaces criu/namespaces.c:1045 #11 0x451ef7 in cr_dump_tasks criu/cr-dump.c:1799 #12 0x424588 in main criu/crtools.c:736 #13 0x7f9ab67b171f in __libc_start_main (/lib64/libc.so.6+0x2071f) #14 0x4253d8 in _start (/criu/criu/criu+0x4253d8) Address 0x7ffef823e3f8 is located in stack of thread T0 at offset 264 in frame #0 0x4ac9ef in dump_one_netdev criu/net.c:364 This frame has 5 object(s): [32, 168) 'netdev' [224, 264) 'info' <== Memory access at offset 264 overflows this variable [320, 1040) 'req' [1088, 3368) 'path' [3424, 3625) 'stable_secret' Increase 'info' size to fix this. Fixes: b705dcc ("net: pass the struct nlattrs to dump() functions") travis-ci: success for net: fix stack out-of-bounds access in dump_one_netdev() Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Acked-by: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

In this patch, we replace all zero characters to '@'. ==30==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000e3ca at pc 0x7f34144b6be1 bp 0x7ffee7b6bb20 sp 0x7ffee7b6b298 READ of size 26 at 0x60300000e3ca thread T0 #0 0x7f34144b6be0 (/lib64/libasan.so.3+0x8dbe0) #1 0x7f34144b8e4d in __interceptor_vsnprintf (/lib64/libasan.so.3+0x8fe4d) #2 0x4966cb in vprint_on_level criu/log.c:228 #3 0x496b64 in print_on_level criu/log.c:249 #4 0x505c94 in collect_one_unixsk criu/sk-unix.c:1401 #5 0x4e7ae3 in collect_image criu/protobuf.c:213 #6 0x462c5c in root_prepare_shared criu/cr-restore.c:247 #7 0x462c5c in restore_task_with_children criu/cr-restore.c:1420 #8 0x7f34132d70ec in __clone (/lib64/libc.so.6+0x1030ec) 0x60300000e3ca is located 0 bytes to the right of 26-byte region [0x60300000e3b0,0x60300000e3ca) allocated by thread T0 here: #0 0x7f34144efe70 in malloc (/lib64/libasan.so.3+0xc6e70) #1 0x7f3413bdb021 (/lib64/libprotobuf-c.so.1+0x6021) Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

==36==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000001c at pc 0x7fb26c88d5f9 bp 0x7ffc15087d40 sp 0x7ffc150874d0 WRITE of size 13 at 0x60200000001c thread T0 #0 0x7fb26c88d5f8 in vsprintf (/lib64/libasan.so.4+0x9e5f8) #1 0x7fb26c88d986 in __interceptor_sprintf (/lib64/libasan.so.4+0x9e986) #2 0x402453 in main /root/git/main/criu/test/zdtm/static/chroot.c:68 #3 0x7fb26c43e4d9 in __libc_start_main (/lib64/libc.so.6+0x204d9) #4 0x4031b9 in _start (/root/git/main/criu/test/zdtm/static/chroot+0x4031b9) Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Segmentation fault was raised while trying to restore a process with tty. Coredump file says this is caused by uninitialized tty_mutex: (gdb) where #0 0x00000000004d7270 in atomic_add_return (i=1, v=0x0) at include/common/asm/atomic.h:34 #1 0x00000000004d7398 in mutex_lock (m=0x0) at include/common/lock.h:151 #2 0x00000000004d840c in __pty_open_ptmx_index (index=3, flags=2, cb=0x4dce50 <open_pty>, arg=0x11, path=0x5562e0 "ptmx") at criu/tty.c:603 #3 0x00000000004dced8 in pty_create_ptmx_index (dfd=17, index=3, flags=2) at criu/tty.c:2384 since init_tty_mutex() is reentrantable, just calling it before mutex_lock() Signed-off-by: Deng Guangxing <dengguangxing@huawei.com> Reviewed-by: Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by: Andrei Vagin <avagin@gmail.com>

ghost assigned cyrillos Dec 17, 2011

cyrillos closed this as completed Mar 21, 2012

avagin added a commit to avagin/crtools that referenced this issue Apr 5, 2013

cr-check: don't forget close a test socket

1e096b6

CID 996206 (cyrillos#3 of 3): Resource leak (RESOURCE_LEAK) 8. leaked_handle: Handle variable "sk" going out of scope leaks the handle.

cyrillos pushed a commit that referenced this issue Jun 9, 2015

SHN_ABS #3

926349d

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

We might need -u option as well #3

We might need -u option as well #3

cyrillos commented Dec 17, 2011

We might need -u option as well #3

We might need -u option as well #3

Comments

cyrillos commented Dec 17, 2011