On Sat, Mar 10, 2018 at 9:11 AM, Michael Clark <m...@sifive.com> wrote:
> > > On Sat, Mar 10, 2018 at 5:49 AM, Peter Maydell <peter.mayd...@linaro.org> > wrote: > >> On 9 March 2018 at 14:28, Peter Maydell <peter.mayd...@linaro.org> wrote: >> > NB: there was a test failure on OpenBSD host: >> > >> > TEST: tests/qom-test... (pid=64016) >> > /riscv32/qom/spike_v1.9.1: >> ** >> > ERROR:/home/qemu/tests/qom-test.c:64:test_properties: assertion >> > failed: (qdict_haskey(response, "return")) >> > FAIL >> > >> > but this seems to have been intermittent -- it was only on that one >> > host, and I reran the test suite there and it passed fine the second >> > time. So it may be nothing to do with your code; we'll see if it >> > comes up again. >> >> On a later test run I got this different one; openbsd again: >> >> TEST: tests/test-hmp... (pid=45236) >> /riscv32/hmp/spike_v1.9.1: ** >> ERROR:/home/qemu/qom/object.c:488:object_new_with_type: assertion >> failed: (type != NULL) >> Broken pipe >> FAIL >> >> My current best theory is that OpenBSD libc's memory allocator >> happens to be more sensitive to a memory corruption bug in the risc >> code, resulting in intermittent failures if the allocations happen >> to come out the wrong way. You do have at least one invalid-write >> off the end of a block according to valgrind: >> >> ==17441== Invalid write of size 1 >> ==17441== at 0x26517F: riscv_isa_string (cpu.c:399) >> ==17441== by 0x25C14D: create_fdt (spike.c:125) >> ==17441== by 0x25C14D: spike_v1_10_0_board_init (spike.c:199) >> ==17441== by 0x2CCE0A: machine_run_board_init (machine.c:807) >> ==17441== by 0x1BFF28: main (vl.c:4597) >> ==17441== Address 0x3055c425 is 0 bytes after a block of size 5 alloc'd >> ==17441== at 0x4C2FB55: calloc (in >> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==17441== by 0x70C8770: g_malloc0 (in >> /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2) >> ==17441== by 0x26511E: riscv_isa_string (cpu.c:395) >> ==17441== by 0x25C14D: create_fdt (spike.c:125) >> ==17441== by 0x25C14D: spike_v1_10_0_board_init (spike.c:199) >> ==17441== by 0x2CCE0A: machine_run_board_init (machine.c:807) >> ==17441== by 0x1BFF28: main (vl.c:4597) >> >> If you can prioritise a patch that fixes the bug in riscv_isa_string() >> I'll apply that and hopefully these intermittent failures will go away. >> > > I'm looking at this right now. > It's a glaringly obvious logic bug. The use of the wrong bit manipulation instrinsic. I just sent a patch.
