This repository was archived by the owner on Oct 9, 2026. It is now read-only.
Repository navigation
fix: no recovered nil dereference on each Telegram API call - #30
Merged
Merged
Conversation
telego formats every response's Error for a debug log whatever the log level, and a successful response's Error is nil, so fmt recovered a nil dereference on each API call. On Windows hosts whose CPUs have AMX, recovering such a hardware fault can corrupt the heap below the goroutine stack (golang/go#81238); the windows-latest CI job crashed once in the Telegram tests with 'found pointer to free object'. The bot's API caller now gives each response an Error. The caller is built as telego would build it: its fasthttp client, or net/http with a proxy.
mekjr1
force-pushed
the
fix/telegram-api-fault
branch
from
October 7, 2026 17:19
a5fbf2e to
9c883f2
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On windows-latest, CI crashed once in the Telegram tests with
fatal error: found pointer to free object(run 37564359695), and passed on rerun.Cause. telego's
performRequestbuildsresponse.String()for a debug log before checking the log level. A successful response'sErroris a nil*telegoapi.Error, andString()formats it with%v, sofmtcalls(*Error).Error()on nil, which dereferences it.fmtrecovers that panic silently. That is a recovered hardware fault on every successful Telegram API call, in production too: polling, every send.On Windows hosts whose CPUs have AMX, recovering a hardware fault can corrupt the heap below the goroutine stack, and a later GC throws exactly this error: golang/go#81238. The fix is open in Go (CL 828724), not released. Our crash matches the issue's case: windows/amd64 on GitHub's runners, a size-16 span, intermittent by host. GitHub's Windows pool includes AMX Xeons, and so does any Windows server or VM on a recent Xeon.
Fix. The bot's API caller gives every response an
Error(errorFillingCaller), so the debug formatting never dereferences nil. telego only reads a successful response'sErrorunderWithWarnings(), which Compa doesn't use. The caller is built as telego would build it: its fasthttp client, ornet/httpwith a proxy as before. That makes fasthttp a direct dependency ingo.mod. The Telegram tests wrap their stub callers the same way.Evidence.
dlv trace --test 'runtime\.panicmem'over the Telegram tests: 52 recovered faults before, all fromtelegoapi.(*Error).Error<-telegoapi.Response.String; 0 after. I couldn't reproduce the crash locally: no AMX on this machine; 210 stress runs withGOGC=5,clobberfreeand checkptr were clean.Test:
TestErrorFillingCaller.