You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 15, 2024. It is now read-only.
Sometimes printk messages do not immediately show up when the reproducer runs, and are only emitted when the next reproducer starts to run.
In the example below, we can see the backtrace for previous reproducer PID: 22329 Comm: 7e93129ee310878 showed up in the result of 7e7470f0058e0950706a4fd684c2d86c7b43df31.
This is a hard one to solve because there may be task related to last reproducer lingering around somewhere (e.g. inside work queues).
Some ideas for this issue:
Adding sleep after each reproducer run (slow down a little bit and can't reliably avoid this issue)
Reboot after each reproducer run (a bit crazy as this will cause a massive slow down, but should work reliably)
Using dmesg to flush the printk buffer (not sure if this will work)
The text was updated successfully, but these errors were encountered:
shunghsiyu
changed the title
Leak log message from previous Syzkaller reproducer run
Leaked log message from previous Syzkaller reproducer run
Jul 7, 2020
I doubt that this will ever get fixed, the timing are just too unpredictable and rebooting or even loading from snapshot would make the testrun way too slow.
I guess that the best we can do is to keep the dmesg in one big file and only store line offset to the relevant part in the testcase.
We could try waiting for the system load to decrease below some threshold before continuing. However it seems like some of the metrics for measuring load are broken on the low latency scheduler on my machine so this could be tricky.
I guess you can also compare the PIDs in the stack trace with the reproducer's.
Sometimes printk messages do not immediately show up when the reproducer runs, and are only emitted when the next reproducer starts to run.
In the example below, we can see the backtrace for previous reproducer
PID: 22329 Comm: 7e93129ee310878
showed up in the result of7e7470f0058e0950706a4fd684c2d86c7b43df31
.This is a hard one to solve because there may be task related to last reproducer lingering around somewhere (e.g. inside work queues).
Some ideas for this issue:
dmesg
to flush the printk buffer (not sure if this will work)The text was updated successfully, but these errors were encountered: