gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] gnunet-gtk crashes


From: Tom Barnes-Lawrence
Subject: Re: [GNUnet-developers] gnunet-gtk crashes
Date: Thu, 18 Dec 2003 04:15:04 +0000
User-agent: Mutt/1.3.28i

On Fri, Dec 12, 2003 at 06:17:43PM -0500, Christian Grothoff wrote:
> > mneh, I suppose that must be true, but I still generally avoid using CVS.
> > Remind me, the current CVS version now uses 2 separate config files, does
> > it have other changes, eg to the directory heirarchy, data formats,etc
> > that I'd need to know about first?
> 
> No, just the configuration.  Everything else should be fine.
> 

Gah, having tried to compile the CVS over the weekend, I found that my
version of libtool was far too old (watching that other thread about
not being able to build the CVS version, I'd been confused by the fact
I hadn't had any problems... but duh I'd not been using CVS :P ). I've
got 1.3.something, whilst it looks like Debian/Stable *had* a
1.4.something available...

...unfortunately Debian's package servers are currently DOWN due to
a recent security breach. Whilst I cheerfully compile various things
from source, I don't fancy doing that for things that other packages
depend on, as I know sod-all about creating my own packages.
 (snip my request for alt package site)

AH! I've just now found one at http://wuarchive.wustl.edu,  so
changing that request:
 -Can I make do with libtool 1.4.2 now, or did the recent investigation
  decide that CVS needs 1.5.x?
 -Does anybody have MD5sums for the official packages of:
  libtool1.4_1.4.3-18_i386.deb   and libtool_1.5-7_i386.deb,
  as I'm feeling paranoid? (If not, don't worry)

> > For that matter, any chance of a new release version some time soon, or
> > is that not on the cards?
> 
> Well, I've got a couple of weird bugs that I would like to fix before the 
> next 
> release (like your gnunet-gtk problem) -- but that depends on what feedback I 
> get in time.  I also want to fix some more bugs from Mantis and extend the 
> testbed functionality, but generally the idea is that there will be another 
> release this year :-).

 Well, looking at the GNUnet webpage, the last release was over 2 months
ago. I've become a bit of a believer in the saying that I think Linus
came up with: "release early and often"- as it keeps users (and authors!)
feeling like the project is progressing, and keeps bugreports current.
Of course, it doesn't always apply- for example, as my cheesy little game
Porrog has been stagnating for a couple of months, there's no point in me
doing another release of that, as there's nothing new!

 But as a project like GNUnet *needs* users, and new bugfixes and
performance improvements seem to be constantly being made, it seems
like a good candidate for this approach. Possibly.


> > (to reassure myself that this was the case, I just ran gnunet-gtk -d
> > without gdb or valgrind, before sending this email. Segfaulted as
> > soon as I tried to enter a search. So there)
> 
> Strange, in particular since there is not really any GNUnet code running at 
> that point (gnunet-gtk sets up the main window, ok, but the event processing 
> and the update of the display with the search-string are entirely GTK-code 
> without a single line of GNUnet code running in the meantime (until you press 
> 'enter' or click somewhere).  So if it crashes while you type the characters, 
> it's certainly not GNUnet.  If it crashes once you press enter, it might be.

 Sorry, I realise I expressed myself a bit badly there:
by "as soon as I tried to enter a search", I strictly meant "immediately
after pressing enter, having typed the keyword". Specifically, the
keyword was one that had previously yielded results with gnunet-search,
so it would already have results in the db.

 In the past (many months back), I tried to figure out exactly what
circumstances these segfaults occurred: often it seemed like it would
be when the first search results came in, other times it seemed like
the number of searches already running within gnunet-gtk made a
difference, etc etc.

 In the end, I realised there didn't seem to be such an easy to spot
pattern to it. Still, I might see if I can get Valgrind to eventually
produce more valuable results than it did the first time.

> > OK, fair enough. I'm mostly just feeling sorry for myself- I'm not likely
> > to be able to afford a new monitor for some time. Perhaps I can figure
> > out where to change my own copy in the meantime.
> 
> src/applications/afs/gtkui/main.c  -- look for '780'.

Cheers for that :)

Tomble




reply via email to

[Prev in Thread] Current Thread [Next in Thread]