Feedback on bug reports beyond "closed"

jbemmel · April 30, 2026, 10:18pm

I have submitted a number of bug reports, and one by one they are slowly getting addressed. Just today I received 2 e-mails:

github.com/modular/modular

[BUG] Mojo compiler crash in ParamInf::inferForCall when constructing Span[UInt8] for a comptime struct field with inferred Span parameter

opened 06:12PM - 29 Apr 26 UTC

closed 06:11PM - 30 Apr 26 UTC

jbemmel

bug mojo

### Bug description Below code crashes with this error: ``` error: 'Span[UInt8,… ?]' is not concrete, use '[]' to bind missing parameters [... WARNING process_reader_linux.cc:144] no stack mapping 1. Crash resolving decl signature at examples/span_paraminf_crash.mojo:8:1 2. Crash ParamInf::inferForCall at examples/span_paraminf_crash.mojo:8:43 >> comptime CRASH = Spec(children=Span[UInt8](CHILDREN)) ``` ### Steps to reproduce ```mojo @fieldwise_init struct Spec: var children: Span[UInt8, _] comptime CHILDREN: InlineArray[UInt8, 1] = [1] comptime CRASH = Spec(children=Span[UInt8](CHILDREN)) ``` ### System information ``` jeroen@j:~/Projects/xYang.mojo$ pixi info System ------------ Pixi version: 0.65.0 TLS backend: rustls Platform: linux-64 Virtual packages: __unix=0=0 : __linux=6.8.0=0 : __glibc=2.39=0 : __cuda=11.4=0 : __archspec=1=haswell jeroen@j:~/Projects/xYang.mojo$ pixi list mojo Name Version Build Size Kind Source mojo 0.26.3.0.dev2026042305 release 89.58 MiB conda https://conda.modular.com/max-nightly mojo-compiler 0.26.3.0.dev2026042305 release 84.89 MiB conda https://conda.modular.com/max-nightly mojo-python 0.26.3.0.dev2026042305 release 22.64 KiB conda https://conda.modular.com/max-nightly ```

github.com/modular/modular

[BUG] SIGSEGV (exit 139) running minimal XPath-style evaluator repro — crash with STRING-only AST when load-bearing visit_call + Variant/Arc code is present

opened 07:23PM - 09 Apr 26 UTC

closed 09:05PM - 30 Apr 26 UTC

jbemmel

bug mojo

### Bug description Running a small single-file Mojo program that evaluates a s…tring-literal XPath-like expression (Expr.string → visit_string) reproducibly terminates with SIGSEGV (exit 128+11, shell exit 139). The AST built in main is only a STRING node; the visit_call implementation is not / should not get invoked for that input, but including the body of visit_call (with Variant/List/Arc/copy() on XPathNode) appears to cause process crashes: trimming or stubbing that path has been observed to yield normal exit (0). This looks like a compiler or runtime bug (bad codegen, bad lowering, or runtime/async interaction), not a logic error in the string-literal path. ### Steps to reproduce ```mojo ## Standalone SIGSEGV repro (exit 139). Only paths/types needed for `Expr.string` + load-bearing `visit_call`. ## ## pixi run mojo -I tests/standalone_crash.mojo from std.collections import List from std.memory import ArcPointer, UnsafePointer, alloc from std.utils import Variant comptime Arc = ArcPointer @fieldwise_init struct Token(Copyable): comptime Type = UInt8 comptime STRING: Self.Type = 3 var type: Self.Type var start: Int var length: Int def text(self, source: String, strip_quotes: Bool = False) raises -> String: if strip_quotes and self.type == Self.STRING: return String( source[byte=self.start + 1 : self.start + self.length - 1] ) return String(source[byte=self.start : self.start + self.length]) struct Expr(Movable): comptime ExprPointer = UnsafePointer[Self, MutExternalOrigin] comptime Kind = UInt8 comptime STRING: Self.Kind = 1 comptime CALL: Self.Kind = 2 var kind: Self.Kind var value: Token var args: List[Arc[Self]] def __init__(out self, kind: Self.Kind, value: Token, var args: List[Arc[Self]]): self.kind = kind self.value = value.copy() self.args = args^ @staticmethod def string(v: Token) -> Self.ExprPointer: var ptr = alloc[Self](1) ptr.init_pointee_move(Self(Self.STRING, v, List[Arc[Self]]())) return ptr @fieldwise_init struct XPathNode(Movable): var path: String comptime EvalResult = Variant[Float64, String, Bool, List[Arc[XPathNode]]] @fieldwise_init struct EvalContext: var expression: String trait ExprEvalVisitor: def visit_string( self, ref node: Expr, ctx: EvalContext, current: Arc[XPathNode] ) raises -> EvalResult: return EvalResult("") def visit_call( self, ref node: Expr, ctx: EvalContext, current: Arc[XPathNode] ) raises -> EvalResult: return EvalResult(0.0) def dispatch_expr[V: ExprEvalVisitor]( visitor: V, ref node: Expr, ctx: EvalContext, current: Arc[XPathNode] ) raises -> EvalResult: if node.kind == Expr.STRING: return visitor.visit_string(node, ctx, current) if node.kind == Expr.CALL: return visitor.visit_call(node, ctx, current) return EvalResult(0.0) def eval_accept[V: ExprEvalVisitor]( visitor: V, root: Expr.ExprPointer, ctx: EvalContext, current: Arc[XPathNode] ) raises -> EvalResult: return dispatch_expr(visitor, root[], ctx, current) struct XPathEvaluator(ExprEvalVisitor): fn __init__(out self): pass def eval( self, expr: Expr.ExprPointer, current: Arc[XPathNode], expression: String ) raises -> EvalResult: var ctx = EvalContext(expression) return eval_accept(self, expr, ctx, current) def visit_string( self, ref node: Expr, ctx: EvalContext, read `_`: Arc[XPathNode] ) raises -> EvalResult: return EvalResult(node.value.text(ctx.expression, strip_quotes=True)) def visit_call( self, ref node: Expr, ctx: EvalContext, current: Arc[XPathNode] ) raises -> EvalResult: var name = node.value.text(ctx.expression) if name == "string": if len(node.args) == 1: var a = dispatch_expr(self, node.args[0][], ctx, current) var fv = a if fv.isa[List[Arc[XPathNode]]](): ref nodes = fv[List[Arc[XPathNode]]] if len(nodes) > 0: # Crash happens here _ = EvalResult(nodes[0].copy()) return EvalResult(0.0) def main() raises: var root = ArcPointer[XPathNode](XPathNode("/")) var ex = "'hello'" var tok = Token(type=Token.STRING, start=0, length=7) var ptr = Expr.string(tok) var ev = XPathEvaluator() _ = ev.eval(ptr, root, ex) ``` ### System information OS: Linux x86_64 Mojo: 0.26.2.0 (build d627decc) — from mojo --version via Pixi

I appreciate that the team is taking care of things, but would it be possible to get a little more than “issue closed”? Like the version in which it was fixed, or ideally some words around what the problem was and how it was addressed.

denis · April 30, 2026, 11:12pm

Hey Jeroen!

First, thank you for submitting the bug reports! This is incredibly valuable for the team, being able to see first-hand defects and examples from people like you!

Your point about “can we have more visibility” is very reasonable. Let me explain what happens now, and then let us think what we can do to improve.

Why you don’t see the comments: Modular uses a different issue tracking system internally, so when you open a bug report on Github, it gets mirrored to that system. The communication that happens inside (all the comments and fix details) is not mirrored back. When the issue is closed (fixed, rejected, etc) only then the issue tracking system talks to Github and reflects that status. So yes, what you see from the outside is just “issue closed”.

What “fixed” means: When the issue is closed as “fixed”, this means the fix has been submitted to our internal repo and to CI, and it will be available in the next Mojo nightly. Unless the nightly build fails, the fix will be available on the nightly channel next day.

Now, I want to say again that your point is correct and the current situation is not good. We will have to solve this problem in the coming months, simply because one cannot have an open-sourced software but a closed-and-invisible issue tracking. If mojo to be open source and worked on by the community, its issue tracking has to adapt.

@BradLarson tagging you here for visibility, as this is one of the problems we need to solve in the coming months.

From now on, we will encourage the engineers to take an extra step and copy the fix info into Github issues whenever possible.

jbemmel · April 30, 2026, 11:46pm

Thanks @denis , I appreciate the quick turnaround, and understand the trade-offs. Perhaps a simple tag with the version in which it got / will be fixed could be a good start?

Or maybe your internal system supports GitHub Action or a bot that posts an automated comment upon closing an issue:

“This issue was resolved internally and the fix is included in Mojo Version 26.x.x. Please update your toolchain to verify.”

denis · May 1, 2026, 12:05am

That’s a great suggestion!

@ahajha what do you think, is that something we could pursue?

ahajha · May 1, 2026, 1:48am

@denis It’s worth exploring. There would be a couple extra “hops” to jump through but it should be possible. Feel free to make an (internal) issue

Topic		Replies	Views
Missed Variant type errors can lead to hard-to-debug runtime crashes Mojo	2	63	April 23, 2026
Compiler crash blocking me from debugging a pointer issue Mojo	0	36	March 15, 2026
What Was Your Biggest “Wait, What?” Moment in Mojo? Mojo	45	1077	April 1, 2026
I have discovered a suspect efficiency anomaly in the mojo compiler, how to proceed? Mojo discussion , mojo-compiler , 25_1	20	416	March 8, 2025
Bugs: Mojo Test - Crashes when non-test file contains a struct with a parameter Mojo discussion	12	175	October 20, 2025

Feedback on bug reports beyond "closed"

Related topics