ben-manes/caffeine · warning

Wrong ref page number found: %ld.\n

Error message

Wrong ref page number found: %ld.\n

What it means

A data-validation error in lirs.c's trace reader: each trace line is parsed into ref_block, and if the referenced page number exceeds vm_size (the configured virtual memory size for the simulation), the tool prints 'Wrong ref page number found: %ld' and returns, skipping the sample. It exists because LIRS simulates a cache over a fixed address space of vm_size pages, and any reference beyond that space cannot be modeled — almost always a trace/format or vm_size-configuration mismatch.

Source

Thrown at simulator/src/main/resources/com/github/benmanes/caffeine/cache/simulator/parser/lirs/lirs.c:181

      fscanf(trace_fp, "%s", ref_block_str);
      if (strcmp(ref_block_str, "*")) {
        ref_block = atoi(ref_block_str);
      }
      continue;
    }

    total_pg_refs++;
    if (total_pg_refs % 10000 == 0) {
      fprintf(stderr, "%ld samples processed\r", total_pg_refs);
    }
    if (total_pg_refs > STAT_START_POINT) {
      collect_stat = 1;
      warm_pg_refs++;
    }

    if (ref_block > vm_size) {
      fprintf(stderr, "Wrong ref page number found: %ld.\n", ref_block);
      return;
    }

    if (ref_block == last_ref_pg) {
      fscanf(trace_fp, "%s", ref_block_str);
      if (strcmp(ref_block_str, "*")) {
        ref_block = atoi(ref_block_str);
      }
      continue;
    }
    else {
      last_ref_pg = ref_block;
    }

    no_dup_refs++; /* ref counter excluding duplicate refs */

    if (!page_tbl[ref_block].isResident) {  /* block miss */
      if (collect_stat == 1) {

View on GitHub (pinned to 9da6581ee3)

Solutions

1. Set vm_size (virtual memory size) to a value >= the largest page number appearing in the trace, typically the distinct block count or max block id
2. Verify the trace format matches what lirs.c expects: a sequence of block numbers (with the tool's continuation marker '*'), preprocessed if needed
3. Sanitize the trace: strip headers, opcodes, or any non-numeric columns before feeding it in
4. Check the error's reported %ld value — if it looks like an ASCII/garbage number, the parser is reading the wrong column

Example fix

# before
./lirs trace.dat 1000   # vm_size=1000 but trace has block ids up to 5000

# after
./lirs trace.dat 8192   # vm_size >= max block id in trace

# validate trace against vm_size before replay
max_id=$(awk '!/\*/ {if ($1+0 > m) m = $1+0} END {print m}' trace.dat)
vm_size=8192   # value you plan to pass
if [ "$max_id" -ge "$vm_size" ]; then echo "trace max id $max_id >= vm_size $vm_size"; exit 1; fi

When it happens

Trigger: Replaying a trace whose maximum page/block number is larger than the vm_size passed to the tool (default virtual memory size too small); passing a trace in the wrong format so a non-numeric token (e.g. an opcode like 'R'/'W' or '*') is parsed as the block number; a trace with 1-based block numbers when the tool assumes a different base against a tight vm_size.

Common situations: Converting a multi-column trace (e.g. with access-type suffixes) through the LIRS converter without normalizing it first; forgetting to set the vm_size parameter to at least the trace's distinct-block count; mixing up the LIRS trace format expected by the simulator's lirs trace parser with the output of another generator.

Related errors

• Fail to alloc memory!\n
• Fail to realloc memory!\n
• Fail to generate file %s\n

AI-assisted analysis of ben-manes/caffeine@9da6581ee3 (2026-08-14). Data as JSON: /api/errors/e9ec58408826b583. Report an issue: GitHub.