leak? #1
Comments
|
On Thu, May 29, 2014 at 10:39:49AM -0700, knokknok wrote:
Sorry for the late reply - we don't use github for problem tracking so In this function (xzfile_read_block) the 'data' pointer is returned to Rich. Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones |
rwmjones
added a commit
that referenced
this issue
Jan 19, 2018
Commit 876d715 ("Refactor plugin_* functions into a backend struct.") causes hidden crashes in the test suite (which unfortunately don't cause tests to fail). These all come from handle_single_connection where we may lock the connection, run a single connection, free the backend, and then try to unlock the connection. Unfortunately the unlock operation has to check the thread model again which fails because the backend has gone away: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00000000004070ce in unlock_connection () at locks.c:59 59 int thread_model = backend->thread_model (backend); [Current thread is 1 (Thread 0x7fab43243700 (LWP 6676))] (gdb) bt #0 0x00000000004070ce in unlock_connection () at locks.c:59 #1 0x00000000004061b1 in handle_single_connection (sockin=<optimized out>, sockout=<optimized out>) at connections.c:317 #2 0x00000000004087d3 in start_thread (datav=0x229fd00) at sockets.c:262 #3 0x00007fab44e525e1 in start_thread () from /lib64/libpthread.so.0 #4 0x00007fab44b8717f in clone () from /lib64/libc.so.6 Since the thread model cannot be changed after a plugin is loaded, just cache it in src/locks.c after the backend is created. Note that I don't believe commit 876d715 caused this breakage. I think it only worked by accident before because it would still have been possible that handle_single_connection was reading the plugin._thread_model field after dlclose.
rwmjones
added a commit
that referenced
this issue
Oct 30, 2018
Fixes commit d1bba96. Error found by GCC ASAN: ==27287==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffcae2e3021 at pc 0x7fd5e96688de bp 0x7ffcae2e2e50 sp 0x7ffcae2e25d8 WRITE of size 2 at 0x7ffcae2e3021 thread T0 #0 0x7fd5e96688dd (/lib64/libasan.so.5+0x3d8dd) #1 0x7fd5e9669312 in vsscanf (/lib64/libasan.so.5+0x3e312) #2 0x7fd5e966941e in sscanf (/lib64/libasan.so.5+0x3e41e) #3 0x7fd5e535ee8a in read_data /home/rjones/d/nbdkit/plugins/data/data.c:171 #4 0x7fd5e535ee8a in data_config /home/rjones/d/nbdkit/plugins/data/data.c:260 #5 0x565032f3193d in plugin_config /home/rjones/d/nbdkit/src/plugins.c:217 #6 0x565032f2b9e4 in next_config /home/rjones/d/nbdkit/src/filters.c:165 #7 0x565032f2ee1b in filter_config /home/rjones/d/nbdkit/src/filters.c:178 #8 0x565032f232ed in main /home/rjones/d/nbdkit/src/main.c:702 #9 0x7fd5e9071412 in __libc_start_main (/lib64/libc.so.6+0x24412) #10 0x565032f24b6d in _start (/home/rjones/d/nbdkit/src/nbdkit+0x12b6d) Address 0x7ffcae2e3021 is located in stack of thread T0 at offset 33 in frame #0 0x7fd5e535eb9f in data_config /home/rjones/d/nbdkit/plugins/data/data.c:232 This frame has 6 object(s): [32, 33) 'c' <== Memory access at offset 33 overflows this variable [96, 100) 'n' [160, 168) 'offset' [224, 232) 'j' [288, 304) 'in' [352, 368) 'out'
rwmjones
added a commit
to rwmjones/nbdkit
that referenced
this issue
Mar 18, 2019
This is a cheap way to find some use-after-free and uninitialized read problems when using glibc. This in fact reveals a race during filter shutdown (which this commit does not fix): Thread 2 (Thread 0x7f1caaa5ffc0 (LWP 7223)): #0 0x00007f1cab0a05f8 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0 libguestfs#1 0x0000000000408842 in lock_unload () at locks.c:97 libguestfs#2 0x00000000004066ff in filter_free (b=0x203c330) at filters.c:77 libguestfs#3 0x000000000040a6f4 in main (argc=11, argv=0x7ffc1f4486e8) at main.c:649 Thread 1 (Thread 0x7f1caaa5e700 (LWP 7226)): #0 0x000000000040732a in filter_finalize (b=0x203c330, conn=0x203d870) at filters.c:421 libguestfs#1 0x0000000000404d07 in _handle_single_connection (sockin=6, sockout=6) at connections.c:239 libguestfs#2 0x0000000000404d76 in handle_single_connection (sockin=6, sockout=6) at connections.c:258 libguestfs#3 0x00000000004119f6 in start_thread (datav=0x203b450) at sockets.c:263 libguestfs#4 0x00007f1cab09b5a2 in start_thread () from /lib64/libpthread.so.0 libguestfs#5 0x00007f1caafc85c3 in clone () from /lib64/libc.so.6 What's happening here is that the filter / plugin chain is freed by Thread 2, while Thread 1 is calling filter->finalize. At this point filter->finalize points to freed memory, but "normally" this would still contain the correct function pointer. However when MALLOC_PERTURB_ is set the function pointer is overwritten with the non-zero dead memory pattern which we then attempt to call, causing a segfault (in Thread 1).
rwmjones
added a commit
to rwmjones/nbdkit
that referenced
this issue
Mar 18, 2019
This is a cheap way to find some use-after-free and uninitialized read problems when using glibc. This in fact reveals a race during filter shutdown (which this commit does not fix): Thread 2 (Thread 0x7f1caaa5ffc0 (LWP 7223)): #0 0x00007f1cab0a05f8 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0 libguestfs#1 0x0000000000408842 in lock_unload () at locks.c:97 libguestfs#2 0x00000000004066ff in filter_free (b=0x203c330) at filters.c:77 libguestfs#3 0x000000000040a6f4 in main (argc=11, argv=0x7ffc1f4486e8) at main.c:649 Thread 1 (Thread 0x7f1caaa5e700 (LWP 7226)): #0 0x000000000040732a in filter_finalize (b=0x203c330, conn=0x203d870) at filters.c:421 libguestfs#1 0x0000000000404d07 in _handle_single_connection (sockin=6, sockout=6) at connections.c:239 libguestfs#2 0x0000000000404d76 in handle_single_connection (sockin=6, sockout=6) at connections.c:258 libguestfs#3 0x00000000004119f6 in start_thread (datav=0x203b450) at sockets.c:263 libguestfs#4 0x00007f1cab09b5a2 in start_thread () from /lib64/libpthread.so.0 libguestfs#5 0x00007f1caafc85c3 in clone () from /lib64/libc.so.6 What's happening here is that the filter / plugin chain is freed by Thread 2, while Thread 1 is calling filter->finalize. At this point filter->finalize points to freed memory, but "normally" this would still contain the correct function pointer. However when MALLOC_PERTURB_ is set the function pointer is overwritten with the non-zero dead memory pattern which we then attempt to call, causing a segfault (in Thread 1).
rwmjones
added a commit
that referenced
this issue
Nov 6, 2019
A frequent cause of crashes on shutdown happens when the quit signal has been received and the main thread and other threads race each other at shutdown. As in the typical stack trace below what happens is that the main thread unloads the plugins while they are still being used by one of the connection threads, causing the connection thread to segfault after calling dlclosed functions. To avoid this simply count the number of connection threads we create, and at exit in the main thread wait until this count drops to 0 before we actually start unloading anything. Thread 2 (Thread 0x7f8fb054ea40 (LWP 3105233)): #0 _asn1_set_down (down=0x5633dd26c010, node=0x5633dd26be70) at parser_aux.h:116 #1 asn1_delete_structure2 (structure=structure@entry=0x7f8fb0dd3fa0 <_gnutls_pkix1_asn>, flags=flags@entry=0) at structure.c:328 #2 0x00007f8fb06e702b in asn1_delete_structure (structure=structure@entry=0x7f8fb0dd3fa0 <_gnutls_pkix1_asn>) at structure.c:293 #3 0x00007f8fb0c66544 in _gnutls_global_deinit (destructor=1) at global.c:419 #4 0x00007f8fb0e0d13b in _dl_fini () at dl-fini.c:138 #5 0x00007f8fb0a0ae87 in __run_exit_handlers (status=0, listp=0x7f8fb0b8e578 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108 #6 0x00007f8fb0a0b040 in __GI_exit (status=<optimized out>) at exit.c:139 #7 0x00005633d47626ee in main (argc=<optimized out>, argv=0x7ffecd6115d8) at main.c:705 Thread 1 (Thread 0x7f8fb054d700 (LWP 3105257)): #0 backend_finalize (b=<optimized out>, conn=conn@entry=0x5633dd287c40) at backend.c:227 #1 0x00005633d476579f in handle_single_connection (sockin=<optimized out>, sockout=<optimized out>) at connections.c:222 #2 0x00005633d476e9e9 in start_thread (datav=0x5633dd269620) at sockets.c:351 #3 0x00007f8fb0b9e4e2 in start_thread (arg=<optimized out>) at pthread_create.c:479 #4 0x00007f8fb0acd643 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
libguestfs
pushed a commit
that referenced
this issue
Aug 15, 2021
The zstd allocator crashed when asked to either fill or zero space
that had previously been unallocated. This adds a check for this
case.
$ rpm -q nbdkit
nbdkit-1.27.4-1.fc35.x86_64
$ nbdkit data "0*10" allocator=zstd -fv
nbdkit: debug: nbdkit 1.27.4 (nbdkit-1.27.4-1.fc35)
nbdkit: debug: TLS disabled: could not load TLS certificates
nbdkit: debug: registering plugin /usr/lib64/nbdkit/plugins/nbdkit-data-plugin.so
nbdkit: debug: registered plugin /usr/lib64/nbdkit/plugins/nbdkit-data-plugin.so (name data)
nbdkit: debug: data: load
nbdkit: debug: data: config key=data, value=0*10
nbdkit: debug: data: config key=allocator, value=zstd
nbdkit: debug: data: config_complete
nbdkit: debug: using thread model: parallel
nbdkit: debug: data: get_ready
nbdkit: debug: allocator: zstd
Segmentation fault (core dumped)
(gdb) bt
#0 0x00007ff61d67284e in zstd_array_zero (a=0x557b37763b50, count=10,
offset=0) at ../../common/allocators/zstd.c:484
#1 0x00007ff61d672aab in zstd_array_fill (a=0x557b37763b50,
c=<optimized out>, count=10, offset=0)
at ../../common/allocators/zstd.c:432
#2 0x00007ff61d6703c2 in evaluate (dict=0x0, root=<optimized out>,
a=0x557b37763b50, offset=0x7fff9a6b5330, size=0x7fff9a6b5310)
at /usr/src/debug/nbdkit-1.27.4-1.fc35.x86_64/plugins/data/format.c:1346
#3 0x00007ff61d670663 in read_data_format (size_rtn=0x7fff9a6b5310,
a=0x557b37763b50, value=<optimized out>)
at /usr/src/debug/nbdkit-1.27.4-1.fc35.x86_64/plugins/data/format.c:314
#4 data_get_ready ()
at /usr/src/debug/nbdkit-1.27.4-1.fc35.x86_64/plugins/data/data.c:214
#5 0x0000557b2e5a005f in plugin_get_ready (b=0x557b37763870)
at /usr/src/debug/nbdkit-1.27.4-1.fc35.x86_64/server/plugins.c:259
#6 0x0000557b2e59a073 in main (argc=<optimized out>, argv=<optimized out>)
at /usr/src/debug/nbdkit-1.27.4-1.fc35.x86_64/server/main.c:731
libguestfs
pushed a commit
that referenced
this issue
Aug 16, 2021
The zstd allocator crashed when asked to either fill or zero space
that had previously been unallocated. This adds a check for this
case.
$ rpm -q nbdkit
nbdkit-1.27.4-1.fc35.x86_64
$ nbdkit data "0*10" allocator=zstd -fv
nbdkit: debug: nbdkit 1.27.4 (nbdkit-1.27.4-1.fc35)
nbdkit: debug: TLS disabled: could not load TLS certificates
nbdkit: debug: registering plugin /usr/lib64/nbdkit/plugins/nbdkit-data-plugin.so
nbdkit: debug: registered plugin /usr/lib64/nbdkit/plugins/nbdkit-data-plugin.so (name data)
nbdkit: debug: data: load
nbdkit: debug: data: config key=data, value=0*10
nbdkit: debug: data: config key=allocator, value=zstd
nbdkit: debug: data: config_complete
nbdkit: debug: using thread model: parallel
nbdkit: debug: data: get_ready
nbdkit: debug: allocator: zstd
Segmentation fault (core dumped)
(gdb) bt
#0 0x00007ff61d67284e in zstd_array_zero (a=0x557b37763b50, count=10,
offset=0) at ../../common/allocators/zstd.c:484
#1 0x00007ff61d672aab in zstd_array_fill (a=0x557b37763b50,
c=<optimized out>, count=10, offset=0)
at ../../common/allocators/zstd.c:432
#2 0x00007ff61d6703c2 in evaluate (dict=0x0, root=<optimized out>,
a=0x557b37763b50, offset=0x7fff9a6b5330, size=0x7fff9a6b5310)
at /usr/src/debug/nbdkit-1.27.4-1.fc35.x86_64/plugins/data/format.c:1346
#3 0x00007ff61d670663 in read_data_format (size_rtn=0x7fff9a6b5310,
a=0x557b37763b50, value=<optimized out>)
at /usr/src/debug/nbdkit-1.27.4-1.fc35.x86_64/plugins/data/format.c:314
#4 data_get_ready ()
at /usr/src/debug/nbdkit-1.27.4-1.fc35.x86_64/plugins/data/data.c:214
#5 0x0000557b2e5a005f in plugin_get_ready (b=0x557b37763870)
at /usr/src/debug/nbdkit-1.27.4-1.fc35.x86_64/server/plugins.c:259
#6 0x0000557b2e59a073 in main (argc=<optimized out>, argv=<optimized out>)
at /usr/src/debug/nbdkit-1.27.4-1.fc35.x86_64/server/main.c:731
(cherry picked from commit 712fd7b)
libguestfs
pushed a commit
that referenced
this issue
Oct 21, 2021
VDDK 7.0.0 and 7.0.3 crash with GLIBC_TUNABLES (malloc debugging) and
latest glibc. This likely indicates a bug in VDDK, but as we cannot
fix it we need to disable the extra hygiene checks instead. For
information the stack trace is below.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 malloc_check_get_size (mem=0x0)
at /usr/src/debug/glibc-2.34.9000-13.fc36.x86_64/malloc/malloc-check.c:39
39 magic = (((uintptr_t) p >> 3) ^ ((uintptr_t) p >> 11)) & 0xFF;
[Current thread is 1 (Thread 0x7fea8056b640 (LWP 3905172))]
(gdb) bt
#0 malloc_check_get_size (mem=0x0)
at /usr/src/debug/glibc-2.34.9000-13.fc36.x86_64/malloc/malloc-check.c:39
#1 malloc_usable_size (mem=0x0) at malloc-debug.c:405
#2 0x00007fea7fd5199b in greedy_realloc0 (p=p@entry=0x7fea805690c0,
need=need@entry=2, size=size@entry=16) at ../src/basic/alloc-util.c:87
#3 0x00007fea7fd51b13 in netlink_container_parse (m=m@entry=0x555d34e77f80,
container=0x555d34e77f90, rta=0x555d34e821f8, rt_len=<optimized out>)
at ../src/libsystemd/sd-netlink/netlink-message.c:1078
#4 0x00007fea7fd557ec in sd_netlink_message_rewind (genl=<optimized out>,
m=<optimized out>) at ../src/libsystemd/sd-netlink/netlink-message.c:1324
#5 socket_read_message (rtnl=<optimized out>)
at ../src/libsystemd/sd-netlink/netlink-socket.c:375
#6 sd_netlink_read (usec=0, ret=0x7fea805692a0, serial=<optimized out>,
rtnl=<optimized out>) at ../src/libsystemd/sd-netlink/sd-netlink.c:700
#7 sd_netlink_call (rtnl=<optimized out>, message=<optimized out>,
ret=0x7fea805692a0, usec=0)
at ../src/libsystemd/sd-netlink/sd-netlink.c:743
#8 0x00007fea7fd5818e in local_addresses (af=2, ret=0x7fea80569378,
ifindex=0, context=0x0) at ../src/shared/local-addresses.c:90
#9 0x00007fea7fd590b9 in _nss_myhostname_gethostbyname3_r (
name=<optimized out>, af=<optimized out>, host=0x7fea805695a0,
buffer=0x7fea80569750 "\177", buflen=1024, errnop=0x7fea8056b4b8,
h_errnop=0x7fea80569594, ttlp=0x0, canonp=0x0)
at ../src/nss-myhostname/nss-myhostname.c:373
#10 0x00007fea7fd593cb in _nss_myhostname_gethostbyname_r (
name=0x7fea80569601 "pick", host=0x7fea805695a0,
buffer=0x7fea80569750 "\177", buflen=1024, errnop=0x7fea8056b4b8,
h_errnop=0x7fea80569594) at ../src/nss-myhostname/nss-myhostname.c:514
#11 0x00007fea864491cb in __gethostbyname_r (
name=0x7fea80569601 "pick", resbuf=0x7fea805695a0,
buffer=<optimized out>, buflen=1024, result=<optimized out>,
h_errnop=0x7fea80569594) at ../nss/getXXbyYY_r.c:273
#12 0x00007fea85bdcca4 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#13 0x00007fea85bd2bb2 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#14 0x00007fea85bba567 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#15 0x00007fea85bbab75 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#16 0x00007fea85bc63bd in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#17 0x00007fea85bc42ec in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#18 0x00007fea85bbf026 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#19 0x00007fea85bc0038 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#20 0x00007fea85c2fb23 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#21 0x00007fea85c2f160 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#22 0x00007fea85c2f1ba in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#23 0x00007fea85d0c0b9 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#24 0x00007fea85d079cb in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#25 0x00007fea85cb2831 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#26 0x00007fea85ca4702 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#27 0x00007fea85c9f76f in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#28 0x00007fea85c7b59f in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#29 0x00007fea85c7c11d in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#30 0x00007fea85bb4475 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#31 0x00007fea85bb4717 in VixDiskLib_Open ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#32 0x00007fea867b0dbb in vddk_open (readonly=<optimized out>)
at /home/rjones/d/nbdkit/plugins/vddk/vddk.c:717
#33 0x0000555d2a83d922 in plugin_open (c=0x555d34e81d10, readonly=0,
exportname=<optimized out>, is_tls=<optimized out>)
at /home/rjones/d/nbdkit/server/plugins.c:353
#34 0x0000555d2a83572d in backend_open (b=0x555d34668db0, readonly=0,
exportname=0x555d34dae020 "", shared=0)
at /home/rjones/d/nbdkit/server/backend.c:292
#35 0x0000555d2a83b937 in protocol_common_open (
exportsize=exportsize@entry=0x7fea8056a9e0,
flags=flags@entry=0x555d34e7f604,
exportname=exportname@entry=0x555d34e7eeb0 "")
at /home/rjones/d/nbdkit/server/protocol-handshake.c:83
#36 0x0000555d2a83e140 in finish_newstyle_options (exportsize=0x7fea8056a9e0,
exportname_in=<optimized out>, exportnamelen=<optimized out>)
at /home/rjones/d/nbdkit/server/protocol-handshake-newstyle.c:284
#37 0x0000555d2a837ee0 in negotiate_handshake_newstyle_options ()
at /home/rjones/d/nbdkit/server/protocol-handshake-newstyle.c:572
#38 protocol_handshake_newstyle ()
at /home/rjones/d/nbdkit/server/protocol-handshake-newstyle.c:904
#39 protocol_handshake ()
at /home/rjones/d/nbdkit/server/protocol-handshake.c:55
#40 handle_single_connection (sockin=<optimized out>, sockout=<optimized out>)
at /home/rjones/d/nbdkit/server/connections.c:171
#41 0x0000555d2a83e4e0 in start_thread (datav=0x555d34d987d0)
at /home/rjones/d/nbdkit/server/sockets.c:354
#42 0x00007fea863b4677 in start_thread (arg=<optimized out>)
at pthread_create.c:434
#43 0x00007fea86439320 in clone3 ()
at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
libguestfs
pushed a commit
that referenced
this issue
Oct 25, 2021
VDDK 7.0.0 and 7.0.3 crash with GLIBC_TUNABLES (malloc debugging) and
latest glibc. This likely indicates a bug in VDDK, but as we cannot
fix it we need to disable the extra hygiene checks instead. For
information the stack trace is below.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 malloc_check_get_size (mem=0x0)
at /usr/src/debug/glibc-2.34.9000-13.fc36.x86_64/malloc/malloc-check.c:39
39 magic = (((uintptr_t) p >> 3) ^ ((uintptr_t) p >> 11)) & 0xFF;
[Current thread is 1 (Thread 0x7fea8056b640 (LWP 3905172))]
(gdb) bt
#0 malloc_check_get_size (mem=0x0)
at /usr/src/debug/glibc-2.34.9000-13.fc36.x86_64/malloc/malloc-check.c:39
#1 malloc_usable_size (mem=0x0) at malloc-debug.c:405
#2 0x00007fea7fd5199b in greedy_realloc0 (p=p@entry=0x7fea805690c0,
need=need@entry=2, size=size@entry=16) at ../src/basic/alloc-util.c:87
#3 0x00007fea7fd51b13 in netlink_container_parse (m=m@entry=0x555d34e77f80,
container=0x555d34e77f90, rta=0x555d34e821f8, rt_len=<optimized out>)
at ../src/libsystemd/sd-netlink/netlink-message.c:1078
#4 0x00007fea7fd557ec in sd_netlink_message_rewind (genl=<optimized out>,
m=<optimized out>) at ../src/libsystemd/sd-netlink/netlink-message.c:1324
#5 socket_read_message (rtnl=<optimized out>)
at ../src/libsystemd/sd-netlink/netlink-socket.c:375
#6 sd_netlink_read (usec=0, ret=0x7fea805692a0, serial=<optimized out>,
rtnl=<optimized out>) at ../src/libsystemd/sd-netlink/sd-netlink.c:700
#7 sd_netlink_call (rtnl=<optimized out>, message=<optimized out>,
ret=0x7fea805692a0, usec=0)
at ../src/libsystemd/sd-netlink/sd-netlink.c:743
#8 0x00007fea7fd5818e in local_addresses (af=2, ret=0x7fea80569378,
ifindex=0, context=0x0) at ../src/shared/local-addresses.c:90
#9 0x00007fea7fd590b9 in _nss_myhostname_gethostbyname3_r (
name=<optimized out>, af=<optimized out>, host=0x7fea805695a0,
buffer=0x7fea80569750 "\177", buflen=1024, errnop=0x7fea8056b4b8,
h_errnop=0x7fea80569594, ttlp=0x0, canonp=0x0)
at ../src/nss-myhostname/nss-myhostname.c:373
#10 0x00007fea7fd593cb in _nss_myhostname_gethostbyname_r (
name=0x7fea80569601 "pick", host=0x7fea805695a0,
buffer=0x7fea80569750 "\177", buflen=1024, errnop=0x7fea8056b4b8,
h_errnop=0x7fea80569594) at ../src/nss-myhostname/nss-myhostname.c:514
#11 0x00007fea864491cb in __gethostbyname_r (
name=0x7fea80569601 "pick", resbuf=0x7fea805695a0,
buffer=<optimized out>, buflen=1024, result=<optimized out>,
h_errnop=0x7fea80569594) at ../nss/getXXbyYY_r.c:273
#12 0x00007fea85bdcca4 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#13 0x00007fea85bd2bb2 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#14 0x00007fea85bba567 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#15 0x00007fea85bbab75 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#16 0x00007fea85bc63bd in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#17 0x00007fea85bc42ec in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#18 0x00007fea85bbf026 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#19 0x00007fea85bc0038 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#20 0x00007fea85c2fb23 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#21 0x00007fea85c2f160 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#22 0x00007fea85c2f1ba in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#23 0x00007fea85d0c0b9 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#24 0x00007fea85d079cb in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#25 0x00007fea85cb2831 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#26 0x00007fea85ca4702 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#27 0x00007fea85c9f76f in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#28 0x00007fea85c7b59f in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#29 0x00007fea85c7c11d in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#30 0x00007fea85bb4475 in ?? ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#31 0x00007fea85bb4717 in VixDiskLib_Open ()
from vddk-7.0.3/vmware-vix-disklib-distrib/lib64/libvixDiskLib.so.7
#32 0x00007fea867b0dbb in vddk_open (readonly=<optimized out>)
at /home/rjones/d/nbdkit/plugins/vddk/vddk.c:717
#33 0x0000555d2a83d922 in plugin_open (c=0x555d34e81d10, readonly=0,
exportname=<optimized out>, is_tls=<optimized out>)
at /home/rjones/d/nbdkit/server/plugins.c:353
#34 0x0000555d2a83572d in backend_open (b=0x555d34668db0, readonly=0,
exportname=0x555d34dae020 "", shared=0)
at /home/rjones/d/nbdkit/server/backend.c:292
#35 0x0000555d2a83b937 in protocol_common_open (
exportsize=exportsize@entry=0x7fea8056a9e0,
flags=flags@entry=0x555d34e7f604,
exportname=exportname@entry=0x555d34e7eeb0 "")
at /home/rjones/d/nbdkit/server/protocol-handshake.c:83
#36 0x0000555d2a83e140 in finish_newstyle_options (exportsize=0x7fea8056a9e0,
exportname_in=<optimized out>, exportnamelen=<optimized out>)
at /home/rjones/d/nbdkit/server/protocol-handshake-newstyle.c:284
#37 0x0000555d2a837ee0 in negotiate_handshake_newstyle_options ()
at /home/rjones/d/nbdkit/server/protocol-handshake-newstyle.c:572
#38 protocol_handshake_newstyle ()
at /home/rjones/d/nbdkit/server/protocol-handshake-newstyle.c:904
#39 protocol_handshake ()
at /home/rjones/d/nbdkit/server/protocol-handshake.c:55
#40 handle_single_connection (sockin=<optimized out>, sockout=<optimized out>)
at /home/rjones/d/nbdkit/server/connections.c:171
#41 0x0000555d2a83e4e0 in start_thread (datav=0x555d34d987d0)
at /home/rjones/d/nbdkit/server/sockets.c:354
#42 0x00007fea863b4677 in start_thread (arg=<optimized out>)
at pthread_create.c:434
#43 0x00007fea86439320 in clone3 ()
at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(cherry picked from commit 03406a7)
libguestfs
pushed a commit
that referenced
this issue
Jun 20, 2022
==3869068== Memcheck, a memory error detector ==3869068== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==3869068== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==3869068== Command: ./test_010_import.opt ==3869068== ==3869068== Syscall param sigaltstack(ss) points to uninitialised byte(s) ==3869068== at 0x49DF24B: sigaltstack (syscall-template.S:120) ==3869068== by 0x1A1365: caml_terminate_signals (in /home/rjones/d/libnbd/ocaml/tests/test_010_import.opt) ==3869068== by 0x1C0C33: caml_startup_common (in /home/rjones/d/libnbd/ocaml/tests/test_010_import.opt) ==3869068== by 0x1C0CAE: caml_main (in /home/rjones/d/libnbd/ocaml/tests/test_010_import.opt) ==3869068== by 0x15CDC1: main (in /home/rjones/d/libnbd/ocaml/tests/test_010_import.opt) ==3869068== Address 0x1ffeffe500 is on thread 1's stack ==3869068== in frame #1, created by caml_terminate_signals (???:) ==3869068== ==3869068== Syscall param sigaltstack(ss) points to uninitialised byte(s) ==3869068== at 0x49DF24B: sigaltstack (syscall-template.S:120) ==3869068== by 0x1A1365: caml_terminate_signals (in /home/rjones/d/libnbd/ocaml/tests/test_010_import.opt) ==3869068== by 0x1B1B6F: caml_do_exit (in /home/rjones/d/libnbd/ocaml/tests/test_010_import.opt) ==3869068== by 0x15CDC8: main (in /home/rjones/d/libnbd/ocaml/tests/test_010_import.opt) ==3869068== Address 0x1ffeffe4d0 is on thread 1's stack ==3869068== in frame #1, created by caml_terminate_signals (???:) (cherry picked from libnbd commit 73dec295f3bbdf8afbfd548eb5a776dee27b0ac0)
libguestfs
pushed a commit
that referenced
this issue
Jun 20, 2022
After discussion with the OCaml team we think these are both bugs in valgrind, not OCaml, but we still need a suppression. ==4145632== Syscall param sigaltstack(ss) points to uninitialised byte(s) ==4145632== at 0xCC5E24B: sigaltstack (syscall-template.S:120) ==4145632== by 0xD7F46CC: caml_stop_stack_overflow_detection (in /home/rjones/d/nbdkit/tests/test-ocaml-plugin.so) ==4145632== by 0xD7F277E: caml_startup_common (in /home/rjones/d/nbdkit/tests/test-ocaml-plugin.so) ==4145632== by 0xD7F27CC: caml_startup (in /home/rjones/d/nbdkit/tests/test-ocaml-plugin.so) ==4145632== by 0xC986891: constructor (plugin.c:64) ==4145632== by 0xC133CED: call_init (dl-init.c:70) ==4145632== by 0xC133DDB: _dl_init (dl-init.c:117) ==4145632== by 0xCD72A73: _dl_catch_exception (dl-error-skeleton.c:182) ==4145632== by 0xC13A955: dl_open_worker (dl-open.c:808) ==4145632== by 0xCD72A1D: _dl_catch_exception (dl-error-skeleton.c:208) ==4145632== by 0xC13ACEB: _dl_open (dl-open.c:883) ==4145632== by 0xCCA7EC9: dlopen_doit (dlopen.c:56) ==4145632== by 0xCD72A1D: _dl_catch_exception (dl-error-skeleton.c:208) ==4145632== by 0xCD72AD2: _dl_catch_error (dl-error-skeleton.c:227) ==4145632== by 0xCCA79DE: _dlerror_run (dlerror.c:138) ==4145632== by 0xCCA7F67: dlopen@@GLIBC_2.34 (dlopen.c:71) ==4145632== by 0x10F775: main (main.c:833) ==4145632== Address 0x1ffeffaca0 is on thread 1's stack ==4145632== in frame #1, created by caml_stop_stack_overflow_detection (???:)
libguestfs
pushed a commit
that referenced
this issue
Jul 6, 2022
==3869068== Memcheck, a memory error detector ==3869068== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==3869068== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==3869068== Command: ./test_010_import.opt ==3869068== ==3869068== Syscall param sigaltstack(ss) points to uninitialised byte(s) ==3869068== at 0x49DF24B: sigaltstack (syscall-template.S:120) ==3869068== by 0x1A1365: caml_terminate_signals (in /home/rjones/d/libnbd/ocaml/tests/test_010_import.opt) ==3869068== by 0x1C0C33: caml_startup_common (in /home/rjones/d/libnbd/ocaml/tests/test_010_import.opt) ==3869068== by 0x1C0CAE: caml_main (in /home/rjones/d/libnbd/ocaml/tests/test_010_import.opt) ==3869068== by 0x15CDC1: main (in /home/rjones/d/libnbd/ocaml/tests/test_010_import.opt) ==3869068== Address 0x1ffeffe500 is on thread 1's stack ==3869068== in frame #1, created by caml_terminate_signals (???:) ==3869068== ==3869068== Syscall param sigaltstack(ss) points to uninitialised byte(s) ==3869068== at 0x49DF24B: sigaltstack (syscall-template.S:120) ==3869068== by 0x1A1365: caml_terminate_signals (in /home/rjones/d/libnbd/ocaml/tests/test_010_import.opt) ==3869068== by 0x1B1B6F: caml_do_exit (in /home/rjones/d/libnbd/ocaml/tests/test_010_import.opt) ==3869068== by 0x15CDC8: main (in /home/rjones/d/libnbd/ocaml/tests/test_010_import.opt) ==3869068== Address 0x1ffeffe4d0 is on thread 1's stack ==3869068== in frame #1, created by caml_terminate_signals (???:) (cherry picked from libnbd commit 73dec295f3bbdf8afbfd548eb5a776dee27b0ac0) (cherry picked from commit e586ca6)
libguestfs
pushed a commit
that referenced
this issue
Jul 6, 2022
After discussion with the OCaml team we think these are both bugs in valgrind, not OCaml, but we still need a suppression. ==4145632== Syscall param sigaltstack(ss) points to uninitialised byte(s) ==4145632== at 0xCC5E24B: sigaltstack (syscall-template.S:120) ==4145632== by 0xD7F46CC: caml_stop_stack_overflow_detection (in /home/rjones/d/nbdkit/tests/test-ocaml-plugin.so) ==4145632== by 0xD7F277E: caml_startup_common (in /home/rjones/d/nbdkit/tests/test-ocaml-plugin.so) ==4145632== by 0xD7F27CC: caml_startup (in /home/rjones/d/nbdkit/tests/test-ocaml-plugin.so) ==4145632== by 0xC986891: constructor (plugin.c:64) ==4145632== by 0xC133CED: call_init (dl-init.c:70) ==4145632== by 0xC133DDB: _dl_init (dl-init.c:117) ==4145632== by 0xCD72A73: _dl_catch_exception (dl-error-skeleton.c:182) ==4145632== by 0xC13A955: dl_open_worker (dl-open.c:808) ==4145632== by 0xCD72A1D: _dl_catch_exception (dl-error-skeleton.c:208) ==4145632== by 0xC13ACEB: _dl_open (dl-open.c:883) ==4145632== by 0xCCA7EC9: dlopen_doit (dlopen.c:56) ==4145632== by 0xCD72A1D: _dl_catch_exception (dl-error-skeleton.c:208) ==4145632== by 0xCD72AD2: _dl_catch_error (dl-error-skeleton.c:227) ==4145632== by 0xCCA79DE: _dlerror_run (dlerror.c:138) ==4145632== by 0xCCA7F67: dlopen@@GLIBC_2.34 (dlopen.c:71) ==4145632== by 0x10F775: main (main.c:833) ==4145632== Address 0x1ffeffaca0 is on thread 1's stack ==4145632== in frame #1, created by caml_stop_stack_overflow_detection (???:) (cherry picked from commit dba71bf)
libguestfs
pushed a commit
that referenced
this issue
Aug 12, 2022
#0 __GI___libc_realloc (oldmem=0x40, bytes=bytes@entry=16) at malloc.c:3425 #1 0x00007fedb6bcf34d in __GI___getdelim ( lineptr=lineptr@entry=0x7fffd4d33b38, n=n@entry=0x7fffd4d33b30, delimiter=delimiter@entry=10, fp=fp@entry=0x55b5f0c166b0) at iogetdelim.c:102 #2 0x000055b5ef79a50b in getline (__stream=0x55b5f0c166b0, __n=0x7fffd4d33b30, __lineptr=0x7fffd4d33b38) at /usr/include/bits/stdio.h:120 #3 run_test () at /home/rjones/d/nbdkit/tests/test-exit-with-parent.c:185 #4 main (argc=<optimized out>, argv=<optimized out>) at /home/rjones/d/nbdkit/tests/test-exit-with-parent.c:66 pidstr (passed by reference to getline) was uninitialized. However this code path was never called at all because of an incorrect test of the exit status of the subprocess fixed in the following commit.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: