CesiumGS / gltf-pipeline

When I run draco compress. It shows the Bus error: 10

Here is the script, I ran on the terminal. My node version is v16.13.0.

gltf-pipeline -i room.glb -o compress.gltf --draco.compressionLevel=10

2021-12-08.2.13.58.mov

If it is required to provide the glb file please let me know the email address.

Thanks a lot.

Interesting, I haven't seen that before.

@Kcin1993 could you send the glb to support@cesium.com and mention this issue in the email?

@lilleyse Thanks. The email was sent. 😃

I got the same bus issue with a specific .gltf file (that was first converted from fbx). The gltf shows 19 errors in gltf-viewer, but it still loads.

The specific line is

gltf-pipeline/lib/compressDracoMeshes.js

Line 264 in 901c94f

const encodedLength = encoder.EncodeMeshToDracoBuffer(

.

What's even worse is that listening to such signal (process.on('SIGBUS', ...) ) causes the whole process to hang -- still don't know why.

Here's some minimal js code that reproduces the issue. Remove the process.on('SIGBUS'...) to see the node process crash and show the bus error.

const fsExtra = require("fs-extra");
const processGltf = require("./lib/processGltf");
const gltf = fsExtra.readJsonSync("./broken.gltf");
const options = {
  dracoOptions: {
    compressionLevel: 10,
  },
};

processGltf(gltf, options).then(function (results) {
  fsExtra.writeJsonSync("model-draco.gltf", results.gltf);
}, function (error){
  console.log(error);
});

// not having process.on makes it crash with the bus error
process.on('SIGBUS', (signal) => {
  console.log('here', signal);
})

If I force draco 1.3.6, before they disabled the flags NODEJS_CATCH_EXIT and NODEJS_CATCH_REJECTION, I get this error instead (rather than bus error). Could it be a side-effect of google/draco#629 ?

RangeError: Maximum call stack size exceeded
RangeError: Maximum call stack size exceeded
RangeError: Maximum call stack size exceeded
RangeError: Maximum call stack size exceeded
RangeError: Maximum call stack size exceeded
RangeError: Maximum call stack size exceeded
RangeError: Maximum call stack size exceeded
    at deferUnhandledRejectionCheck (/Users/luis/workspace/Git/deteleTarget/node_modules/bluebird/js/release/debuggability.js:50:9)
    at Promise._ensurePossibleRejectionHandled (/Users/luis/workspace/Git/deteleTarget/node_modules/bluebird/js/release/debuggability.js:70:5)
    at Promise._reject (/Users/luis/workspace/Git/deteleTarget/node_modules/bluebird/js/release/promise.js:694:14)
    at Promise._rejectCallback (/Users/luis/workspace/Git/deteleTarget/node_modules/bluebird/js/release/promise.js:509:10)
    at doThenable (/Users/luis/workspace/Git/deteleTarget/node_modules/bluebird/js/release/thenables.js:67:17)
    at tryConvertToPromise (/Users/luis/workspace/Git/deteleTarget/node_modules/bluebird/js/release/thenables.js:28:20)
    at Promise._resolveCallback (/Users/luis/workspace/Git/deteleTarget/node_modules/bluebird/js/release/promise.js:465:24)
    at resolve (/Users/luis/workspace/Git/deteleTarget/node_modules/bluebird/js/release/thenables.js:73:17)
    at Object.Module.then (/Users/luis/workspace/Git/deteleTarget/node_modules/draco3d/draco_encoder_nodejs.js:39:40258)
    at Object.tryCatcher (/Users/luis/workspace/Git/deteleTarget/node_modules/bluebird/js/release/util.js:16:23)
    at doThenable (/Users/luis/workspace/Git/deteleTarget/node_modules/bluebird/js/release/thenables.js:63:38)
    at tryConvertToPromise (/Users/luis/workspace/Git/deteleTarget/node_modules/bluebird/js/release/thenables.js:28:20)
    at Promise._resolveCallback (/Users/luis/workspace/Git/deteleTarget/node_modules/bluebird/js/release/promise.js:465:24)
    at resolve (/Users/luis/workspace/Git/deteleTarget/node_modules/bluebird/js/release/thenables.js:73:17)
    at Object.Module.then (/Users/luis/workspace/Git/deteleTarget/node_modules/draco3d/draco_encoder_nodejs.js:39:40258)
    at Object.tryCatcher (/Users/luis/workspace/Git/deteleTarget/node_modules/bluebird/js/release/util.js:16:23)

broken.gltf.zip

The gltf shows 19 errors in gltf-viewer, but it still loads.

The input model is invalid. It contains an accessor that contains NaN elements. One can not expect Draco to work on an invalid input model. As such, this is a question about the exact error handling/reporting mechanism that Draco uses, and not an issue of gltf-pipeline.

When making the model valid, everything works as expected.

broken-fixed-and-processed.zip

Thanks for the reply and help! While I understand that, I was wondering if gltf-pipeline can perform some specific validation that avoids the bus error to begin with. I wonder if using the gltf validator you linked in the email (https://www.npmjs.com/package/gltf-validator) is a bit too much, as some models with some errors end up working through gltf-pipeline and draco fine. I will give it a try, but most of our users download models from the internet, and they often contain some errors that do not seem to affect the outcome of the pipeline and draco (or some editors can still load them, somehow).

For reference, what was the exact accessor with the issue?

Edit:
javagl kindly replied the email with an example of the accessor issue:
... ( 0.00000, 1.00000), (36287219762535574000000000.00000, 1.00000), ( 0.00000, 1.00000), ... ( 0.00000, 1.00000), (15196623764577712000000000.00000, 1.00000), ( -0.00000, 1.00000), ( NaN, NaN)]

I was then also able to view those values through Ceium's glTF Tools vscode extension (https://marketplace.visualstudio.com/items?itemName=cesium.gltf-vscode):

Bus error: 10 When darco compression

Bus error: 10 When darco compression