Giter Club home page Giter Club logo

mini-async-log-c's People

Contributors

rafagago avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

mini-async-log-c's Issues

Question about formatting

I just had a small question on a design decision: why did you choose to write your own serialization rather than use an existing library like fmtlib, or simply vsnprintf? Was this to support lazy evaluation?

Thank you for all the work on the library - it looks great!

Linux build instructions fail on aarch64 because base library's CPU timept support is implemented only for x64/x86/IA64

Hi,

I'm investigating running mini-async-log-c on a Raspberry Pi to log some time-sensitive code. The Raspberry Pi is running the PiCAT 4 version of Raspberry Pi OS, aarch64. This version of Raspberry Pi OS is derived from Debian Buster 10.

I followed the readme's Linux build instructions for Debian/Ubuntu-type systems, but didn't get a successful build. The output from the meson process looks fairly reasonable to my inexperienced eyes:

pi@myhost:~/src/mini-async-log-c $ meson $MYBUILDDIR --buildtype=release
The Meson build system
Version: 1.1.0
Source dir: /home/pi/src/mini-async-log-c
Build dir: /home/pi/src/mini-async-log-c/build
Build type: native build
Project name: mini-async-log-c
Project version: 0.0.1
C compiler for the host machine: cc (gcc 8.3.0 "cc (Debian 8.3.0-6) 8.3.0")
C linker for the host machine: cc ld.bfd 2.31.1
C++ compiler for the host machine: c++ (gcc 8.3.0 "c++ (Debian 8.3.0-6) 8.3.0")
C++ linker for the host machine: c++ ld.bfd 2.31.1
Host machine cpu family: aarch64
Host machine cpu: aarch64

Executing subproject base_library

base_library| Project name: base_library
base_library| Project version: 0.1.0
base_library| C compiler for the host machine: cc (gcc 8.3.0 "cc (Debian 8.3.0-6) 8.3.0")
base_library| C linker for the host machine: cc ld.bfd 2.31.1
base_library| C++ compiler for the host machine: c++ (gcc 8.3.0 "c++ (Debian 8.3.0-6) 8.3.0")
base_library| C++ linker for the host machine: c++ ld.bfd 2.31.1
base_library| Downloading cmocka source from https://cmocka.org/files/1.1/cmocka-1.1.2.tar.xz
Download size: 82300
Downloading: ..........
base_library| Downloading cmocka patch from https://wrapdb.mesonbuild.com/v1/projects/cmocka/1.1.2/1/get_zip
Download size: 4226
Downloading: ..........

Executing subproject base_library:cmocka

cmocka| Project name: cmocka
cmocka| Project version: 1.1.2
cmocka| C compiler for the host machine: cc (gcc 8.3.0 "cc (Debian 8.3.0-6) 8.3.0")
cmocka| C linker for the host machine: cc ld.bfd 2.31.1
cmocka| Compiler for C supports arguments -Wshadow: YES
cmocka| Compiler for C supports arguments -Wmissing-prototypes: YES
cmocka| Compiler for C supports arguments -Wcast-align: YES
cmocka| Compiler for C supports arguments -Werror=address: YES
cmocka| Compiler for C supports arguments -Werror=strict-prototypes: YES
cmocka| Compiler for C supports arguments -Werror=write-strings: YES
cmocka| Compiler for C supports arguments -Werror=implicit-function-declaration: YES
cmocka| Compiler for C supports arguments -Werror=pointer-arith: YES
cmocka| Compiler for C supports arguments -Werror=declaration-after-statement: YES
cmocka| Compiler for C supports arguments -Werror=return-type: YES
cmocka| Compiler for C supports arguments -Werror=uninitialized: YES
cmocka| Compiler for C supports arguments -Wimplicit-fallthrough: YES
cmocka| Compiler for C supports arguments -Werror=strict-overflow: YES
cmocka| Compiler for C supports arguments -Wstrict-overflow=2: YES
cmocka| Compiler for C supports arguments -Wno-format-zero-length: YES
cmocka| Compiler for C supports arguments -Wformat: YES
cmocka| Compiler for C supports arguments -Werror=format-security: NO
cmocka| Compiler for C supports arguments -Wno-gnu-zero-variadic-macro-arguments: NO
cmocka| Compiler for C supports arguments -fno-common: YES
cmocka| Check usable header "assert.h" : YES
cmocka| Check usable header "inttypes.h" : YES
cmocka| Check usable header "io.h" : NO
cmocka| Check usable header "malloc.h" : YES
cmocka| Check usable header "memory.h" : YES
cmocka| Check usable header "setjmp.h" : YES
cmocka| Check usable header "signal.h" : YES
cmocka| Check usable header "stdarg.h" : YES
cmocka| Check usable header "stddef.h" : YES
cmocka| Check usable header "stdint.h" : YES
cmocka| Check usable header "stdio.h" : YES
cmocka| Check usable header "stdlib.h" : YES
cmocka| Check usable header "string.h" : YES
cmocka| Check usable header "strings.h" : YES
cmocka| Check usable header "sys/stat.h" : YES
cmocka| Check usable header "sys/types.h" : YES
cmocka| Check usable header "time.h" : YES
cmocka| Check usable header "unistd.h" : YES
cmocka| Checking whether type "struct timespec" has member "tv_sec" : YES
cmocka| Checking for function "calloc" : YES
cmocka| Checking for function "exit" : YES
cmocka| Checking for function "fprintf" : YES
cmocka| Checking for function "free" : YES
cmocka| Checking for function "longjmp" : YES
cmocka| Checking for function "siglongjmp" : YES
cmocka| Checking for function "malloc" : YES
cmocka| Checking for function "memcpy" : YES
cmocka| Checking for function "memset" : YES
cmocka| Checking for function "printf" : YES
cmocka| Checking for function "setjmp" : YES
cmocka| Checking for function "signal" : YES
cmocka| Checking for function "strsignal" : YES
cmocka| Checking for function "strcmp" : YES
cmocka| Checking for function "clock_gettime" : YES
cmocka| Checking for function "snprintf" : YES
cmocka| Checking for function "vsnprintf" : YES
cmocka| Checking if "Thread Local Storage" compiles: YES
cmocka| Library rt found: YES
cmocka| Header "time.h" has symbol "CLOCK_REALTIME" : YES
cmocka| Checking for size of "void *" : 8
cmocka| Configuring config.h using configuration
cmocka| Build targets in project: 1
cmocka| Subproject cmocka finished.

base_library| Run-time dependency threads found: YES
base_library| Configuring config.h using configuration
base_library| Build targets in project: 17
base_library| Subproject base_library finished.

Dependency threads found: YES unknown (cached)
Configuring config.h using configuration
Build targets in project: 45

mini-async-log-c 0.0.1

  Subprojects
    base_library: YES
    cmocka      : YES

  User defined options
    buildtype   : release

Found ninja-1.10.1 at /usr/bin/ninja
WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.

I'm not sure if the "missing usable header" for io.h is a problem. My system does have build-essential installed and I have various files named io.h under /usr/src/linux-headers-.....

Anyway, running the build with ninja $MYBUILDDIR fails, apparently on test code. C is not a language I'm very expert in, but these "implicit declaration of function" warnings look more like something basic is missing from the build environment, to me:

pi@myhost:~/src/mini-async-log-c $ ninja -C $MYBUILDDIR
ninja: Entering directory `build'
[87/155] Compiling C object subprojects/base_library/bl-t_extras-test.p/test_src_bl_time_extras_time_extras_test.c.o
In file included from ../subprojects/base_library/test/src/bl/cmocka_pre.h:18,
                 from ../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c:3:
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c: In function ‘bl_timept_to_sysclock_diff_test’:
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c:41:16: warning: implicit declaration of function ‘llabs’ [-Wimplicit-function-declaration]
   assert_true (llabs (diff2 - diff) <= (10 * bl_nsec_in_msec));
                ^~~~~
../subprojects/cmocka-1.1.2/include/cmocka.h:111:28: note: in definition of macro ‘cast_to_largest_integral_type’
     ((LargestIntegralType)(value))
                            ^~~~~
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c:41:3: note: in expansion of macro ‘assert_true’
   assert_true (llabs (diff2 - diff) <= (10 * bl_nsec_in_msec));
   ^~~~~~~~~~~
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c:41:16: warning: incompatible implicit declaration of built-in function ‘llabs’
   assert_true (llabs (diff2 - diff) <= (10 * bl_nsec_in_msec));
                ^~~~~
../subprojects/cmocka-1.1.2/include/cmocka.h:111:28: note: in definition of macro ‘cast_to_largest_integral_type’
     ((LargestIntegralType)(value))
                            ^~~~~
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c:41:3: note: in expansion of macro ‘assert_true’
   assert_true (llabs (diff2 - diff) <= (10 * bl_nsec_in_msec));
   ^~~~~~~~~~~
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c:41:16: note: include ‘<stdlib.h>’ or provide a declaration of ‘llabs’
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c:23:1:
+#include <stdlib.h>
 /*---------------------------------------------------------------------------*/
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c:41:16:
   assert_true (llabs (diff2 - diff) <= (10 * bl_nsec_in_msec));
                ^~~~~
../subprojects/cmocka-1.1.2/include/cmocka.h:111:28: note: in definition of macro ‘cast_to_largest_integral_type’
     ((LargestIntegralType)(value))
                            ^~~~~
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c:41:3: note: in expansion of macro ‘assert_true’
   assert_true (llabs (diff2 - diff) <= (10 * bl_nsec_in_msec));
   ^~~~~~~~~~~
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c: In function ‘bl_cpu_timept_vs_timept_test’:
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c:52:21: warning: implicit declaration of function ‘bl_cpu_timept_get’; did you mean ‘bl_fast_timept_get’? [-Wimplicit-function-declaration]
   bl_timept cprev = bl_cpu_timept_get();
                     ^~~~~~~~~~~~~~~~~
                     bl_fast_timept_get
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c:62:29: warning: implicit declaration of function ‘bl_cpu_timept_to_nsec’; did you mean ‘bl_fast_timept_to_nsec’? [-Wimplicit-function-declaration]
     double ratio = (double) bl_cpu_timept_to_nsec (c - cprev);
                             ^~~~~~~~~~~~~~~~~~~~~
                             bl_fast_timept_to_nsec
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c: In function ‘bl_cpu_timept_to_sysclock_diff_test’:
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c:79:23: warning: implicit declaration of function ‘bl_cpu_timept_to_sysclock64_diff_ns’; did you mean ‘bl_cpu_timept_to_sysclock_diff_test’? [-Wimplicit-function-declaration]
   bl_timeoft64 diff = bl_cpu_timept_to_sysclock64_diff_ns();
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                       bl_cpu_timept_to_sysclock_diff_test
In file included from ../subprojects/base_library/test/src/bl/cmocka_pre.h:18,
                 from ../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c:3:
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c:86:16: warning: incompatible implicit declaration of built-in function ‘llabs’
   assert_true (llabs (diff2 - diff) <= (10 * bl_nsec_in_msec));
                ^~~~~
../subprojects/cmocka-1.1.2/include/cmocka.h:111:28: note: in definition of macro ‘cast_to_largest_integral_type’
     ((LargestIntegralType)(value))
                            ^~~~~
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c:86:3: note: in expansion of macro ‘assert_true’
   assert_true (llabs (diff2 - diff) <= (10 * bl_nsec_in_msec));
   ^~~~~~~~~~~
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c:86:16: note: include ‘<stdlib.h>’ or provide a declaration of ‘llabs’
   assert_true (llabs (diff2 - diff) <= (10 * bl_nsec_in_msec));
                ^~~~~
../subprojects/cmocka-1.1.2/include/cmocka.h:111:28: note: in definition of macro ‘cast_to_largest_integral_type’
     ((LargestIntegralType)(value))
                            ^~~~~
../subprojects/base_library/test/src/bl/time_extras/time_extras_test.c:86:3: note: in expansion of macro ‘assert_true’
   assert_true (llabs (diff2 - diff) <= (10 * bl_nsec_in_msec));
   ^~~~~~~~~~~
[89/155] Linking target subprojects/base_library/bl-t_extras-test
FAILED: subprojects/base_library/bl-t_extras-test
cc  -o subprojects/base_library/bl-t_extras-test subprojects/base_library/bl-t_extras-test.p/test_src_bl_time_extras_time_extras_test.c.o subprojects/base_library/bl-t_extras-test.p/test_src_bl_time_extras_tests_main.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wl,--start-group subprojects/base_library/libbl-base.a subprojects/base_library/libbl-time-extras.a subprojects/cmocka-1.1.2/src/libcmocka.a -Wl,--end-group
/usr/bin/ld: subprojects/base_library/bl-t_extras-test.p/test_src_bl_time_extras_time_extras_test.c.o: in function `bl_cpu_timept_to_sysclock_diff_test':
time_extras_test.c:(.text+0x3c): undefined reference to `bl_cpu_timept_to_sysclock64_diff_ns'
/usr/bin/ld: time_extras_test.c:(.text+0xa4): undefined reference to `bl_cpu_timept_to_sysclock64_diff_ns'
/usr/bin/ld: subprojects/base_library/bl-t_extras-test.p/test_src_bl_time_extras_time_extras_test.c.o: in function `bl_cpu_timept_vs_timept_test':
time_extras_test.c:(.text+0x128): undefined reference to `bl_cpu_timept_get'
/usr/bin/ld: time_extras_test.c:(.text+0x164): undefined reference to `bl_cpu_timept_get'
/usr/bin/ld: time_extras_test.c:(.text+0x170): undefined reference to `bl_cpu_timept_to_nsec'
collect2: error: ld returned 1 exit status
[91/155] Compiling C++ object subprojects/base_library/bl-nonblo...c-bpm-relacy.p/test_src_bl_mpmc_bpm_relacy_mpmc_bpm_relacy.cpp.o
ninja: build stopped: subcommand failed.

Am I missing some dependency that I should have installed before attempting to build malc?

Re-running the build command generated slightly different output each time, but has eventually stabilised on the following:

pi@myhost:~/src/mini-async-log-c $ ninja -C $MYBUILDDIR
ninja: Entering directory `build'
[1/25] Linking target malc-smoke
FAILED: malc-smoke
cc  -o malc-smoke malc-smoke.p/test_src_malc-smoke_smoke.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wl,--start-group libmalc.a subprojects/base_library/libbl-base.a subprojects/base_library/libbl-nonblock.a subprojects/base_library/libbl-time-extras.a subprojects/base_library/libbl-tostr.a subprojects/cmocka-1.1.2/src/libcmocka.a -Wl,--end-group -pthread
/usr/bin/ld: libmalc.a(src_malc_malc.c.o): in function `malc_run_consume_task':
malc.c:(.text+0x6c4): undefined reference to `bl_nsec_to_cpu_timept_max'
/usr/bin/ld: malc.c:(.text+0x6d0): undefined reference to `bl_usec_to_cpu_timept_max'
/usr/bin/ld: malc.c:(.text+0x704): undefined reference to `bl_usec_to_cpu_timept'
/usr/bin/ld: malc.c:(.text+0xa00): undefined reference to `bl_cpu_timept_get'
collect2: error: ld returned 1 exit status
[2/25] Linking target subprojects/base_library/bl-t_extras-test
FAILED: subprojects/base_library/bl-t_extras-test
cc  -o subprojects/base_library/bl-t_extras-test subprojects/base_library/bl-t_extras-test.p/test_src_bl_time_extras_time_extras_test.c.o subprojects/base_library/bl-t_extras-test.p/test_src_bl_time_extras_tests_main.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wl,--start-group subprojects/base_library/libbl-base.a subprojects/base_library/libbl-time-extras.a subprojects/cmocka-1.1.2/src/libcmocka.a -Wl,--end-group
/usr/bin/ld: subprojects/base_library/bl-t_extras-test.p/test_src_bl_time_extras_time_extras_test.c.o: in function `bl_cpu_timept_to_sysclock_diff_test':
time_extras_test.c:(.text+0x3c): undefined reference to `bl_cpu_timept_to_sysclock64_diff_ns'
/usr/bin/ld: time_extras_test.c:(.text+0xa4): undefined reference to `bl_cpu_timept_to_sysclock64_diff_ns'
/usr/bin/ld: subprojects/base_library/bl-t_extras-test.p/test_src_bl_time_extras_time_extras_test.c.o: in function `bl_cpu_timept_vs_timept_test':
time_extras_test.c:(.text+0x128): undefined reference to `bl_cpu_timept_get'
/usr/bin/ld: time_extras_test.c:(.text+0x164): undefined reference to `bl_cpu_timept_get'
/usr/bin/ld: time_extras_test.c:(.text+0x170): undefined reference to `bl_cpu_timept_to_nsec'
collect2: error: ld returned 1 exit status
[3/25] Linking target malc-test
FAILED: malc-test
cc  -o malc-test malc-test.p/test_src_malc_tests_main.c.o malc-test.p/test_src_malc_tls_buffer_test.c.o malc-test.p/test_src_malc_bounded_buffer_test.c.o malc-test.p/test_src_malc_serialization_test.c.o malc-test.p/test_src_malc_entry_parser_test.c.o malc-test.p/test_src_malc_destinations_test.c.o malc-test.p/test_src_malc_array_destination_test.c.o malc-test.p/test_src_malc_file_destination_test.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wl,--start-group libmalc.a subprojects/base_library/libbl-base.a subprojects/base_library/libbl-nonblock.a subprojects/base_library/libbl-time-extras.a subprojects/base_library/libbl-tostr.a subprojects/cmocka-1.1.2/src/libcmocka.a -Wl,--end-group -pthread
/usr/bin/ld: libmalc.a(src_malc_destinations_file.c.o): in function `malc_file_dst_open_new_file':
file.c:(.text+0x1c8): undefined reference to `bl_fast_timept_to_sysclock64_diff_ns'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Is there any other information I can provide that would help identify the root cause?

Tests failing on Ubuntu 22.04

I am trying to build and run tests, but I am getting this list of failures. Seems to be some segfaults.

Summary of Failures:

 8/20 base_library / taskqueue-stress                 FAIL            0.08s   exit status 1
 9/20 mini-async-log-c / malc-stress-test-heap        FAIL            0.08s   exit status 1
10/20 mini-async-log-c / malc-stress-test-tls         FAIL            0.08s   exit status 1
11/20 mini-async-log-c / malcpp-smoke                 FAIL            0.09s   exit status 24
12/20 mini-async-log-c / malcpp-stress-test-heap      FAIL            0.08s   exit status 1
13/20 mini-async-log-c / malc-stress-test-queue       FAIL            0.09s   exit status 1
14/20 mini-async-log-c / malc-stress-test-queue-cpu   FAIL            0.09s   exit status 1
15/20 mini-async-log-c / malcpp-stress-test-tls       FAIL            0.10s   exit status 1
16/20 mini-async-log-c / malcpp-stress-test-queue     FAIL            0.09s   exit status 1
18/20 mini-async-log-c / malcpp-stress-test-queue-cpu FAIL            0.10s   exit status 1
19/20 base_library / bl-base                          FAIL            0.16s   exit status 1
20/20 mini-async-log-c / malc-smoke                   TIMEOUT        30.03s   killed by signal 15 SIGTERM

I have attached the test log as well
tests.tar.gz

malcpp-example-hello-malcpp giving bl_timeout non-deterministically

Getting this error when I build and run malcpp/hello-malcpp.
The error does not happen every time - it seems to be somewhat random when running directly on the terminal, but doesn't
ever seem to show up when running in GDB.

Program Output

jsridhara@RSU-502C9R3:~/Documents/Projects/mini-async-log-c/build (master)$ ./malcpp-example-hello-malcpp
terminate called after throwing an instance of 'malcpp::exception'
  what():  Unable to create malc instance
Aborted (core dumped)

Stack trace from the core dump:

Core was generated by `./malcpp-example-hello-malcpp'.
Program terminated with signal SIGABRT, Aborted.
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=139653185956736) at ./nptl/pthread_kill.c:44
44	./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=139653185956736) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=139653185956736) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=139653185956736, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007f038a242476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007f038a2287f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x00007f038a6a2bbe in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007f038a6ae24c in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x00007f038a6ae2b7 in std::terminate() () from /lib/x86_64-linux-gnu/libstdc++.so.6
#8  0x00007f038a6ae518 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
#9  0x00005638e58135fa in malcpp::malcpp<true, true, true>::construct_throw_impl (this=0x5638e5832048 <logger>, alloc=0x0)
    at ../include/malcpp/impl/malc_base.hpp:507
#10 0x00005638e5813307 in malcpp::malcpp<true, true, true>::malcpp (this=0x5638e5832048 <logger>, alloc=0x0)
    at ../include/malcpp/impl/malc_base.hpp:468
#11 0x00005638e5812e93 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at ../example/src/malcpp/hello-malcpp.cpp:7
#12 0x00005638e5812ff4 in _GLOBAL__sub_I_logger () at ../example/src/malcpp/hello-malcpp.cpp:24
#13 0x00007f038a229ebb in call_init (env=<optimized out>, argv=0x7fffac600468, argc=1) at ../csu/libc-start.c:145
#14 __libc_start_main_impl (main=0x5638e5812a7c <main(int, char const**)>, argc=1, argv=0x7fffac600468, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fffac600458) at ../csu/libc-start.c:379
#15 0x00005638e5812805 in _start ()

Inspecting Frame 9:

(gdb) print e
$1 = {own = 4, sys = 0}

Adding some debugging code, the issue seems to be here in time_extras.c

  if (first == -1 || last == -1 || last - first < BL_TIME_MIN_QSAMPLES) {
    return bl_mkerr (bl_timeout);
  }

Things are running okay when running with GDB. Here is the variable values:

Breakpoint 1, bl_time_extras_get_ro_data (s=0x555555576070 <state+16>) at ../subprojects/base_library/src/bl/time_extras/time_extras.c:192
192	  t64_cycles  = meas[last].t[4] - meas[first].t[1];
$1 = 1  <--- first
$2 = 49 <--- last
$3 = 48 <--- (last-first)

But if I print the same from the executable itself, when it fails it prints:

jsridhara@RSU-502C9R3:~/Documents/Projects/mini-async-log-c/build (master)$ ./malcpp-example-hello-malcpp
37 <-- first
49 <-- last
12 <-- (last - first)

So for some reason, these first and last variables are not properly conforming to the logic when not running through GDB.
Not entirely sure where to proceed with debugging here - I am not fully understanding the intention of this section of code anyway.
Any direction is appreciated!

Jay

C++ compiling & CMake integration & Linking order of static dependencies

Hi,
I had some issues using your library in a small project of mine. I solved those issues and I thought I'd share here.

Setup

Ubuntu 19.10
gcc 9.2.1
cmake 3.17.0
meson 0.53.2
ninja 1.9.0

Issue compiling the standalone project (standard)

$ cd mini-async-log-c
$ meson build --buildtype=release
$ ninja -C build

I get the following error:

In file included from ../subprojects/base_library/include/bl/base/thread.h:12,
                 from ../subprojects/base_library/test/src/bl/base/time_test.c:6:
../subprojects/base_library/include/bl/base/impl/thread_c11.h: At top level:
../subprojects/base_library/include/bl/base/impl/thread_c11.h:52:48: error: unknown type name ‘bl_tss_cleanup_func’
   52 | static inline bl_err bl_tss_init (bl_tss* key, bl_tss_cleanup_func cleanup)
      |                                                ^~~~~~~~~~~~~~~~~~~

Cause

It seems that there is a discrepancy in the implementation files when using C11 threads instead of POSIX threads in the base-library dependency:
bl/base/impl/thread_C11.h
bl/base/impl/tss_posix.h

The implementation choice is defined in bl/base/thread.h which depends on bl/base/platform.h and since I use a recent version of gcc (I guess ?) the choice is made to enable BL_HAS_C11_THREAD.

NB: Interestingly this issue didn't arise when I tried to compile logger-bench and base-library as a standalone but I didn't dig much farther.
NBB: malcpp did not compile with logger-bench though :(

Solution

I first chose the quick and dirty way of switching the preprocessor directives in bl/base/thread.h to give priority to the use of POSIX threads. I ended up with this error:

c++ -Isubprojects/base_library/b3ec909@@bl-nonblock-mpmc-bpm-relacy@exe -Isubprojects/base_library -I../subprojects/base_library -I../subprojects/base_library/include -I../subprojects/base_library/src -I../subprojects/base_library/test/src -I../subprojects/base_library/gitmodules/relacy -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++11 -O3 -pthread -MD -MQ 'subprojects/base_library/b3ec909@@bl-nonblock-mpmc-bpm-relacy@exe/test_src_bl_mpmc_bpm_relacy_mpmc_bpm_relacy.cpp.o' -MF 'subprojects/base_library/b3ec909@@bl-nonblock-mpmc-bpm-relacy@exe/test_src_bl_mpmc_bpm_relacy_mpmc_bpm_relacy.cpp.o.d' -o 'subprojects/base_library/b3ec909@@bl-nonblock-mpmc-bpm-relacy@exe/test_src_bl_mpmc_bpm_relacy_mpmc_bpm_relacy.cpp.o' -c ../subprojects/base_library/test/src/bl/mpmc_bpm_relacy/mpmc_bpm_relacy.cpp
../subprojects/base_library/test/src/bl/mpmc_bpm_relacy/mpmc_bpm_relacy.cpp:304:10: fatal error: relacy/relacy.hpp: No such file or directory
  304 | #include <relacy/relacy.hpp>
      |          ^~~~~~~~~~~~~~~~~~~

With this error, I gave up the idea of using a C threading implementation since the logger would eventually be used in a C++ library.

Issue compiling the standalone project (C++ implementation)

I use the -xc++ flag to force gcc to compile c++ code regardless of the compiled file:

$ cd mini-async-log-c
$ CFLAGS=-xc++ meson build --buildtype=release
$ ninja -C build

I end up with a bunch of compiling errors related to the use of cmocka as unit testing framework (not reproduced here). Next try without building the tests:

$ cd mini-async-log-c
$ CFLAGS=-xc++ meson build --buildtype=release -Dbare=true
$ ninja -C build

I get this kind of error:

../subprojects/base_library/src/bl/base/dynamic_string_replace.c:178:1: error: jump to label ‘destroy_bl_dynarray’
  178 | destroy_bl_dynarray:
      | ^~~~~~~~~~~~~~~~~~~
../subprojects/base_library/src/bl/base/dynamic_string_replace.c:162:10: note:   from here
  162 |     goto destroy_bl_dynarray;
      |          ^~~~~~~~~~~~~~~~~~~
../subprojects/base_library/src/bl/base/dynamic_string_replace.c:164:9: note:   crosses initialization of ‘char* rptr_prev’
  164 |   char* rptr_prev   = s->da.str + bl_dstr_len (s);
      |         ^~~~~~~~~

Cause

This was caused by the use of goto labels that jumped over the declaration with initialization of temporary variables which seems to be allowed in C but not in C++.
In the malc project:

In the base-library project:

Solution

I went the q-a-d way again and (stupidly) rewrote the branching logic in those code segments using flags to emulate the goto mechanism. I later stumbled on one of your commit or in-code commentary specifying that the goto mechanism was intended to improve code readability and it did... quite a lot.

I gave another try at solving this and simply created local scopes for the temporary variables jumped over by gotos. It did solve the goto issue.

Issue compiling the standalone project (C++ implementation #2)

So, again:

$ cd mini-async-log-c
$ CFLAGS=-xc++ meson build --buildtype=release -Dbare=true
$ ninja -C build

And this time I'm met with this kind of error:

../subprojects/base_library/src/bl/serial/serial_posix.c: In function ‘bl_err bl_serial_init(bl_serial**, bl_uword, const bl_alloc_tbl*)’:
../subprojects/base_library/include/bl/base/allocator.h:54:29: error: invalid conversion from ‘void*’ to ‘bl_serial*’ [-fpermissive]
   54 |   (bl_alloc_tbl_ptr)->alloc ((bytes), (bl_alloc_tbl_ptr))
      |   ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                             |
      |                             void*

I didn't search this one through a lot and directly went:

$ cd mini-async-log-c
$ CFLAGS="-xc++ -fpermissive" meson build --prefix=/ --buildtype=release -Dbare=true
$ ninja -C build

And thus, I was able to compile the logger. Now to the CMake integration.

CMake integration & Linking order

This part is more for those interested by using this logger inside a CMake project.
So, having everything compiled, I installed it with the complete compile + install command being:

$ cd mini-async-log-c
$ CFLAGS="-xc++ -fpermissive" meson build --prefix=/ --buildtype=release -Dbare=true
$ ninja -C build
$ DESTDIR=$PWD/install ninja -C build install

And, based on the README, I wrote my Findmini-async-log-c.cmake and managed to gather everything as STATIC IMPORTED libraries. I created an INTERFACE target to regroup everything under the same umbrella like this:

add_library(mini-async-log-c INTERFACE IMPORTED)
target_link_libraries(mini-async-log-c
    INTERFACE
        malc
        malcpp
        bl-base
        bl-nonblock
        bl-time-extras
        Threads::Threads
)

I used your example hello-malcpp.cpp inside my project to test the integration. In doing so, I did stumble on some linking error like:

/usr/bin/ld: /home//mini-async-log-c/install/lib/x86_64-linux-gnu/libmalcpp.a(src_malcpp_destinations.cpp.o): in function `malcpp::array_dst::size() const':
destinations.cpp:(.text+0x99): undefined reference to `malc_array_dst_size'

Which appeared to be related to my wrong ordering of static libraries when creating my umbrella target.
Furthermore I got some errors looking like:

/usr/bin/ld: /home//mini-async-log-c/install/lib/x86_64-linux-gnu/libmalc.a(src_malc_entry_parser.c.o): in function `push_obj_data(void*, char const*, char const*, malc_obj_log_data const*)':
entry_parser.c:(.text+0x598): undefined reference to `bl_itostr_dyn_arr'

Those errors stemed from the dependency on bl-tostr library from base-library, I added it to the mini-async-log-c target and got this target which, linked with the example, could compile:

add_library(mini-async-log-c INTERFACE IMPORTED)
target_link_libraries(mini-async-log-c
    INTERFACE
        malcpp
        malc
        bl-tostr
        bl-nonblock
        bl-time-extras
        bl-base
        Threads::Threads
)

And that's it !

Sorry for the big chunk of text, I hope you'll find some interesting feedback in it. And thanks for releasing this project, now having everything setup, I can't wait to give it an in-depth try.

NB: I attached the Findmini-async-log-c.cmake for those interested. You can use it as such:

list(INSERT CMAKE_MODULE_PATH 0 "path/to/find/modules")
set(mini-async-log-c_ROOT "abs/path/to/mini-async-log-c" CACHE PATH "Location of the mini-async-log-c library")
find_package(mini-async-log-c MODULE)

Production Ready?

Is this library production ready or should the original mal be used instead? Which branch is best to be used? It looks like there's no ci builds etc for this.

stress test: Missing messages for small message counts.

Steps to reproduce:

Modify the stress test utility to use a thread only (to reproduce it faster) and use a very high number of iterations of only one message with TLS.

What has been discovered so far:

-It seems to only happen for small message counts, it points to be an initialization/shutdown problem only.
-It seems to happen when running only producer thread.
-Fortunately it's reproductible on Debug mode.
-If malc.c is modified to keep track of the messages that it gets (on static variables properly initialized each time) and trigger assertions there, it shows that when the error is triggered there isn't a single message coming to the queue (the message itself + the TLS buffer init/deinit command messages).
-The TLS creation functions are reporting no errors.

Platform:

-Linux (Ubuntu 16-04 x64).

To check:

-If it happens when using the heap -> TLS issue.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.