nssm crashes
ohitstom opened this issue · comments
windows 10, nssm
panic: runtime error: index out of range [3] with length 0 [recovered]
panic:
== Recovering from initIndex crash ==
File Info: [ID: 1, Size: 10915, Zeros: 2726]
isEnrypted: false checksumLen: 0 checksum: indexLen: 0 index: []
== Recovered ==
goroutine 22 [running]:
github.com/dgraph-io/badger/v3/table.(*Table).initBiggestAndSmallest.func1.1()
/go/pkg/mod/github.com/dgraph-io/badger/v3@v3.2103.5/table/table.go:351 +0xa8
github.com/dgraph-io/badger/v3/table.(*Table).initBiggestAndSmallest.func1()
/go/pkg/mod/github.com/dgraph-io/badger/v3@v3.2103.5/table/table.go:397 +0xc2
panic({0x153cce0, 0xc001074648})
/usr/local/go/src/runtime/panic.go:884 +0x213
github.com/google/flatbuffers/go.GetUint32(...)
/go/pkg/mod/github.com/google/flatbuffers@v23.5.26+incompatible/go/encode.go:47
github.com/google/flatbuffers/go.GetUOffsetT(...)
/go/pkg/mod/github.com/google/flatbuffers@v23.5.26+incompatible/go/encode.go:121
github.com/dgraph-io/badger/v3/fb.GetRootAsTableIndex(...)
/go/pkg/mod/github.com/dgraph-io/badger/v3@v3.2103.5/fb/TableIndex.go:14
github.com/dgraph-io/badger/v3/table.(*Table).readTableIndex(0xc000140240)
/go/pkg/mod/github.com/dgraph-io/badger/v3@v3.2103.5/table/table.go:707 +0x15e
github.com/dgraph-io/badger/v3/table.(*Table).initIndex(0xc000140240)
/go/pkg/mod/github.com/dgraph-io/badger/v3@v3.2103.5/table/table.go:462 +0x19d
github.com/dgraph-io/badger/v3/table.(*Table).initBiggestAndSmallest(0xc000140240)
/go/pkg/mod/github.com/dgraph-io/badger/v3@v3.2103.5/table/table.go:401 +0x7f
github.com/dgraph-io/badger/v3/table.OpenTable(0xc00033c240, {0x0, 0x1, 0x200000, 0x0, 0x0, 0x3f847ae147ae147b, 0x1000, 0x0, 0x1, ...})
/go/pkg/mod/github.com/dgraph-io/badger/v3@v3.2103.5/table/table.go:308 +0x272
github.com/dgraph-io/badger/v3.newLevelsController.func1({0xc0010aa280, 0x4d}, {0x0?, 0x0?, 0x0?})
/go/pkg/mod/github.com/dgraph-io/badger/v3@v3.2103.5/levels.go:150 +0x1f9
created by github.com/dgraph-io/badger/v3.newLevelsController
/go/pkg/mod/github.com/dgraph-io/badger/v3@v3.2103.5/levels.go:129 +0x585
badger 2023/10/23 21:49:21 INFO: All 1 tables opened in 0s
panic: runtime error: index out of range [3] with length 0 [recovered]
panic:
== Recovering from initIndex crash ==
File Info: [ID: 1, Size: 10915, Zeros: 2726]
isEnrypted: false checksumLen: 0 checksum: indexLen: 0 index: []
== Recovered ==
goroutine 66 [running]:
github.com/dgraph-io/badger/v3/table.(*Table).initBiggestAndSmallest.func1.1()
/go/pkg/mod/github.com/dgraph-io/badger/v3@v3.2103.5/table/table.go:351 +0xa8
this error seems to just keep repeating and the stdout only contains
Socket: C:\WINDOWS\TEMP\jfa-go.sock
2023/10/23 21:49:47 Using internal storage
this happened after a power cut so i thought db, however running jfa-go.exe from commandline works fine its just nssm that is causing this crash
jfa-go version: git (43e36ee)
very weird, are you running the same command nssm does, with the same arguments?
very weird, are you running the same command nssm does, with the same arguments?
yeah I mean it should be identical I'm not sure why its giving me this error
the only thing i can recommend is to check that everything's identical: the user jfa-go runs as, the config & data paths, and anything else you can think of. A google says that the error given sometimes happens after the programs using this database crash unexpectedly, however if running jfa-go from the command line can still open the database, then i dont know what could be wrong.
A little more googling and you might have hit the jackpot of unlucky, apologies as it seems this update has been very unkind to you. Almost every person who's had the specific error was running the database on windows, and had a sudden loss of power. No-one I saw was able to fix the corrupted database, so all I can suggest is making frequent backups. Per request of another user i'll be adding an import/export feature soon-ish that should make doing that easier, for now, you'll need to stop jfa-go periodically, make a copy of the db/ folder, then start jfa-go again. Sorry again.
A little more googling and you might have hit the jackpot of unlucky, apologies as it seems this update has been very unkind to you. Almost every person who's had the specific error was running the database on windows, and had a sudden loss of power. No-one I saw was able to fix the corrupted database, so all I can suggest is making frequent backups. Per request of another user i'll be adding an import/export feature soon-ish that should make doing that easier, for now, you'll need to stop jfa-go periodically, make a copy of the
db/folder, then start jfa-go again. Sorry again.
damn I really am unlucky recently lol
no need to apologize I had a backup but it's a few weeks out of date, what sorts of stuff will the database hold? will I need to reset user passwords or is it just settings related?
@hrfee i removed all the files in %appdata%/jfa-go and then reran it from nssm and i still get the same error? i think its safe to say this is luckily not a db error, any idea of what else might be causing this any other kinds of caches or dbs i can wipe?
fixed it by making a task scheduler task instead of relying on nssm, nssm is usually great but seems super flimsy for jfa for some reason!
ah ok great, happy you didn't lose everything then. I've never used nssm myself but had to help someone with it back when jfa-go was jellyfin-accounts, and it was a nightmare.