minimind

Root cause: signal.SIGALRM and signal.alarm() are POSIX-only and do not exist on Windows. In trainer/train_agent.py, execute_tool() calls signal.signal(signal.SIGALRM, ...) inside a bare except:, so the resulting AttributeError is silently swallowed and the function returns None. rollout_single then converts that None into {"error": "tool not found"} for every single tool call — no crash, no warning. This also silently corrupts Agentic RL training: the format reward still scores, but the main ground-truth reward (weight 2.5) becomes unreachable because the model never sees real tool results.

Fix (PR #847): update to a version containing the AST-based safe_math_eval() in trainer/trainer_utils.py. It replaces raw eval() on model-generated strings and removes the signal-based timeout entirely (an AST evaluator cannot enter an infinite loop, so signal.alarm is unnecessary — the cross-platform problem disappears with no platform guard needed). The same fix is applied to all three eval() call sites: trainer/train_agent.py, scripts/eval_toolcall.py, and scripts/web_demo.py.

If you are stuck on an older commit, apply this minimal cross-platform patch:

_HAS_ALARM = hasattr(signal, "SIGALRM")

def execute_tool(name, args):
    fn = MOCK_RESULTS.get(name)
    if not fn: return None
    try:
        if _HAS_ALARM:
            signal.signal(signal.SIGALRM, lambda *_: (_ for _ in ()).throw(TimeoutError()))
            signal.alarm(1)
        return fn(args)
    except Exception as e:
        print(f"[tool] {name} failed: {type(e).__name__}: {e}")
        return None
    finally:
        if _HAS_ALARM: signal.alarm(0)

Key rules: never use a bare except: (it hid the AttributeError and made the failure silent), and always guard signal.SIGALRM/signal.alarm with hasattr(signal, 'SIGALRM') on cross-platform code.

The effective training batch is batch_size × num_generations (Agent RL: 2×4=8, GRPO: 2×6=12), and training simultaneously loads the Policy model, Reference model, and a 1.8B Reward Model, so 24GB VRAM may be insufficient. Fixes:

1. For train_agent.py, reduce batch size and total length:

python train_agent.py --batch_size 1 --max_total_len 1536

2. For train_grpo.py (no max_total_len option), reduce batch size, generations, and sequence lengths:

python train_grpo.py --batch_size 1 --num_generations 4 --max_seq_len 512 --max_gen_len 768

3. If PyTorch reports large 'reserved but unallocated memory', reduce fragmentation by setting:

export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True

original_max_position_embeddings must reference the context length the checkpoint was actually trained on *before* enabling YaRN — not the value in train_pretrain.py. MiniMind's pipeline is: (1) Pretrain with original RoPE at max_seq_len=340 (YaRN disabled); (2) Full SFT with original RoPE at max_seq_len=2048 (YaRN disabled — the released full_sft weights were trained at 2048 tokens, not the 768 used in the quick mini-dataset reproduction script); (3) Inference with YaRN enabled, extrapolating from the 2048 window (e.g., python eval_llm.py --weight full_sft --inference_rope_scaling). Therefore original_max_position_embeddings=2048 matches the Full SFT checkpoint. RoPE itself is a deterministic position rotation with no trainable parameters; what needs training is the model weights' adaptation to the position range, which already happened during the 2048-token Full SFT stage. Only if you skip Full SFT and apply YaRN directly to a pretrain-only checkpoint trained at length 340 should you set original_max_position_embeddings=340.