The asker is reverse-engineering a stripped x86_64 binary in GDB and wants to run "until" a specific instruction address. The documentation claims until and tbreak accept the same location syntax, including the *addr form for raw addresses. But in practice:

• tbreak *0x401234 sets a one-shot breakpoint at exactly that address.
• until *0x401234 reports a memory-access error, and the resolved target looks like 0x1 — a nonsense value.

Why this is interesting: it's a divergence inside GDB itself between two command implementations that document themselves as equivalent. The "0x1" smells like a parsing or dereference bug — GDB's expression evaluator is treating *0x401234 as "read a long from address 0x401234" (the C-style unary *) instead of as the linespec prefix that means "the literal address." tbreak dispatches to the linespec parser, which has a special case for the leading *; until appears to fall through to the generic expression evaluator, which interprets * as pointer dereference. The "0x1" the user sees is plausibly whatever low byte happened to live at 0x401234.

Direction toward an answer:

• Confirm with set debug expression 1 and set debug parser 1 — watch how each command tokenizes *0x401234.
• Check GDB source: until_command in infcmd.c historically routes through parse_and_eval_address, whereas tbreak goes through decode_line_full / linespec.c. That's the asymmetry.
• Workaround: skip the linespec form entirely. Use tbreak *0x401234 followed by continue — semantically identical to until for a one-shot stop, and uses the parser that actually works.
• Alternative: advance *0x401234 has the same documented syntax but is implemented closer to until, so it likely fails the same way — worth confirming, since the asker mentioned it.

Gotchas: until also has a semantic constraint tbreak doesn't — it only stops if the target is within the current frame and at a higher address than the current PC. So even if the address parsing were fixed, until into an arbitrary stripped address can silently no-op (run to end of frame). For RE work on stripped binaries, tbreak + continue is genuinely the more robust idiom regardless of whether this is a bug.

This looks like a legitimate GDB bug worth filing against sourceware — the docs explicitly promise equivalence the implementation doesn't deliver.