Re: [Help-gnunet] Major ouches

[Tom Barnes-Lawrence]

On Wed, May 07, 2003 at 12:25:53PM -0500, Christian Grothoff wrote:
> >  Well, it doesn't seem to get this far under gdb: after the run
> > command, it says (again) something about unknown signals, spawns
> > 2 threads, and then is very very quiet. No network activity, and
> > gnunet-stats cant connect. The processes still seem to be there,
> > and gdb doesn't say anything more.
> >
> >  Did I have to pass some configure option for debugging symbols?
> > The only time I've really used gdb was with my own (recent) program,
> > that just used a Makefile (without autoconf).
> 
> Did you run it with "run -d" (the -d is kind of important). In order to get 
   Yup.

> full debuging information, run "export CLAGS="-g" *before* ./configure; then 
> recompile (make clean ; make install) and that should be it.
   Instead, I investigated further- sure enough, -g is already
set in the Makefile. I presume you must have set it as default.

  It occurred to me that the stuff about unknown signals was likely
to do with gnunet's use of threads, and that maybe my copy of gdb wasn't
dealing with that properly. I checked, and I'm using gdb 4.17 but
Debian currently has 5.2...
... Installed it. Yup, now *that* works. No complaints about signals,
6 or 7 threads, various debug messages...
...And now the segfault, and "ba" produces:

#0  0xbf3ff808 in ?? ()
#1  0x40377829 in lowCountContentEntries (handle=0x805dd00) at low_bdb.c:320
#2  0x403779c8 in lowWriteContent (handle=0x805dd00, name=0xbf3ff8b0, 
    len=1056, block=0x81084f0) at low_bdb.c:409
#3  0x403760aa in writeContent (handle=0x805ce20, ce=0xbf3ff990, len=1024, 
    block=0x8102f6c) at high_simple.c:462
#4  0x4026d74f in insertContent (ce=0xbf3ff990, len=1024, data=0x8102f6c, 
    sender=0x805b13c, duplicate=0xbf3ff98c) at manager.c:689
#5  0x4025ef7d in handleCHK_CONTENT (sender=0x805b13c, msg=0x8102f68)
    at handler.c:189
#6  0x0804d77b in handleHelper (msg=0x8102f60 "", sender=0x805b13c,
size=1452, 
    crc=-1691907674) at handler.c:147
#7  0x0804d954 in handleMessage (tsession=0x40516618, sender=0x805b13c, 
    msg=0x8104098, size=1452, isEncrypted=1, crc=-1691907674) at
handler.c:256
#8  0x0804ce3e in threadMain (id=-1073744424) at core.c:130
#9  0x401310ba in pthread_start_thread () from /lib/libpthread.so.0
#10 0x40131101 in pthread_start_thread_event () from /lib/libpthread.so.0

 I trust you can do something with that ;)
NB- I'll try this a few more times tonight to see if I get anything
different to that.



> > > > So, is nobody else getting this level of flakiness?
> 
> I don't know of anyone. If you have some old gnunet.conf file lying around, 
> that may cause some unknown trouble (which we should fix), but I doubt that 
> that's the cause.
  As usual, I copied and adapted the bundled gnunet.conf to ~/.gnunet/ ,
and renamed the previous versions. I did worry about setting DATABASETYPE
to "bdb" as the help text didn't say what to set.

> The most likely thing I can come up with is that you have 
> some old GNUnet libraries installed somewhere and that these are loaded by 
> chance instead of the correct (0.5.3-compatible) ones. That would explain the 
> crashing.  "locate libgnunet" and remove whatever files you find and then 
> re-install, see if that helps. Oh, and the library-version conflict may also 
> be quite confusing for gdb if it happens.
  I'd already checked ls -t /usr/local/lib/libgnunet*,
the only thing that wasn't brand new was libgnunetfilesharing.a,
which I presume isn't used at all now.

  The thing is tho, that most of these potential causes I'd expect to have
a pretty instant effect- yet it usually takes a fair few seconds to crash,
and the first night I used it, I did manage to do a few searches (which
stopped silently each time gnunetd died), and then before giving up for
the night, downloaded about half an ogg _without_ gnunetd dying.

  If it's a bug in gnunet, then maybe me being the only one to see it
would mean some sort of freak concurrency issue, like a race condition?
Presumably differences between specific machines would affect the order
in which concurrent tasks execute. But I'm guessing really  :P

Tomble