Crash while running Benchmark

[AnkitAggarwalPEC]

After running the benchmark as specified by

https://github.com/Iyengar111/NanoLog/blob/master/nano_vs_spdlog_vs_g3log_vs_reckless.cpp

The code is running successfully with -o0 and -o2 but crashes with -o3.

I'm getting the following crash:

I'm unable to solve the issue for a while.

Please do let me know how to solve this.

[mattiasflodin]

I took the source file and commented out nanolog/spdlog/g3log to avoid having to link will all of those libraries. But I'm unable to reproduce your crash. I also single-stepped through the full chain of formatting calls to see if I could find some potential problem but didn't find anything substantial. I should point out though that neither the %c or %lf format specifiers are currently honored so the string you get in the log file is something like "Logging benchmark660%c%lf". A working format string would say "Logging %s%d%d%s%f".

Looking at your backtrace, it seems like the %s argument is passed a null string pointer for some reason. The argument is a constant string ("benchmark") in the benchmarking code so there shouldn't be any lifetime issues or similar, which leads me to think there are alignment inconsistencies when arguments are packed into a tuple and pushed on the queue.

• Could you try making the string on line 25 of the benchmark static? I.e. change the line to static char const * const benchmark = "benchmark";
• How did you compile the library and how did you compile the benchmark?
• What compiler version are you using?
• What commit ID of reckless are you running on?
• Could you perhaps upload a core dump along with your compiled binary? I guess it's too big to attach to a github issue but you could put it on, say, Firefox send.

[mattiasflodin]

For what it's worth, here are the benchmark results I got with your code:

Thread count: 1
reckless percentile latency numbers in microseconds
     50th|     75th|     90th|     99th|   99.9th|    Worst|  Average|
        0|        0|        0|        1|       90|      114| 0.239590|

Thread count: 2
reckless percentile latency numbers in microseconds
     50th|     75th|     90th|     99th|   99.9th|    Worst|  Average|
        0|        0|        0|        1|       95|      111| 0.438870|
reckless percentile latency numbers in microseconds
     50th|     75th|     90th|     99th|   99.9th|    Worst|  Average|
        0|        0|        1|        1|       95|      125| 0.458620|

Thread count: 3
reckless percentile latency numbers in microseconds
     50th|     75th|     90th|     99th|   99.9th|    Worst|  Average|
        0|        0|        1|        1|      101|      124| 0.784570|
reckless percentile latency numbers in microseconds
     50th|     75th|     90th|     99th|   99.9th|    Worst|  Average|
        0|        0|        1|        1|      100|      110| 0.780480|
reckless percentile latency numbers in microseconds
     50th|     75th|     90th|     99th|   99.9th|    Worst|  Average|
        0|        1|        1|        1|      101|      124| 0.785240|

Thread count: 4
reckless percentile latency numbers in microseconds
     50th|     75th|     90th|     99th|   99.9th|    Worst|  Average|
        0|        0|        1|        1|      100|      118| 0.979490|
reckless percentile latency numbers in microseconds
     50th|     75th|     90th|     99th|   99.9th|    Worst|  Average|
        0|        0|        1|        1|      101|      118| 0.986600|
reckless percentile latency numbers in microseconds
     50th|     75th|     90th|     99th|   99.9th|    Worst|  Average|
        0|        0|        1|        1|      101|      119| 1.003500|
reckless percentile latency numbers in microseconds
     50th|     75th|     90th|     99th|   99.9th|    Worst|  Average|
        0|        0|        1|        1|      101|      120| 1.006060|

[mattiasflodin]

Closing due to lack of response from reporter. Please reopen if you are able to provide more information for reproducing or fixing this.