gdbm fatal: lseek error

[quinox]

i just installed nicotine+ via portage (on gentoo on a 64bit machine), and i always get this error on startup: gdbm fatal: lseek error

then i tried to debug with pdb, which gives me this:

$ python -m pdb =nicotine
> /usr/bin/nicotine(23)<module>()
-> """
(Pdb) break /usr/lib64/python2.6/shelve.py:101
Breakpoint 1 at /usr/lib64/python2.6/shelve.py:101
(Pdb) r
Mon 16:31 Nicotine supports a country code blocker but that requires a (GPL'ed)
          library called GeoIP. You can find it here:  C library:
          http://www.maxmind.com/app/c  Python bindings:
          http://www.maxmind.com/app/python  (the python bindings require the C
          library)
> /usr/lib64/python2.6/shelve.py(101)keys()
-> return self.dict.keys()
(Pdb) bt
  /usr/lib64/python2.6/bdb.py(368)run()
-> exec cmd in globals, locals
  <string>(1)<module>()
  /usr/bin/nicotine(275)<module>()
-> run()
  /usr/bin/nicotine(261)run()
-> app = frame.MainApp(config, plugins, trayicon, tryrgba, hidden, webbrowser)
  /usr/lib64/python2.6/site-packages/pynicotine/gtkgui/frame.py(3607)__init__()
-> self.frame = NicotineFrame(config, plugindir, trayicon, rgbamode, start_hidden, WebBrowser)
  /usr/lib64/python2.6/site-packages/pynicotine/gtkgui/frame.py(329)__init__()
-> self.np = NetworkEventProcessor(self, self.callback, self.logMessage, self.SetStatusText, config)
  /usr/lib64/python2.6/site-packages/pynicotine/pynicotine.py(118)__init__()
-> self.shares = Shares(self)
  /usr/lib64/python2.6/site-packages/pynicotine/shares.py(29)__init__()
-> self.CompressShares("normal")
  /usr/lib64/python2.6/site-packages/pynicotine/shares.py(84)CompressShares()
-> m.makeNetworkMessage(nozlib=0, rebuild=True)
  /usr/lib64/python2.6/site-packages/pynicotine/slskmessages.py(1664)makeNetworkMessage()
-> msg = msg + self.packObject(len(self.list.keys()))
> /usr/lib64/python2.6/shelve.py(101)keys()
-> return self.dict.keys()
(Pdb) s
gdbm fatal: lseek error

[quinox]

From what I understand gdbm is some low-level library for managing the mapping of an hashmap (or associative array). We do not import dbm/gdbm so it's probably python itself that decided to use it. Your debug output seems to support this theory, it shows that python crashes at /usr/lib64/python2.6/shelve.py

Therefore there's little we can do about it on the nicotine+ side.

To solve your problem:

Have you compiled sys-libs/gdbm with some aggressive flags? I have a Gentoo 64-bit system too and don't see this happening with 1.8.3-r4(-berkdb). My settings:

CFLAGS="-march=athlon64 -O2 -pipe -msse3"
CXXFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
ACCEPT_KEYWORDS="~amd64"

• or -

Is something else broken? Perhaps see what revdep-rebuild reports.

[anonymous]

revdep-rebuild only find some broken stuff for net-libs/webkit-gtk, but i guess that has nothing to do with nicotine.

my make.conf settings (i think they should be fine though):

CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=native -mtune=native -O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"

ACCEPT_KEYWORDS="amd64 ~amd64"
[...]

i also tried to emerge gdbm with CFLAGS="", which gives the same error.

what else could i try?

[quinox]

yes, -O2 should be good.

Based on  this post it might be python itself. if python --version reports 2.6 try running nicotine with /usr/bin/python2.5 or vice-versa and see what happens.

Other options:

• Following  this, try strace -fF /usr/bin/python nicotine and see if it shows any open()s just before the crash that could be the issue
• Recompile the active python version and see if that helps.

[anonymous]

strace gives me this: paste.pocoo.org/show/194430/ last lines:

stat("/home/totycro/.nicotine/config.buddymtimes.db", {st_mode=S_IFREG|0644, st_size=12288, ...}) = 0
open("/home/totycro/.nicotine/config.buddymtimes.db", O_RDWR) = 15
fcntl(15, F_GETFD)                      = 0
fcntl(15, F_SETFD, FD_CLOEXEC)          = 0
read(15, "\0\0\0\0\1\0\0\0\0\0\0\0a\25\6\0\t\0\0\0\0\20\0\0\0\10\0\0\0\0\0\0"..., 512) = 512
close(15)                               = 0
open("/home/totycro/.nicotine/config.buddymtimes.db", O_RDWR|O_CREAT, 0) = 15
fcntl(15, F_GETFD)                      = 0
fcntl(15, F_SETFD, FD_CLOEXEC)          = 0
fstat(15, {st_mode=S_IFREG|0644, st_size=12288, ...}) = 0
pread(15, "\0\0\0\0\1\0\0\0\0\0\0\0a\25\6\0\t\0\0\0\0\20\0\0\0\10\0\0\0\0\0\0"..., 4096, 0) = 4096
brk(0x30d1000)                          = 0x30d1000
brk(0x30f2000)                          = 0x30f2000
brk(0x3113000)                          = 0x3113000
brk(0x3134000)                          = 0x3134000
lseek(8, 8192, SEEK_SET)                = 8192
read(8, "\1\0\0\0\0\20\0\0\0000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\21\0\0\0\0x=\264"..., 4096) = 4096
lseek(8, 13246639292477032032, SEEK_SET) = -1 EINVAL (Invalid argument)
write(2, "gdbm fatal: ", 12gdbm fatal: )            = 12
write(2, "lseek error", 11lseek error)             = 11
write(2, "\n", 1
)                       = 1
exit_group(1)                           = ?

Recompiling python didn't help.

I'm using 2.6.5, using 2.5.4, it complained about all the libs, that are only installed here in /usr/lib/python2.6/site-packages (gtk, pygtk, cairo..). I just copied the required ones to the corresponding dir for 2.5, which results in the same gdbm error.

I looked at your links, but i couldn't really find sth, that i could use in this case..

[anonymous]

Oh yeah I forgot PyGTK doesn't do work like that, sorry. Most modules install themselves for all available python versions, PyGTK being the exception. So using a diff. python version is no option.

Your trace shows the N+ storage was last opened before the crash, it might be related: It's a database so it's quite possible GDBM is involved. These files contain cached information, used by N+ to remember things it has seen/calculated previously.

Perhaps these files got corrupted in a way python doesn't expect, thus crashing it. I don't know how this could have happened with a brand new installation, but computers are weird so who knows.

If that is the situation you can fix it by deleting those files (or moving them to some other folder). This should have no side effects apart from N+ having to rehash your music collection.

(Yes, these are all hunches and guesses: anything other than python backtraces fall outside our scope)

[anonymous]

And with those files I mean the files having the .db extension located in the folder ~/.nicotine/

[anonymous]

Thank you very much! Removing .nicotine worked, it seems that some file really got corrupted.

[quinox]

Excellent