Comment # 6
on bug 1167575
from Jiri Slaby
(In reply to Franck Bui from comment #5)
> (In reply to Jiri Slaby from comment #0)
> >> (gdb) p *s
> >> [...]
> >> exec_command = {0x200000000000000, 0x0, 0x561c9a282960, 0x0, 0x0, 0x0, 0x0},
>
> I checked the code but I cannot see currently where the boggus value
> "0x200000000000000" could come from.
>
> It doesn't look random though, it looks like the value was set to 0 but one
> bit was not cleared.
>
> It might be interesting to see if the other crashes show the same wrong
> value at the same location.
>
> Maybe you could try to test the system RAM... otherwise without a reproducer
> I'm running out of idea.
Yesterday, udev crashed while parsing udev rules file.
> #0 0x000055e5889a3bf4 in udev_rules_apply_to_event (rules=0x55e58a2d92e0, event=0x55e58a22c8d0, timeout_usec=180000000, properties_list=0x0) at ../src/udev/udev-rules.c:2268
> 2268 LIST_FOREACH_SAFE(rule_lines, file->current_line, next_line, file->rule_lines) {
Iterating through the file->rule_lines list in gdb:
> {line = 0x55e58a139c60 "SUBSYSTEM", line_number = 65, type = LINE_UPDATE_SOMETHING, ... rule_lines_next = 0x55e58a139e90, rule_lines_prev = 0x55e58a139ae0}
> {line = 0x55e58a139e00 "SUBSYSTEM", line_number = 66, type = LINE_UPDATE_SOMETHING, ... rule_lines_next = 0x55e58a13a090, rule_lines_prev = 0x55e58a139ce0}
> {line = 0x55e58a13a010 "SUBSYSTEM", line_number = 67, type = LINE_UPDATE_SOMETHING, ... rule_lines_next = 0x20055e58a13a240, rule_lines_prev = 0x55e58a139e90}
Look at the last rule_lines_next: 0x20055e58a13a240. It's 0x55e58a13a240 ORed
with 0x200000000000000 again (it's the very same bit flipped). So this is
either bad RAM or kernel corrupts memory.
Note that when I fix the address, it contains the next line:
(gdb) p *(UdevRuleLine *)0x55e58a13a240
{line = 0x55e58a13a1b0 "SUBSYSTEM", line_number = 68, type =
LINE_UPDATE_SOMETHING, ... rule_lines_next = 0x55e58a13a440, rule_lines_prev =
0x55e58a13a090}
Let it open for a while, until I run memtest to confirm/exclude RAM failure.