Giters

ssbc / ssb-db2

A new database for secure-scuttlebutt

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Crash: Attempt to access memory outside buffer bounds

Powersource opened this issue · comments

commented

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"

commented

@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.

commented

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 ?

commented

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?

commented

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.

commented

Yep agree. We should in any case handle that. No matter how it happened.

commented

Omg GitHub 🙃 I replied on email but that didn't end up here. But yeah latest version

commented

Jitdb 6.6.2 published. I'll try to release a new Manyverse version soon. Let's assume this specific issue is fixed

commented