Question on memory mapping in silifuzz

[xiangli3]

Hi Silifuzz author,

I am currently using Silifuzz as a part of my research, and during my experiments, there has some issue related with memory mapping.
Form silifuzz source: https://github.com/google/silifuzz/blob/main/runner/runner.cc

1. It first creates memory mapping, here if we compared passed and failed log, seems failed log does not trigger memory mapping successfully:

    Passed memory mapping log:
    I<DATE> <PID> runner.cc:315] Creating memory mappings
    I<DATE> <PID> runner.cc:330] Mapping 0x10000
    I<DATE> <PID> runner.cc:330] Mapping 0x64548000
    ……
    I<DATE> <PID> runner.cc:330] Mapping 0x880f000
    I<DATE> <PID> runner.cc:330] Mapping 0x77919000
    I<DATE> <PID> runner.cc:347] Done creating memory mappings
   
    Failed memory mapping log:
    I<DATE> <PID> runner.cc:315] Creating memory mappings
    I<DATE> <PID> runner.cc:347] Done creating memory mappings
   

2. Then start silifuzz iteration, here if we compared passed and failed log, seems failed log does not trigger iteration successfully since no memory mapping created.

   Passed iteration log: 
   I<DATE> <PID> runner.cc:624] iter #512 of 1000000
   I<DATE> <PID> runner.cc:627] #512 Running 10e61c7601de69b752e110d80f81a65bd0081f84
   
   Failed iteration log:
   I<DATE> <PID> runner.cc:624] iter #512 of 1000000
   

3. Finally, failed system hit “Execution misbehaved” and record error info, here outcome = 6 means “Execution caused a signal.”

   E<DATE> <PID> runner.cc:439] Snapshot [05ade11fea669f234eb7606b4c62df40ebc27ee8] failed, outcome = 6
   I<DATE> <PID> runner.cc:473] Execution misbehaved
   I<DATE> <PID> snapshot_enums.cc:75] Signal: 11
   I<DATE> <PID> snapshot_enums.cc:76] sig_address: 0x0
   

So here the problem is why failed system cannot create memory mapping successfully?

Please check below full log from failed system, thanks.
runner_log_2023-10-12-21-53-45_cpu7.log

[ksteuck]

hi @xiangli3

The log says that the 05ade11fea669f234eb7606b4c62df40ebc27ee8 snapshot caused a #GP. Mostly likely it tried to execute an instruction that was not allowed or was otherwise malformed (e.g. unaligned memory access). It's impossible to tell exactly what happened without seeing the actual snapshot. If you look at the player_result it clearly shows start_address:0x10000 etc indicating that the mappings were in fact created.

On the missing logs, I think what happened is that you'd made changes the verbosity level in this file so that VLOG_INFO(2) messages are visible in the passing run but then changed it so that only VLOG_INFO(1) are visible in the failing run. We have an outstanding action item to make the verbosity level configurable via the command line.

Feel free to objdump the code and post it here if you need help debugging this further.

HTH