Repository navigation
Fix Windows startup stack overflow - #10
Closed
chrislearn wants to merge 14 commits into
Closed
chrislearn wants to merge 14 commits into
chrislearn wants to merge 14 commits into
Conversation
Repoint all 13 makepad crate dependencies and the lockfile from makepad/makepad to the OctoSense-org fork. The revision is unchanged (74b63be8), so the resolved source is byte-identical — this only moves the pin onto a repository we control, so upstream's work branch cannot move under us and patches have somewhere to land. The rev is reachable from refs/heads/pin/octosense-74b63be8 in the fork, which is what lets cargo fetch it. Claude-Session: https://claude.ai/code/session_01GR1KyERPDtrF9FgZ9HvWqt Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The repoint left the dependency graph resolving makepad from two sources
at once, and the hand-edited lockfile did not parse at all:
package `ab_glyph_rasterizer` is specified twice in the lockfile
Root cause: makepad vendors ~100 third-party crates inside its own
repository and references them from its own git URL. Repointing only the
13 top-level dependencies leaves those internal references on
makepad/makepad, so cargo resolves the same crates from both that URL and
the fork — 105 duplicated package names, 264 packages where there were
159. That is the two-copies-of-makepad-widgets hazard, reintroduced.
Rewriting the lockfile by hand cannot fix it, because the second source
comes from makepad's own manifests, not from ours.
Restores Cargo.toml and Cargo.lock to e096273. Verified: cargo metadata
exits 0, 111 makepad packages from a single source, 159 packages total,
and cargo leaves the lockfile byte-identical.
Moving onto the fork needs source replacement or fork-internal manifest
rewrites, not a URL swap. Tracked separately.
Claude-Session: https://claude.ai/code/session_01GR1KyERPDtrF9FgZ9HvWqt
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
…-org#4) Converges makepad onto the fork without touching Cargo.toml or Cargo.lock. The earlier attempt rewrote the dependency URLs directly and broke the build: makepad vendors ~100 third-party crates inside its own repository and references them from its own git URL, so repointing only our 13 top-level dependencies left those internal references on makepad/makepad. Cargo then resolved the same crates from both URLs — 105 duplicated package names, 264 packages where there were 159, and a lockfile that no longer parsed. Source replacement fixes this at the right layer. The dependency identity stays makepad/makepad, which is the identity makepad's own manifests use, so the graph stays single-source and the lockfile is untouched. Only the bytes are served from the fork. Verified: cargo check --workspace exits 0 with zero errors, and cargo leaves Cargo.lock byte-identical. Source replacement was separately proven to genuinely serve from the fork by resolving a commit that exists only there, with the git cache cleared. Bump both revs together when moving the pin. Claude-Session: https://claude.ai/code/session_01GR1KyERPDtrF9FgZ9HvWqt Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
…toSense-org#5) Both manifests this time. The previous attempt repointed only the root Cargo.toml and missed apps/reference/Cargo.toml, which declares its own makepad-widgets and makepad-app-module. With one manifest on each URL cargo resolved the same crates twice — 105 duplicated package names, 264 packages where there were 159 — and the hand-edited lockfile stopped parsing. That is the whole cause. The .cargo/config.toml source replacement added in the previous commit was written against a wrong diagnosis (that makepad self-references its own git URL from ~100 internal manifests; those 98 occurrences are homepage/repository metadata, and makepad's internal crates are path deps). Source replacement worked, but it is not needed once both manifests agree, so it is removed rather than left as unexplained indirection. Also moves the pin from 74b63be8 to 8c23d577 — the fork's octoscript branch, which is upstream work plus the Splash isolate host-mod hook. That is the same revision Octoscript-Makepad now builds against, so both products sit on one repository and one commit. Verified from a clean clone with a regenerated lockfile: cargo check --workspace exits 0, 120 makepad entries all from the fork, 0 from upstream, 159 packages — matching the pre-change baseline. Claude-Session: https://claude.ai/code/session_01GR1KyERPDtrF9FgZ9HvWqt Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
…llpaper Add OctoSense light theme and matching desktop wallpapers
Fix OctoSense name in macOS menu bar
… VM hardening Tree-identical to the vm-port/integration revision this workspace was verified against (cargo check clean); every OctoSense-org repo now shares this commit. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JgSir4cQyaakzPju4h6smw
…toscript-1fdce27 deps: pin makepad to octoscript 1fdce27 (ported Octoscript VM)
…76e52) Replace rev 1fdce273 with 9069cfaf in Cargo.toml (13 crates), apps/reference/Cargo.toml, and Cargo.lock. The lock was re-resolved with `cargo update -p makepad-widgets` because the upstream tree changed (log/ctrlc -> makepad-error-log, vendored unicode-ident). Verified: cargo check (default members) Finished; cargo check -p octosense-reference Finished. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JgSir4cQyaakzPju4h6smw
…toscript-9069cfa deps: pin makepad to octoscript 9069cfa (synced with upstream work d476e52)
Move the OctoSense-org/makepad `octoscript` pin from 9069cfaf to 712b9f16 (fork PR OctoSense-org#3: 17 upstream `dev` commits picked, incl. Splash isolate theme/panic containment, on_item_tap, Apply::Rebake). Cargo.toml (13 lines), apps/reference/Cargo.toml and Cargo.lock updated in place; `cargo metadata --locked` resolves without a `cargo update`. Verified: `cargo check` Finished; `cargo check -p octosense-reference` Finished. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JgSir4cQyaakzPju4h6smw
…toscript-712b9f1 deps: pin makepad to octoscript 712b9f1 (dev picks #1208–#1232)
Contributor
|
Thanks for this fix, @chrislearn — the Windows startup stack overflow is still worth landing. 🤖 Generated with Claude Code |
ymote
added a commit
that referenced
this pull request
Sep 27, 2026
Fix Windows startup stack overflow (port of #10 by @chrislearn)
chrislearn
pushed a commit
to chrislearn/OctoSense
that referenced
this pull request
Sep 29, 2026
…main-7f468bb9 Home: pin AppCard main (7f468bb9) for octos-app, Mail and Camera
chrislearn
pushed a commit
to chrislearn/OctoSense
that referenced
this pull request
Sep 29, 2026
CI now also runs the tests of octosense-app-hub-app, octosense-maps, octosense-news and octosense-appcard. The catalog-merge test uses the apphub module id and hub:<manifest-id> installed ids. home-migration.md records the second sync from mobile and updates the dispositions of PRs OctoSense-org#10 and OctoSense-org#11 and 45dbbfb. home-build.md describes the in-tree App Hub crate. The backlog lists the review's follow-ups (hub: ids in Android placements, installed-app reads, find_app's card fallback, old appstore ids, small cleanups, Calendar). The plan marks conflicted files resolved with git add in Tasks 3-7.
chrislearn
pushed a commit
to chrislearn/OctoSense
that referenced
this pull request
Sep 29, 2026
…hub-3e993d4c Host services: App Hub 3e993d4c
chrislearn
pushed a commit
to chrislearn/OctoSense
that referenced
this pull request
Sep 29, 2026
…artup-stack Fix Windows startup stack overflow (port of OctoSense-org#10 by @chrislearn)
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Windows reserves a 1 MiB main-thread stack by default. During startup, OctoSense's Makepad script and widget construction exceeds that reserve and exits with
STATUS_STACK_OVERFLOWbefore the window appears.This change adds a Windows MSVC linker setting that reserves 16 MiB for the executable's main-thread stack. PE stack pages are committed lazily, so this adds address-space headroom without committing 16 MiB up front. It also gates Unix-only process cleanup imports and variables so the Windows build no longer reports those unused-code warnings.
Validation:
cargo build --release --bin octosensecargo run --releasereached the D3D11 first frame and remained runningtarget\release\octosense.exe --galleryremained running through the deeper gallery startup pathdumpbin /headersreports a0x1000000stack reserve (16 MiB)cargo test --workspace --releasecompleted 206 tests successfully and exposed 5 existing Windows-only assertion failures where tests assume a Unixcargofilename or/path separators. Those assertions are outside this startup fix.