varlink / libvarlink Goto Github PK

View Code? Open in Web Editor NEW

87.0 4.0 16.0 540 KB

C implementation of the Varlink protocol and command line tool

License: Apache License 2.0

Makefile 0.13% Shell 0.28% C 97.10% Emacs Lisp 0.36% Meson 1.87% Python 0.12% Vim Script 0.15%

ipc json varlink

libvarlink's Introduction

The varlink.org Website

libvarlink's People

Contributors

Stargazers

Watchers

Forkers

keszybz whot afbjorklund boot2podman gragonvlad larskarlitski lsm5 thomasjfox haraldh ericonr mc964203886 t-8ch evverx icodein scabrero valpackett

libvarlink's Issues

non-blocking sockets: Handle EWOULDBLOCK as EAGAIN

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 failing tests in tests-json/FAILS

Fix the tests:

Named PIPES as a backend

Would it be possible to add named pipes/FIFOs as a transport for varlink (the ideals say any connection oriented transport can possibly work).

RFE: Portability

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:

Use portable nonblock/cloexec.
Refactor epoll usage to tools.

Use python3 from path, instead of hardcoding /usr/bin

Here is the current workaround:

sed -e 's|/usr/bin/python3|/usr/bin/env python3|' -i varlink-wrapper.py

Build failure: Multiple producers for Ninja target "ctags"

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

Fix tests-json/SEGFAULTS

Fix the tests, which segfault in tests-json/SEGFAULTS by introducing a recursive limit.

test packit

/packit propose-update

21: test suite is failing

+ /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

versioning scheme and changelogs

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).

varlink_stream_bridge() will silently discard data

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 '['.

deprecated or not?

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.

Test '64/326 test-symbols' failing on ppc64le on Alpine Linux

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.

job.log

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.

Support Varlink connection on an existing, connected UNIX socket

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
}

Why do user space cred checks this way ?

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

if (!check_credentials(sb.st_mode, sb.st_uid, sb.st_gid,

Build error with newer meson and ninja

ERROR: Multiple producers for Ninja target "ctags". Please rename your targets.

Fish shell completion

varlink tool should include completion for fish shell.

Implementation for varlinks std interfaces

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.

Conditional jump or move depends on uninitialised value(s) in varlink_array_unrefp

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==

[packit] Propose downstream failed for release 23

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.

Consider moving to gitlab.freedesktop.org

The rest of the FreeDesktop projects (including e.g. D-Bus) are hosted there.

Allow lsiting service with varlink tool

varlink <tab><tab> allows identifying local services, but for convenience (and discoverability) varlink ls or alike would be nice.

grpc?

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?

Failed to build on MacOS

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.

Include C Examples

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.

EPOLL constants used in connection.c

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?

There seems to be a memory leak

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).

There seems to be a heap-use-after-free in test-server-client

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