Closed Powersource closed 2 years ago
@Powersource please also give as many details as possible. Like the most important here would be the version of Manyverse so that we can "decode" that stack trace.
Assuming it's 0.2206.3, the stack trace is
RangeError [ERR_BUFFER_OUT_OF_BOUNDS]: Attempt to access memory outside buffer bounds
at boundsError (internal/buffer.js:79:11)
at Buffer.readUInt32LE (internal/buffer.js:215:5)
at /data/user/0/se.manyver/files/nodejs-project/index.js:27308:25
at FSReqCallback.readFileAfterClose [as oncomplete] (internal/fs/read_file_context.js:63:3)
That line 27308
is this in jitdb:
function readFileAndCheckCRC(filename, cb) {
readFile(filename, (err, buf) => {
if (err) return cb(err)
const crcFile = buf.readUInt32LE(3 * FIELD_SIZE) // <---------------
buf.writeUInt32LE(0, 3 * FIELD_SIZE)
const crc = crcCalculate(buf)
if (crcFile !== 0 && crc !== crcFile) return cb('crc check failed')
cb(null, buf)
})
}
The obvious way to interpret this (I think!) is that an index file in jitdb is basically empty, and reading the header causes a crash. An interesting bit is that the previous crash report you sent was this:
User comment: i opened the app and started scrolling the public feed, crashed after like 1 sec total
Stack trace from Node.js:
EBADF: bad file descriptor, write
Error: EBADF: bad file descriptor, write
I'm not sure if that means whether atomic-file-rw
is not truly atomic, or whether there is something else funky going on, like the index file was saved and then got corrupted such that it got truncated to zero size or something.
Thoughts @arj03 ?
Perhaps when loading a file we can check if its size is at least the header size, and if not, then delete the file? Or initialize the header with sensible defaults?
Yeah in fact it seems safe to just throw an error because in everyplace in jitdb where we load files, if there is any error, we fallback to silently recreating the index.
Yep agree. We should in any case handle that. No matter how it happened.
Omg GitHub 🙃 I replied on email but that didn't end up here. But yeah latest version
Jitdb 6.6.2 published. I'll try to release a new Manyverse version soon. Let's assume this specific issue is fixed
version 0.2206.3-beta-indie
There's more info in the reports on gitlab
Jacob
On Sun, Jun 26, 2022, 17:28 André Staltz @.***> wrote:
@Powersource https://github.com/Powersource please also give as many details as possible. Like the most important here would be the version of Manyverse so that we can "decode" that stack trace.
— Reply to this email directly, view it on GitHub https://github.com/ssbc/ssb-db2/issues/358#issuecomment-1166564787, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAK4M5YHCPOMWPCC3BY2FPDVRBZKRANCNFSM5Z35XKDA . You are receiving this because you were mentioned.Message ID: @.***>
I'm getting crashes immediately every time I open manyverse android since a few days ago. This is the stack trace from one of the error reports.
"java.lang.Exception: Attempt to access memory outside buffer bounds\\nRangeError [ERR_BUFFER_OUT_OF_BOUNDS]: Attempt to access memory outside buffer bounds\\n at boundsError (internal\/buffer.js:79:11)\\n at Buffer.readUInt32LE (internal\/buffer.js:215:5)\\n at \/data\/user\/0\/se.manyver\/files\/nodejs-project\/index.js:27308:25\\n at FSReqCallback.readFileAfterClose [as oncomplete] (internal\/fs\/read_file_context.js:63:3)\n\tat se.manyver.MainActivity$1$1.invoke(MainActivity.java:96)\n\tat se.manyver.MainActivity$1$1.invoke(MainActivity.java:94)\n\tat com.janeasystems.rn_nodejs_mobile.RNNodeJsMobileModule.sendMessageBackToReact(RNNodeJsMobileModule.java:258)\n\tat com.janeasystems.rn_nodejs_mobile.RNNodeJsMobileModule.sendMessageToApplication(RNNodeJsMobileModule.java:220)\n\tat com.janeasystems.rn_nodejs_mobile.RNNodeJsMobileModule.startNodeWithArguments(Native Method)\n\tat com.janeasystems.rn_nodejs_mobile.RNNodeJsMobileModule$3.run(RNNodeJsMobileModule.java:190)\n\tat java.lang.Thread.run(Thread.java:923)\n"