I've added "-monitor stdio" option to command line of Test 1 and repeated entering command during execution:
QEMU 3.0.50 monitor - type 'help' for more information (qemu) info replay Replaying execution 'icount_rr_capture.bin': current step = 311736195 (qemu) info replay Replaying execution 'icount_rr_capture.bin': current step = 318198367 (qemu) info replay Replaying execution 'icount_rr_capture.bin': current step = 324737211 (qemu) info replay Replaying execution 'icount_rr_capture.bin': current step = 329890795 (qemu) info replay Replaying execution 'icount_rr_capture.bin': current step = 607069789 (qemu) info replay Replaying execution 'icount_rr_capture.bin': current step = 607069789 (qemu) info replay Replaying execution 'icount_rr_capture.bin': current step = 607069789 ... Some notes on value of step it stucks on: - mostly it's same (even across different record-replay pairs); - stressing host during replay may cause it to change even for same record-replay pair (i.e. different replay executions for same file recorded). This specific case seems to be stable to reproduce. вт, 2 окт. 2018 г. в 0:22, Artem Pisarenko <artem.k.pisare...@gmail.com>: > I've posted bug report with extended tests (incl. case without sleep=off). > You may find guest image (kernel) in bug description. > https://bugs.launchpad.net/qemu/+bug/1795369 > > The most annoying thing is that some issues are almost not reproducible. > There are definitely race conditions somewhere in qemu code. Running > 'stress-ng' utility with CPU and I/O stressors in parallel with qemu > execution greatly minimizes amount of attempts when I'm trying to trigger > some of issues I encounter. > > I'll try 'info monitor' command tomorrow, but no guarantees that I'll be > able to reproduce issue again. > > Speaking about '-nographic' and SDL... I've noted that UI greatly > minimizes possibility of hanging (but not avoids it completely) when using > icount in general, so this effect isn't rr-specific. I've already reported > this bug too. > > > пн, 1 окт. 2018 г., 20:14 dovgaluk <dovga...@ispras.ru>: > >> Artem Pisarenko писал 2018-09-30 14:01: >> > Feature still broken :( >> >> Thanks for testing. >> >> > >> > Brief description of my tests. >> > >> > Guest image is Linux, which just powers off after kernel boots >> > (instead of proceeding to user-space /init or /sbin/init). >> > Base cmdline: >> > qemu-system-x86_64 -nodefaults -machine pc,accel=tcg -m 2048 -cpu >> > qemu64 -rtc clock=vm,base=2000-01-01T00:00:00 -kernel bzImage -initrd >> > rootfs -append 'nokaslr console=ttyS0 rdinit=/init_poweroff' >> > -nographic -serial SERIAL_VALUE -icount >> > 1,sleep=off,rr=RR_VALUE,rrfile=icount_rr_capture.bin >> >> I've never tried it with sleep=off. Can you remove it and try again? >> >> We also seen a problem with '-nographic'. When we remove this option and >> QEMU runs with SDL >> window, everything is ok. There is some problem with main loop which may >> sleep when there >> is no GUI to update, or something like that. We couldn't fix it yet. >> >> > >> > Test 1. When SERIAL_VALUE=none >> > Running with RR_VALUE=record completes successfully. >> > Running with RR_VALUE=replay doesn't completes. qemu process just >> > eating ~100% cpu and memory usage doesn't grow after some moment. I >> > don't see what happens because of problem no.2 (see below). >> >> Try 'info replay' monitor command. Does instruction counter increases? >> >> > >> > Test 2. When SERIAL_VALUE=stdio >> > Running with RR_VALUE=record completes successfully. >> > >> > Running with RR_VALUE=replay caues exit with error: >> > >> > "qemu-system-x86_64: Missing character write event in the replay log" >> > >> > These problems are same with qemu 2.12 (both vanilla and with previous >> > versions of these patches applied). Furthemore, I consider whole >> > icount mode broken and determinism isn't achievable. >> > The irony is that I actually don't need record/replay feature. I've >> > tried to use it only as instrument to debug failing determinism in >> > qemu code. But since replay/record feature itself relies on >> > determinism, which is broken, it's no wonder why it fails also (I just >> > hoped to bypass it). >> > >> > Contact me if you need more details. I just tired a lot trying to get >> > all these things working... Hope is leaving me... >> >> Can you share the kernel in case the icount still broken? >> >> >> Pavel Dovgalyuk >> >> -- > > С уважением, > Артем Писаренко > -- С уважением, Артем Писаренко
