I am generating a simple glb file like this (in nodejs):
import * as THREE from 'three';
import { GLTFExporter } from './../src/gltfexport.js'; // std example just modified to avoid using filereader
import fs from 'fs/promises';
const geometry = new THREE.PlaneGeometry(1, 1, 100, 100);
geometry.computeVertexNormals();
const material = new THREE.MeshStandardMaterial({
vertexColors: false,
wireframe: false,
});
const mesh = new THREE.Mesh(geometry, material);
const exporter = new GLTFExporter();
const result = await exporter.parseAsync(mesh, { binary: true });
if (result instanceof ArrayBuffer) {
await fs.writeFile('terrain-mesh.glb', Buffer.from(result));
console.log('GLB exported successfully.');
}
I’ve attached the resulting glb file.
terrain-mesh.glb (437.1 KB)
I can open it normally with windows 3d viewer, blender, but it leads (most often, but not always !) to a crash ONLY when I use Edge or Chrome (for instance with gltf-viewer.donmccurdy.com). Works fine on Firefox. The Edge error says: STATUS_BREAKPOINT
The gltf file validation says that the file is OK.
I’ve spent countless hours trying to understand what’s wrong but I can’t find anything.
What can be wrong?
I am using Three 0.177.0
It loads fine in:
the “STATUS_BREAKPOINT” is suspicious.. are you sure you don’t have some breakpoints set in the debugger, or in a vscode instanced attached to your browser window?
No debugger attached, using Edge Version 138.0.3351.55 (Official build) (64-bit).
The same happens with latest chrome.
I am able to reproduce it on a very high end machine as well as a low end one.
Out of curiosity, do you get the same error with a gltf file exported from blender or similar?
Do you have any extensions installed in either chrome/edge?
I cannot repro this with the asset you provided.. (in chrome)
No extensions at all.
Confirmed on a third PC.
For those who cannot reproduce, what’s your browser version?
Many thanks
Version 137.0.7151.120 (Official Build) (64-bit)
I encountered (and reported to Chrome) the STATUS_BREAKPOINT error. In my case, I could actually see visual glitches (like black paint chips flickering) in the DOM page on the source. My solution was to filter things (especially special things) and try to interleave updates.
Multiple factors contributed to the overload:
- Sandbox development caused tab RAM to grow from 400MB to 4GB rapidly, via refresh of network resources.
- texture sample was complex: deep clone hierarchy, interactive listeners, and memory-critical prototype.
- requestAnimationFrame functions were not yet over-optimized to release memory or handle error bubbling of resource fragments.
- imports could be configured to convert a smaller filetype, or alternate imports could release memory better (in a loop).
- GPU paint layer was forcefully invoked
Your friend,
Vlad “Unfriendly” Vladovstok
BYOB… I opened your file. It is a square white plane. I had this knowledge prior to formulating a correspondence.
@kpachinger I’m not sure how these comments apply to the question. The file has no textures, texture sampling does not involve JavaScript listeners or prototypes, the issue occurs in a production viewer (not a sandbox), it’s very unclear what memory you’d release, etc.
If you’re using an LLM to to generate answers to questions, please mark comments accordingly. If you’re just using an LLM to help translate from your preferred language, or to improve style and grammar while writing the content yourself, that is of course fine and doesn’t (IMO) need to be indicated.
1 Like
@donmccurdy
It’s a direct reply to the titular concept. Furthermore, I’m obviously not an LLM. You have joined several of the words I used in ways they weren’t provided, and suggested that may be my intention. See above the orderly contribution of terms useful to the progress of development. OP may use them to search or debug. See below how I clarify to you personally.
I’ve politely replied to OP and you. Personally I find you charming and ambitious. I’m not a serial abuser harming a fragile open community. I provided a similar use case for an erratic and specific error message, within the context of ThreeJS limited documentation. Users may be beginner or advanced, but suffice it to say I’ve provided the only meaningful discouse so far to the OP. There is no need for lavish topical appropriation. I’m not panhandling black-market tech support warranties. If you don’t find this disclosure more helpful… I agree!
If I must further subject parties to my rationale, it would be that: as resources become exhausted/overwritten the pixel data is mutated/corrupt. That is a pleasant conversational response which I believe may help a non-verbose error.
I think the chromium team may already have corrected the bug in the beta version of chrome.
Version 138.0.7204.50 (Build officiel) (64 bits) => leads to a crash
Version 139.0.7258.5 (Build officiel) beta (64 bits) => perfectly fine
@manthrax could you please try the current official version 138.0.7204.50 ?
If it indeed crashes, I think it’s safe to say that we should not worry too much about this bug that only appears somewhere between 137.0.7151.120 and 139.0.7258.5
I bet we could find the same results on edge
Oh wow yeah.
Just did the update to:
Version 138.0.7204.50 (Official Build) (64-bit)
and sure enough:
Google broke something!
What’s weird is that other more complex apps seems to be working.. must be some edge case:
@donmccurdy
When I load : https://gltf-viewer.donmccurdy.com/
I see this in the console.. dunno if related:
Then if I drag OPs plane mesh in, I see it for a split second then get the STATUS_BREAKPOINT page crash.
Nothing else in the console to indicate any problems leading up to the crash:
edit: I put a breakpoint in your render loop.. and it’s getting called normally for about 10 frames.. but then chrome dies.
So maybe related to some other process that is started at model load time, but only completes after a few frames have rendered?
@kpachinger might be on to something. 
Also @kpachinger forgive me for asking, but is english your first language? You speak like a time traveller! It’s super fascinating… <3
fwiw I can’t reproduce this anywhere but gltf-viewer so far.
Which does kinda make sense, since gltf-viewer has to load every possible variation of loader/texture/compression plugin around for compatibility.
@kpachinger Do you have a link to your bug report on chrome for this issue? I want to see if there is anything about it…
@manthrax the same issue appears on babylonjs’ viewer too !
1 Like
I see my note on February 23, 2025 of STATUS_BREAKPOINT. There would also be a repo commit (with the unusual visual artifacts). I submitted the description/screenshot in the Chrome/Help/Report a Bug… so there is no ticket. I searched Chromium Bug Forum and there are about 150 listed tickets for STATUS_BREAKPOINT.
I speak English primarily (and well) but it’s debatable why I’m not flowing grammatically. The effort is lost.
1 Like
Nah.. just unexpected. 
I feel like i’m talking to diogenes (in a good way)
For anyone interested:
Looks like multiple related reports..
Might be worth dropping this exact repro as a new bug report..
gltf-viewer + the subdivided plane mesh
since it seems sporadic for other people.
I noticed the same crash error with web application that are using gltf/validator.
After installed Version 139.0.7258.5 Beta Google Chrome the crash is no longer happening.
1 Like
