The varlink.org Website
varlink / libvarlink Goto Github PK
View Code? Open in Web Editor NEWC implementation of the Varlink protocol and command line tool
License: Apache License 2.0
C implementation of the Varlink protocol and command line tool
License: Apache License 2.0
The varlink.org Website
Packit failed on creating pull-requests in dist-git:
dist-git branch | error |
---|---|
f33 |
Release was not found. |
f34 |
Release was not found. |
f35 |
Release was not found. |
main |
Release was not found. |
You can retrigger the update by adding a comment (/packit propose-downstream
) into this issue.
Would it be possible to add named pipes/FIFOs as a transport for varlink (the ideals say any connection oriented transport can possibly work).
What happened
An error occurred when I run make build
:
Build started at 2020-01-24T23:57:56.374049
Main binary: /usr/local/opt/python/bin/python3.7
Build Options:
Python system: Darwin
The Meson build system
Version: 0.53.0
Source dir: /Users/shaneing/local/libvarlink/libvarlink
Build dir: /Users/shaneing/local/libvarlink/libvarlink/build
Build type: native build
Project name: libvarlink
Project version: 18
No CFLAGS in the environment, not changing global flags.
No LDFLAGS in the environment, not changing global flags.
No CPPFLAGS in the environment, not changing global flags.
Sanity testing C compiler: cc
Is cross compiler: False.
Sanity check compiler command line: cc /Users/shaneing/local/libvarlink/libvarlink/build/meson-private/sanitycheckc.c -o /Users/shaneing/local/libvarlink/libvarlink/build/meson-private/sanitycheckc.exe -pipe
Sanity check compile stdout:
-----
Sanity check compile stderr:
-----
Running test binary command: /Users/shaneing/local/libvarlink/libvarlink/build/meson-private/sanitycheckc.exe
C compiler for the build machine: cc (clang 11.0.0 "Apple clang version 11.0.0 (clang-1100.0.33.16)")
C linker for the build machine: cc APPLE ld 530
No CFLAGS in the environment, not changing global flags.
No LDFLAGS in the environment, not changing global flags.
No CPPFLAGS in the environment, not changing global flags.
Sanity testing C compiler: cc
Is cross compiler: False.
Sanity check compiler command line: cc /Users/shaneing/local/libvarlink/libvarlink/build/meson-private/sanitycheckc.c -o /Users/shaneing/local/libvarlink/libvarlink/build/meson-private/sanitycheckc.exe -pipe
Sanity check compile stdout:
-----
Sanity check compile stderr:
-----
Running test binary command: /Users/shaneing/local/libvarlink/libvarlink/build/meson-private/sanitycheckc.exe
C compiler for the host machine: cc (clang 11.0.0 "Apple clang version 11.0.0 (clang-1100.0.33.16)")
C linker for the host machine: cc APPLE ld 530
Build machine cpu family: x86_64
Build machine cpu: x86_64
Host machine cpu family: x86_64
Host machine cpu: x86_64
Target machine cpu family: x86_64
Target machine cpu: x86_64
Running compile:
Working directory: /Users/shaneing/local/libvarlink/libvarlink/build/meson-private/tmpiiit8w7y
Command line: cc /Users/shaneing/local/libvarlink/libvarlink/build/meson-private/tmpiiit8w7y/testfile.c -o /Users/shaneing/local/libvarlink/libvarlink/build/meson-private/tmpiiit8w7y/output.exe -pipe -O0 -lm -Wl,-undefined,dynamic_lookup
Code:
int main(void) { return 0; }
Compiler stdout:
Compiler stderr:
Library m found: YES
Configuring config.h using configuration
Program ./varlink-wrapper.py found: YES (/Users/shaneing/local/libvarlink/libvarlink/./varlink-wrapper.py)
Configuring libvarlink.pc using configuration
Adding test "test-interface"
Adding test "test-server-client"
Adding test "test-object"
Adding test "test-array"
Adding test "test-type"
Adding test "test-error"
Adding test "test-avl"
Program test-symbols.sh found: YES (/Users/shaneing/local/libvarlink/libvarlink/lib/test-symbols.sh)
Adding test "test-symbols"
Program git found: YES (/usr/bin/git)
Running command: /usr/bin/git --git-dir=/Users/shaneing/local/libvarlink/libvarlink/.git ls-files :/*.[ch]
--- stdout ---
lib/array.c
lib/array.h
lib/avltree.c
lib/avltree.h
lib/connection.c
lib/connection.h
lib/error.c
lib/interface.c
lib/interface.h
lib/message.c
lib/message.h
lib/object.c
lib/object.h
lib/scanner.c
lib/scanner.h
lib/service.c
lib/service.h
lib/stream.c
lib/stream.h
lib/test-array.c
lib/test-avl.c
lib/test-error.c
lib/test-interface.c
lib/test-object.c
lib/test-server-client.c
lib/test-type.c
lib/transport-device.c
lib/transport-tcp.c
lib/transport-unix.c
lib/transport.c
lib/transport.h
lib/type.c
lib/type.h
lib/uri.c
lib/uri.h
lib/util.c
lib/util.h
lib/value.c
lib/value.h
lib/varlink.h
tool/cli-activate.c
tool/cli-bridge.c
tool/cli.c
tool/cli.h
tool/command-bridge.c
tool/command-call.c
tool/command-complete.c
tool/command-format.c
tool/command-help.c
tool/command-info.c
tool/command-resolve.c
tool/command.c
tool/command.h
tool/main.c
tool/terminal-colors.c
tool/terminal-colors.h
--- stderr ---
Build targets in project: 13
Found ninja-1.9.0 at /usr/local/bin/ninja
Running compile:
Working directory: /Users/shaneing/local/libvarlink/libvarlink/build/meson-private/tmpr_uj9ea3
Command line: cc /Users/shaneing/local/libvarlink/libvarlink/build/meson-private/tmpr_uj9ea3/testfile.c -o /Users/shaneing/local/libvarlink/libvarlink/build/meson-private/tmpr_uj9ea3/output.obj -pipe -c -O0 --print-search-dirs
Code:
Compiler stdout:
programs: =/Library/Developer/CommandLineTools/usr/bin
libraries: =/Library/Developer/CommandLineTools/usr/lib/clang/11.0.0
Compiler stderr:
ERROR: Multiple producers for Ninja target "ctags". Please rename your targets.
Fix the tests:
git describe
22-6-g5bb62f6
printf '{"":0,"":1}}\0' | ./build/tool/varlink bridge
=================================================================
==1474995==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1 byte(s) in 1 object(s) allocated from:
#0 0x7fb5f4c158f7 in strdup (/lib64/libasan.so.6+0x598f7)
#1 0x427bb4 in object_add_field ../lib/object.c:48
#2 0x4284d2 in varlink_object_new_from_scanner ../lib/object.c:115
#3 0x4289c6 in varlink_object_new_from_json ../lib/object.c:153
#4 0x434a35 in varlink_stream_read ../lib/stream.c:229
#5 0x40b67b in handleBridge ../tool/command-bridge.c:147
#6 0x40cfa5 in bridge_run ../tool/command-bridge.c:339
#7 0x4079c9 in cli_run ../tool/cli.c:496
#8 0x41450c in main ../tool/main.c:14
#9 0x7fb5f408443f in __libc_start_call_main (/lib64/libc.so.6+0x4043f)
SUMMARY: AddressSanitizer: 1 byte(s) leaked in 1 allocation(s).
The non-blocking I/O socket code in varlink_stream_read() / varlink_stream_flush() handles EAGAIN already. It should be an easy thing to also handle EWOULDBLOCK:
From the write() man page:
EAGAIN or EWOULDBLOCK
The file descriptor fd refers to a socket and has been marked non-blocking (O_NONBLOCK), and the write would block. POSIX.1-2001 allows either error to be returned for this case, and does not require these constants to have the same value, so a portable application should check for both possibilities.
Looking at the code again today, support for EINTR should also be added to varlink_stream_read() and varlink_stream_flush(). Otherwise the code errors out during normal signal delivery.
Fix the tests, which segfault in tests-json/SEGFAULTS
by introducing a recursive limit.
ERROR: Multiple producers for Ninja target "ctags". Please rename your targets.
The varlinkctl
utility in systemd supports fork+execve'ing a process rather than utilizing the traditional method of connecting to an existing UNIX socket.
When invoking an executable in this manner, it creates a connected UNIX socket via socketpair
and passes one end to the executable as file descriptor 3.
varlinkctl call ./a.out com.example.Method '{}'
Passing this file descriptor as listen_fd
to varlink_service_new
fails as the library attempts to call accept4
on the connected socket.
It would be great if varlink_service_new
detects whether listen_fd
is a connected UNIX socket, rather than a listening socket, and assumes it's an already accepted connection.
Systemd's Varlink services do roughly this to tell if the file descriptor is a listening socket passed by the service's corresponding .socket
unit, or is directly invoked via varlinkctl
:
int b;
socklen_t l = sizeof(b);
if (getsockopt(listen_fd, SOL_SOCKET, SO_ACCEPTCONN, &b, &l) < 0) {
// TODO: errno
}
if (b) {
// This is a listening socket
} else {
// This is a connected socket
}
I did a quick hack using libvarlink from the glib main loop and noticed in connection.c that things are using EPOLLIN
and EPOLLOUT
constants from sys/epoll.h
directly. Given that some projects will need to stay vaguely portable, is it worth modifying these to use the posix POLLIN
/POLLOUT
?
Given that varlink intends to be OS-agnostic, it would be sensible for its reference implementation to be portable.
At present, though, this library only compiles on Linux. Nothing in varlink.h, though, seems to imply a hard need for Linux.
It looks like it would entail:
https://podman.io/blogs/2020/08/01/deprecate-and-remove-varlink-notice.html states "About one year ago, the Podman team was notified that the varlink library was being deprecated and there would be no further development and little support for it from the varlink library team." but not such notice is visible here or on https://varlink.org/. It would be great to clarify this.
/packit propose-update
varlink tool should include completion for fish shell.
CC=clang meson -Db_sanitize=address -Db_lundef=false build
meson test -C ./build/ --print-errorlog test-server-client
ninja: Entering directory `/libvarlink/build'
ninja: no work to do.
1/1 test-server-client FAIL 0.30s exit status 1
>>> MALLOC_PERTURB_=82 /libvarlink/build/lib/test-server-client
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
stderr:
=================================================================
==2638==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000000b10 at pc 0x00000052a1ed bp 0x7ffff15b0230 sp 0x7ffff15b0228
READ of size 8 at 0x606000000b10 thread T0
#0 0x52a1ec in varlink_call_reply /libvarlink/build/../lib/service.c:660:23
#1 0x518172 in org_varlink_example_Echo /libvarlink/build/../lib/test-server-client.c:33:9
#2 0x526bb2 in varlink_service_method_callback /libvarlink/build/../lib/service.c:282:16
#3 0x5298f2 in varlink_service_dispatch_connection /libvarlink/build/../lib/service.c:555:29
#4 0x528bee in varlink_service_process_events /libvarlink/build/../lib/service.c:604:29
#5 0x518a8e in test_process_events /libvarlink/build/../lib/test-server-client.c:66:25
#6 0x5173e5 in main /libvarlink/build/../lib/test-server-client.c:155:25
#7 0x7fb5e6f4750f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) (BuildId: 765237b0355c030ff41d969eedcb87bfccb43595)
#8 0x7fb5e6f475c8 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x275c8) (BuildId: 765237b0355c030ff41d969eedcb87bfccb43595)
#9 0x41e414 in _start (/libvarlink/build/lib/test-server-client+0x41e414) (BuildId: 895f2f71b3295e0d2de926f12b3f985f4b8f704d)
0x606000000b10 is located 16 bytes inside of 64-byte region [0x606000000b00,0x606000000b40)
freed by thread T0 here:
#0 0x4d2138 in __interceptor_free.part.0 asan_malloc_linux.cpp.o
#1 0x52523c in varlink_call_unref /libvarlink/build/../lib/service.c:101:17
#2 0x52a1bf in varlink_call_reply /libvarlink/build/../lib/service.c:660:42
#3 0x518172 in org_varlink_example_Echo /libvarlink/build/../lib/test-server-client.c:33:9
#4 0x526bb2 in varlink_service_method_callback /libvarlink/build/../lib/service.c:282:16
#5 0x5298f2 in varlink_service_dispatch_connection /libvarlink/build/../lib/service.c:555:29
#6 0x528bee in varlink_service_process_events /libvarlink/build/../lib/service.c:604:29
#7 0x518a8e in test_process_events /libvarlink/build/../lib/test-server-client.c:66:25
#8 0x5173e5 in main /libvarlink/build/../lib/test-server-client.c:155:25
#9 0x7fb5e6f4750f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) (BuildId: 765237b0355c030ff41d969eedcb87bfccb43595)
previously allocated by thread T0 here:
#0 0x4d3457 in __interceptor_calloc (/libvarlink/build/lib/test-server-client+0x4d3457) (BuildId: 895f2f71b3295e0d2de926f12b3f985f4b8f704d)
#1 0x52b8df in varlink_call_new /libvarlink/build/../lib/service.c:69:16
#2 0x52970e in varlink_service_dispatch_connection /libvarlink/build/../lib/service.c:551:29
#3 0x528bee in varlink_service_process_events /libvarlink/build/../lib/service.c:604:29
#4 0x518a8e in test_process_events /libvarlink/build/../lib/test-server-client.c:66:25
#5 0x5173e5 in main /libvarlink/build/../lib/test-server-client.c:155:25
#6 0x7fb5e6f4750f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) (BuildId: 765237b0355c030ff41d969eedcb87bfccb43595)
SUMMARY: AddressSanitizer: heap-use-after-free /libvarlink/build/../lib/service.c:660:23 in varlink_call_reply
Shadow bytes around the buggy address:
0x0c0c7fff8110: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00
0x0c0c7fff8120: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa
0x0c0c7fff8130: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
0x0c0c7fff8140: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00
0x0c0c7fff8150: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa
=>0x0c0c7fff8160: fd fd[fd]fd fd fd fd fd fa fa fa fa fa fa fa fa
0x0c0c7fff8170: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0c7fff8180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0c7fff8190: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0c7fff81a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0c7fff81b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==2638==ABORTING
This is a kind request to change the versioning scheme from the current incremental-integer scheme to something more expressive, e.g., to semantic versioning (https://semver.org/).
For packaging varlink, it would be really nice to provide a changelog for each release. I've recently added a simple make target to Podman to facilitate this task (see https://github.com/projectatomic/libpod/blob/master/Makefile#L168).
Here is the current workaround:
sed -e 's|/usr/bin/python3|/usr/bin/env python3|' -i varlink-wrapper.py
The rest of the FreeDesktop projects (including e.g. D-Bus) are hosted there.
There's some statistical evidence that most programmers evaluate, and learn how to use, libraries by their examples included with the project. So, it would be a good idea to include some examples for the C library so that C program authors will have a good idea about what's involved in getting this integrated with their projects.
lib/stream.c:varlink_stream_bridge() switches the client/server sockets to non-blocking mode. At least the write() call should handle the non-fatal errno codes EAGAIN, EWOULDBLOCK and EINTR from write(). Otherwise silent data loss occurs.
Ideally the read() code does the same, so it doesn't need to re-enter the function to keep bridging data.
I've noticed this issue during a manual audit for these specific problems as we evaluate varlink as our next-gen IPC. We have painful experience with non-blocking sockets for 19+ years ;) We'll probably extend varlink for our use with netstring encapsulation during transport in a backward-compatible way as JSON data always starts with '{' or '['.
Hi Harald,
while starting the review of #20, I did a fresh clone of the libvarlink repo on Fedora 31.
I just tried running "make" in the top source and the build failed with this:
$ make
meson build
The Meson build system
Version: 0.53.1
Source dir: /tmp/libvarlink
Build dir: /tmp/libvarlink/build
Build type: native build
Project name: libvarlink
Project version: 18
C compiler for the host machine: ccache cc (gcc 9.2.1 "cc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)")
C linker for the host machine: cc GNU ld.bfd 2.32-31
Host machine cpu family: x86_64
Host machine cpu: x86_64
Library m found: YES
Configuring config.h using configuration
Program ./varlink-wrapper.py found: YES (/tmp/libvarlink/./varlink-wrapper.py)
Configuring libvarlink.pc using configuration
Program test-symbols.sh found: YES (/tmp/libvarlink/lib/test-symbols.sh)
Program git found: YES (/usr/bin/git)
Build targets in project: 13
Found ninja-1.9.0 at /usr/bin/ninja
ERROR: Multiple producers for Ninja target "ctags". Please rename your targets.
A full log can be found at /tmp/libvarlink/build/meson-logs/meson-log.txt
When I remove the "tags" / "ctags" custom target from meson.build, libvarlink builds just fine.
Any idea?
Cheers,
Thomas
+ /usr/bin/meson test -C x86_64-redhat-linux-gnu --num-processes 48 --print-errorlogs
ninja: Entering directory `/home/tkloczko/rpmbuild/BUILD/libvarlink-21/x86_64-redhat-linux-gnu'
ninja: no work to do.
1/8 test-interface OK 0.07s
2/8 test-object OK 0.06s
3/8 test-array OK 0.05s
4/8 test-type OK 0.05s
5/8 test-error OK 0.04s
6/8 test-avl OK 0.03s
7/8 test-server-client OK 0.07s
8/8 test-symbols FAIL 0.06s exit status 1
>>> MALLOC_PERTURB_=22 /home/tkloczko/rpmbuild/BUILD/libvarlink-21/lib/test-symbols.sh /home/tkloczko/rpmbuild/BUILD/libvarlink-21/lib/libvarlink.sym /home/tkloczko/rpmbuild/BUILD/libvarlink-21/x86_64-redhat-linux-gnu/lib/libvarlink.a
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
stdout:
--- symbols.list 2021-02-23 13:17:40.414761875 +0000
+++ symbols.lib 2021-02-23 13:17:40.455761897 +0000
@@ -0,0 +1,68 @@
+varlink_array_append_array
+varlink_array_append_bool
+varlink_array_append_float
+varlink_array_append_int
+varlink_array_append_null
+varlink_array_append_object
+varlink_array_append_string
+varlink_array_get_array
+varlink_array_get_bool
+varlink_array_get_float
+varlink_array_get_int
+varlink_array_get_n_elements
+varlink_array_get_object
+varlink_array_get_string
+varlink_array_new
+varlink_array_ref
+varlink_array_unref
+varlink_array_unrefp
+varlink_call_get_connection_fd
+varlink_call_get_connection_userdata
+varlink_call_get_method
+varlink_call_ref
+varlink_call_reply
+varlink_call_reply_error
+varlink_call_reply_invalid_parameter
+varlink_call_set_connection_closed_callback
+varlink_call_unref
+varlink_call_unrefp
+varlink_connection_call
+varlink_connection_close
+varlink_connection_free
+varlink_connection_freep
+varlink_connection_get_events
+varlink_connection_get_fd
+varlink_connection_get_userdata
+varlink_connection_is_closed
+varlink_connection_new
+varlink_connection_process_events
+varlink_connection_set_closed_callback
+varlink_error_string
+varlink_listen
+varlink_object_get_array
+varlink_object_get_bool
+varlink_object_get_field_names
+varlink_object_get_float
+varlink_object_get_int
+varlink_object_get_object
+varlink_object_get_string
+varlink_object_new
+varlink_object_new_from_json
+varlink_object_ref
+varlink_object_set_array
+varlink_object_set_bool
+varlink_object_set_float
+varlink_object_set_int
+varlink_object_set_null
+varlink_object_set_object
+varlink_object_set_string
+varlink_object_to_json
+varlink_object_unref
+varlink_object_unrefp
+varlink_service_add_interface
+varlink_service_free
+varlink_service_freep
+varlink_service_get_fd
+varlink_service_new
+varlink_service_new_raw
+varlink_service_process_events
stderr:
+ set -e
+ libvarlink_sym=/home/tkloczko/rpmbuild/BUILD/libvarlink-21/lib/libvarlink.sym
+ libvarlink_a=/home/tkloczko/rpmbuild/BUILD/libvarlink-21/x86_64-redhat-linux-gnu/lib/libvarlink.a
+ which readelf
+ test -e /home/tkloczko/rpmbuild/BUILD/libvarlink-21/lib/libvarlink.sym
+ test -e /home/tkloczko/rpmbuild/BUILD/libvarlink-21/x86_64-redhat-linux-gnu/lib/libvarlink.a
+ rm -f symbols.list symbols.lib
+ readelf -s -W /home/tkloczko/rpmbuild/BUILD/libvarlink-21/x86_64-redhat-linux-gnu/lib/libvarlink.a
+ grep 'FUNC GLOBAL DEFAULT.*varlink_'
+ awk '{ print $8 }'
+ sort
+ grep varlink_ /home/tkloczko/rpmbuild/BUILD/libvarlink-21/lib/libvarlink.sym
+ sed 's/[ ;]//g'
+ sort
+ diff -u symbols.list symbols.lib
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
Summary of Failures:
8/8 test-symbols FAIL 0.06s exit status 1
Ok: 7
Expected Fail: 0
Fail: 1
Unexpected Pass: 0
Skipped: 0
Timeout: 0
Tests are failing on powerpc on Alpine Linux.
Alpine merge request and job log for powerpc build
In case the job goes away, here it is attached.
The tests pass on every other architecture, so I'm not sure why it would be failing on powerpc. I don't know much about the differences and don't have real powerpc hardware to test on, just the Alpine builders, but I can assist with testing where possible.
meson build
ninja -C ./build
printf '{"":[\0' | valgrind --track-origins=yes ./build/tool/varlink bridge
==2931== Memcheck, a memory error detector
==2931== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2931== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info
==2931== Command: ./build/tool/varlink bridge
==2931==
==2931== Conditional jump or move depends on uninitialised value(s)
==2931== at 0x410C7A: varlink_value_clear (value.c:13)
==2931== by 0x4073CA: varlink_array_unref (array.c:110)
==2931== by 0x407427: varlink_array_unrefp (array.c:121)
==2931== by 0x407352: varlink_array_new_from_scanner (array.c:54)
==2931== by 0x410DAE: varlink_value_read_from_scanner (value.c:56)
==2931== by 0x40B0FD: varlink_object_new_from_scanner (object.c:122)
==2931== by 0x40B247: varlink_object_new_from_json (object.c:156)
==2931== by 0x40DDB9: varlink_stream_read (stream.c:229)
==2931== by 0x40448C: handleBridge (command-bridge.c:147)
==2931== by 0x404C63: bridge_run (command-bridge.c:339)
==2931== by 0x40353B: cli_run (cli.c:496)
==2931== by 0x40700D: main (main.c:14)
==2931== Uninitialised value was created by a heap allocation
==2931== at 0x484378A: malloc (vg_replace_malloc.c:392)
==2931== by 0x484870B: realloc (vg_replace_malloc.c:1451)
==2931== by 0x4070DF: array_append (array.c:22)
==2931== by 0x407276: varlink_array_new_from_scanner (array.c:73)
==2931== by 0x410DAE: varlink_value_read_from_scanner (value.c:56)
==2931== by 0x40B0FD: varlink_object_new_from_scanner (object.c:122)
==2931== by 0x40B247: varlink_object_new_from_json (object.c:156)
==2931== by 0x40DDB9: varlink_stream_read (stream.c:229)
==2931== by 0x40448C: handleBridge (command-bridge.c:147)
==2931== by 0x404C63: bridge_run (command-bridge.c:339)
==2931== by 0x40353B: cli_run (cli.c:496)
==2931== by 0x40700D: main (main.c:14)
==2931==
==2931== Conditional jump or move depends on uninitialised value(s)
==2931== at 0x410C7F: varlink_value_clear (value.c:13)
==2931== by 0x4073CA: varlink_array_unref (array.c:110)
==2931== by 0x407427: varlink_array_unrefp (array.c:121)
==2931== by 0x407352: varlink_array_new_from_scanner (array.c:54)
==2931== by 0x410DAE: varlink_value_read_from_scanner (value.c:56)
==2931== by 0x40B0FD: varlink_object_new_from_scanner (object.c:122)
==2931== by 0x40B247: varlink_object_new_from_json (object.c:156)
==2931== by 0x40DDB9: varlink_stream_read (stream.c:229)
==2931== by 0x40448C: handleBridge (command-bridge.c:147)
==2931== by 0x404C63: bridge_run (command-bridge.c:339)
==2931== by 0x40353B: cli_run (cli.c:496)
==2931== by 0x40700D: main (main.c:14)
==2931== Uninitialised value was created by a heap allocation
==2931== at 0x484378A: malloc (vg_replace_malloc.c:392)
==2931== by 0x484870B: realloc (vg_replace_malloc.c:1451)
==2931== by 0x4070DF: array_append (array.c:22)
==2931== by 0x407276: varlink_array_new_from_scanner (array.c:73)
==2931== by 0x410DAE: varlink_value_read_from_scanner (value.c:56)
==2931== by 0x40B0FD: varlink_object_new_from_scanner (object.c:122)
==2931== by 0x40B247: varlink_object_new_from_json (object.c:156)
==2931== by 0x40DDB9: varlink_stream_read (stream.c:229)
==2931== by 0x40448C: handleBridge (command-bridge.c:147)
==2931== by 0x404C63: bridge_run (command-bridge.c:339)
==2931== by 0x40353B: cli_run (cli.c:496)
==2931== by 0x40700D: main (main.c:14)
==2931==
==2931== Conditional jump or move depends on uninitialised value(s)
==2931== at 0x410C84: varlink_value_clear (value.c:13)
==2931== by 0x4073CA: varlink_array_unref (array.c:110)
==2931== by 0x407427: varlink_array_unrefp (array.c:121)
==2931== by 0x407352: varlink_array_new_from_scanner (array.c:54)
==2931== by 0x410DAE: varlink_value_read_from_scanner (value.c:56)
==2931== by 0x40B0FD: varlink_object_new_from_scanner (object.c:122)
==2931== by 0x40B247: varlink_object_new_from_json (object.c:156)
==2931== by 0x40DDB9: varlink_stream_read (stream.c:229)
==2931== by 0x40448C: handleBridge (command-bridge.c:147)
==2931== by 0x404C63: bridge_run (command-bridge.c:339)
==2931== by 0x40353B: cli_run (cli.c:496)
==2931== by 0x40700D: main (main.c:14)
==2931== Uninitialised value was created by a heap allocation
==2931== at 0x484378A: malloc (vg_replace_malloc.c:392)
==2931== by 0x484870B: realloc (vg_replace_malloc.c:1451)
==2931== by 0x4070DF: array_append (array.c:22)
==2931== by 0x407276: varlink_array_new_from_scanner (array.c:73)
==2931== by 0x410DAE: varlink_value_read_from_scanner (value.c:56)
==2931== by 0x40B0FD: varlink_object_new_from_scanner (object.c:122)
==2931== by 0x40B247: varlink_object_new_from_json (object.c:156)
==2931== by 0x40DDB9: varlink_stream_read (stream.c:229)
==2931== by 0x40448C: handleBridge (command-bridge.c:147)
==2931== by 0x404C63: bridge_run (command-bridge.c:339)
==2931== by 0x40353B: cli_run (cli.c:496)
==2931== by 0x40700D: main (main.c:14)
==2931==
==2931== Conditional jump or move depends on uninitialised value(s)
==2931== at 0x410C89: varlink_value_clear (value.c:13)
==2931== by 0x4073CA: varlink_array_unref (array.c:110)
==2931== by 0x407427: varlink_array_unrefp (array.c:121)
==2931== by 0x407352: varlink_array_new_from_scanner (array.c:54)
==2931== by 0x410DAE: varlink_value_read_from_scanner (value.c:56)
==2931== by 0x40B0FD: varlink_object_new_from_scanner (object.c:122)
==2931== by 0x40B247: varlink_object_new_from_json (object.c:156)
==2931== by 0x40DDB9: varlink_stream_read (stream.c:229)
==2931== by 0x40448C: handleBridge (command-bridge.c:147)
==2931== by 0x404C63: bridge_run (command-bridge.c:339)
==2931== by 0x40353B: cli_run (cli.c:496)
==2931== by 0x40700D: main (main.c:14)
==2931== Uninitialised value was created by a heap allocation
==2931== at 0x484378A: malloc (vg_replace_malloc.c:392)
==2931== by 0x484870B: realloc (vg_replace_malloc.c:1451)
==2931== by 0x4070DF: array_append (array.c:22)
==2931== by 0x407276: varlink_array_new_from_scanner (array.c:73)
==2931== by 0x410DAE: varlink_value_read_from_scanner (value.c:56)
==2931== by 0x40B0FD: varlink_object_new_from_scanner (object.c:122)
==2931== by 0x40B247: varlink_object_new_from_json (object.c:156)
==2931== by 0x40DDB9: varlink_stream_read (stream.c:229)
==2931== by 0x40448C: handleBridge (command-bridge.c:147)
==2931== by 0x404C63: bridge_run (command-bridge.c:339)
==2931== by 0x40353B: cli_run (cli.c:496)
==2931== by 0x40700D: main (main.c:14)
==2931==
==2931== Conditional jump or move depends on uninitialised value(s)
==2931== at 0x410C8E: varlink_value_clear (value.c:13)
==2931== by 0x4073CA: varlink_array_unref (array.c:110)
==2931== by 0x407427: varlink_array_unrefp (array.c:121)
==2931== by 0x407352: varlink_array_new_from_scanner (array.c:54)
==2931== by 0x410DAE: varlink_value_read_from_scanner (value.c:56)
==2931== by 0x40B0FD: varlink_object_new_from_scanner (object.c:122)
==2931== by 0x40B247: varlink_object_new_from_json (object.c:156)
==2931== by 0x40DDB9: varlink_stream_read (stream.c:229)
==2931== by 0x40448C: handleBridge (command-bridge.c:147)
==2931== by 0x404C63: bridge_run (command-bridge.c:339)
==2931== by 0x40353B: cli_run (cli.c:496)
==2931== by 0x40700D: main (main.c:14)
==2931== Uninitialised value was created by a heap allocation
==2931== at 0x484378A: malloc (vg_replace_malloc.c:392)
==2931== by 0x484870B: realloc (vg_replace_malloc.c:1451)
==2931== by 0x4070DF: array_append (array.c:22)
==2931== by 0x407276: varlink_array_new_from_scanner (array.c:73)
==2931== by 0x410DAE: varlink_value_read_from_scanner (value.c:56)
==2931== by 0x40B0FD: varlink_object_new_from_scanner (object.c:122)
==2931== by 0x40B247: varlink_object_new_from_json (object.c:156)
==2931== by 0x40DDB9: varlink_stream_read (stream.c:229)
==2931== by 0x40448C: handleBridge (command-bridge.c:147)
==2931== by 0x404C63: bridge_run (command-bridge.c:339)
==2931== by 0x40353B: cli_run (cli.c:496)
==2931== by 0x40700D: main (main.c:14)
==2931==
==2931==
I am confused, in what case this hasn't already be done properly by the kernel before allowing the connection ?
libvarlink/lib/transport-unix.c
Line 226 in bd4cd60
Since this seems to be more alive then the respective interfaces (cough cough cherry-pick/com.redhat.resolver#2)....
What is one supposed to do if he wants to use varlink + the std interfaces on some small system (just C runtime available)?
There seems to be multiple implementations in various languages for everything with the C part looking more like an afterthought.
varlink <tab><tab>
allows identifying local services, but for convenience (and discoverability) varlink ls
or alike would be nice.
Not that I am a fan of grpc - but how does varlink compare to it?
What benefits does valrink have which makes it so much better suited for the OS use-case?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.