Open edumoot opened 1 month ago
@llvm/issue-subscribers-lldb
Author: Yachao Zhu (edumoot)
LLDB may crash when attempting to access structure-related variables or similar constructs like multi-dimensional arrays, defined as {{}}. Here is another crash example in the LLVM18.1.8 environment when trying to print a two-dimensional array, l_11
on line 17.
clang -g -O1 382.c -o 382_O1.out
lldb 382_O1.out
(lldb) b 382.c:17
Breakpoint 1: where = 382_O1.out`main [inlined] func_1 at 382.c:17, address = 0x0000000000001130
(lldb) r
[...]
* thread #1, name = '382_O1.out', stop reason = breakpoint 1.1
frame #0: 0x0000555555555130 382_O1.out`main [inlined] func_1 at 382.c:17
14 {
15 uint32_t l_11[1][8] = {{0UL,0UL,0UL,0UL,0UL,0UL,0UL,0UL}};
16 int i, j;
-> 17 for (g_2[1][0][0] = 0; (g_2[1][0][0] >= (-12)); g_2[1][0][0] = safe_sub_func_int64_t_s_s(g_2[1][0][0], 5))
18 {
19 int32_t *l_5[3];
20 struct S1 * const l_7 = &g_8;
(lldb) p l_11
lldb: /llvm-project/lldb/source/Expression/DWARFExpression.cpp:2192: static bool lldb_private::DWARFExpression::Evaluate(lldb_private::ExecutionContext*, lldb_private::RegisterContext*, lldb::ModuleSP, const lldb_private::DataExtractor&, const lldb_private::plugin::dwarf::DWARFUnit*, lldb::RegisterKind, const lldb_private::Value*, const lldb_private::Value*, lldb_private::Value&, lldb_private::Status*): Assertion `ap_int.getBitWidth() >= bit_size' failed.
LLDB diagnostics will be written to /tmp/diagnostics-626a8f
Please include the directory content when filing a bug report
Aborted (core dumped)
cat 382.c
#include "csmith.h"
volatile uint64_t csmith_sink_ = 0;
struct S1 {
uint8_t f0;
};
static int32_t g_2[5][1][1] = {{{0xE01BD97AL}},{{6L}},{{0xE01BD97AL}},{{6L}},{{0xE01BD97AL}}};
static int32_t g_6 = 1L;
static struct S1 g_8 = {0xCEL};
static uint16_t func_1(void)
{
uint32_t l_11[1][8] = {{0UL,0UL,0UL,0UL,0UL,0UL,0UL,0UL}};
int i, j;
for (g_2[1][0][0] = 0; (g_2[1][0][0] >= (-12)); g_2[1][0][0] = safe_sub_func_int64_t_s_s(g_2[1][0][0], 5))
{
int32_t *l_5[3];
struct S1 * const l_7 = &g_8;
struct S1 *l_10 = &g_8;
struct S1 **l_9 = &l_10;
int i;
for (i = 0; i < 3; i++)
l_5[i] = &g_6;
g_6 = 0xA20BD035L;
if (g_2[1][0][0])
continue;
(*l_9) = l_7;
}
return l_11[0][2];
}
int main (int argc, char* argv[])
{
int i, j, k;
func_1();
for (i = 0; i < 5; i++)
{
for (j = 0; j < 1; j++)
{
for (k = 0; k < 1; k++)
{
csmith_sink_ = g_2[i][j][k];
}
}
}
return 0;
}
Crash occurs in LLVM18.1.8 and LLVM17.0.6, but it does not happen in LLVM16.0.3.
After extensive testing, it appears that LLDB is prone to crashing when attempting to print complex variables, such as arrays and structures, where some elements are optimized out while others remain accessible. LLDB can only handle printing variables where either all elements are optimized out or all are available.
print
orfr v
command on line 16 of the binary generated with-g -O3
,and the diagnostics file contains nothing,
under the context of llvm 18.1.8.
include
volatile uint64_t csmithsink = 0;
struct S0 { volatile uint8_t f0; };
static struct S0 g_4[8][9][3] = {{{{1UL},{248UL},{7UL}},{{0xA4L},{253UL},{0xD7L}},{{0xD7L},{248UL},{0x8FL}},{{0xEDL},{1UL},{1UL}},{{0UL},{0xDCL},{253UL}},{{0x98L},{0xA4L},{3UL}},{{0x0FL},{0UL},{1UL}},{{1UL},{0UL},{0x73L}},{{0x57L},{1UL},{0x73L}}},{{{0x02L},{0UL},{1UL}},{{0xDCL},{255UL},{3UL}},{{253UL},{0x8FL},{253UL}},{{0UL},{0UL},{1UL}},{{0x73L},{0x6DL},{0x8FL}},{{255UL},{0xEDL},{0xD7L}},{{0UL},{0UL},{1UL}},{{1UL},{0UL},{0x0FL}},{{0UL},{0x11L},{248UL}}},{{{0UL},{1UL},{0x6DL}},{{0xEDL},{248UL},{0x98L}},{{1UL},{255UL},{255UL}},{{0UL},{0UL},{246UL}},{{255UL},{0UL},{0UL}},{{1UL},{255UL},{0xF8L}},{{0x73L},{248UL},{0x71L}},{{1UL},{1UL},{1UL}},{{0xF8L},{0x11L},{1UL}}},{{{0x66L},{0UL},{1UL}},{{3UL},{0UL},{7UL}},{{0x6DL},{0x66L},{1UL}},{{0xDCL},{255UL},{1UL}},{{255UL},{7UL},{1UL}},{{250UL},{0UL},{0x71L}},{{255UL},{1UL},{0xF8L}},{{0x78L},{0xF8L},{0UL}},{{0x02L},{0x23L},{246UL}}},{{{0x02L},{253UL},{255UL}},{{0x78L},{0xD7L},{0x98L}},{{255UL},{0x6DL},{0x6DL}},{{250UL},{1UL},{248UL}},{{255UL},{0xDCL},{0x0FL}},{{0xDCL},{2UL},{1UL}},{{0x6DL},{0xEDL},{3UL}},{{3UL},{2UL},{0UL}},{{0x66L},{0xDCL},{0x23L}}},{{{0xF8L},{1UL},{0xEDL}},{{1UL},{0x6DL},{255UL}},{{0x73L},{0xD7L},{0UL}},{{1UL},{253UL},{0UL}},{{255UL},{0x23L},{0UL}},{{0UL},{0xF8L},{0UL}},{{1UL},{1UL},{255UL}},{{0xEDL},{0UL},{0xEDL}},{{0UL},{7UL},{0x23L}}},{{{0UL},{255UL},{0UL}},{{1UL},{0x66L},{3UL}},{{0xD7L},{0UL},{1UL}},{{1UL},{0UL},{0x0FL}},{{0UL},{0x11L},{248UL}},{{0UL},{1UL},{0x6DL}},{{0xEDL},{248UL},{0x98L}},{{1UL},{255UL},{255UL}},{{0UL},{0UL},{246UL}}},{{{255UL},{0UL},{0UL}},{{1UL},{255UL},{0xF8L}},{{0x73L},{248UL},{0x71L}},{{1UL},{1UL},{1UL}},{{0xF8L},{0x11L},{1UL}},{{0x66L},{0UL},{1UL}},{{3UL},{0UL},{7UL}},{{0x6DL},{0x66L},{1UL}},{{0xDCL},{255UL},{1UL}}}};
static uint32_t func_1(void) { struct S0 l_3[8] = {(void)0,(void)0,(void)0,(void)0,(void)0,(void)0,(void)0,(void*)0}; struct S0 *l_2 = &l_3[2]; int i; (l_2) = (void*)0; return g_4[2][3][0].f0; }
int main (int argc, char* argv[]) { func_1(); return 0; }
gdb 320.out (gdb) b 320.c:16 Breakpoint 1 at 0x1130: file 320.c, line 16. (gdb) r [...] Breakpoint 1, func_1 () at 320.c:16 16 return g_4[2][3][0].f0; (gdb) p l_3 $1 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0} (gdb) info local l_3 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0} l_2 =
i =
gdb version GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
/llvm-project/lldb/source/Expression/DWARFExpression.cpp:2191: static bool lldb_private::DWARFExpression::Evaluate(lldb_private::ExecutionContext, lldb_private::RegisterContext, lldb::ModuleSP, const lldb_private::DataExtractor&, const DWARFUnit, lldb::RegisterKind, const lldb_private::Value, const lldb_private::Value, lldb_private::Value&, lldb_private::Status): Assertion `ap_int.getBitWidth() >= bit_size' failed. Aborted (core dumped)
clang -g -O3 -o 320.out lldb 320.out (lldb) b 320.c:16 Breakpoint 1: where = 320.out`main [inlined] func_1 at 320.c:16:25, address = 0x0000000000001130 (lldb) r [...]
19 int main (int argc, char argv[]) (lldb) fr v (S0 *[8]) l_3 = { [0] = NULL [1] = NULL [2] = NULL [3] = NULL [4] = NULL [5] = NULL [6] = NULL [7] = NULL } (lldb) version lldb version 16.0.3 (https://github.com/llvm/llvm-project.git revision da3cd333bea572fb10470f610a27f22bcb84b08c) clang revision da3cd333bea572fb10470f610a27f22bcb84b08c llvm revision da3cd333bea572fb10470f610a27f22bcb84b08c