gcore is a gdb command, that internally uses gdb to dump the core.
However with proper configuration of limits (core_dump.size_limit) it
should not be required, althought some issues is possible:
- non standard kernel.core_pattern
- sanitizers
So yes, gcore is more "universal" (you don't need to configure any
`kernel_pattern`), but it is ad-hoc, and it has drawbacks -
**it does not work when gdb fails**. For example gdb may fail with
`Dwarf Error: DW_FORM_strx1 found in non-DWO CU` in case of DWARF-5 [1].
[1]: https://github.com/ClickHouse/ClickHouse/pull/40772#issuecomment-1236331323.
Let's try to switch to more native way.
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
* test/fuzzer: preserve core
This may help to capture things like in [1]:
Failed assertion: "bin->low_bits_full > bin->low_bits_empty" Received signal 6 Received signal Aborted (6)
[1]: https://s3.amazonaws.com/clickhouse-test-reports/33057/19216f4c0ae0f72108c147f958a708b521ad27dc/fuzzer_astfuzzerdebug,actions//report.html
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
* test: do not run 'info locals' since 'backtrace full' includes it
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
* test: try capture backtrace from all threads
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
* test/stress: fix path for core artifacts
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
Fixes: #33389
* test/fuzzer: store core file in artifacts
v2: fix report, because of undefined variable CORE_LINK
v3: fix case when there is no core file
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
