Re: [GNUnet-developers] gnunet-gtk crashes

[Tom Barnes-Lawrence]

On Thu, Dec 11, 2003 at 06:16:35PM -0500, Christian Grothoff wrote:
> Let me start with some important hint with respect to gdb.  The latest gdb 
> (6.0) reliably produces broken stacktraces for me.  Switching to an earlier 
> version (5.x) solved the problem.  So if your stacktrace contains a ton of 
> "??" lines, I recommend trying with another gdb version.

Hmm, well I used to have troubles using GDB with gnunet-gtk (and
some other programs, possibly gnunetd). IIRC it was to do with threads.
Then I upgraded a couple of months back, and it was much better.
But the version I upgraded to (being on Debian/Stable) was 5.2.cvs,
not 6.anything. I don't really remember other programs getting
these ??s anywhere.

I'm not discounting the idea, I just don't want to play "blindly hunt
the version of GDB that gets it right", if you see what I mean.

> On Wednesday 10 December 2003 12:15 am, Tom Barnes-Lawrence wrote:
> >
> >  Right, well after to-ing and fro-ing across the country a fair bit, and
> > trying to get together some more content for GNUnet, I've finally gotten
> > around to trying just that. I think I'd heard of Valgrind before, but
> > never actually tried it. NB- I'm still running V0.6.0a rather than CVS.
> 
> Well, there are fixes for various minor and some major bugs in CVS.

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?

For that matter, any chance of a new release version some time soon, or
is that not on the cards?


> I've seen this one before.  It is a possibly well-known but harmless problem 
> in some versions of glibc.  glibc has tons of these but most are suppressed 
> by valgrinds configuration (the default tries to not show glibc problems to 
> avoid cluttering the screen; this one somehow is (was?) not included in that 
> list).  So no worries here.

OK, I'll have to take your word for that...

THOUGHT: I'm using Glibc 2.2.5;
Is ANYBODY else using that version, and if so, are they getting these
address@hidden segfaults in gnunet-gtk or not?

(WAVES TO ANYONE ELSE ON THE LIST WHO MIGHT BE READING)

> > But it sort of sounds to me like it's saying that *valgrind* crashed here.
> > Still, is ANY of that any use? If not, I'm willing to try other stuff.
> 
> No, it is a genuine valgrind crash and the output is valgrind specific.  It 
> is 
> actually likely that there is no problem in gnunet-gtk at this point.  

Hmm, not sure if by "at this point" you mean at the point in testing
where Valgrind crashed, or at this version of Gnunet. Because gnunet-gtk
certainly *does* crash for me, and if it's not in the gnunet code, I'd
be interested to know where the problem actually is. All suggestions
are welcome, however far fetched, because I'm running out of ideas.

(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)

> >  For that matter, I saw you recently discussing some issue with gnunet-gtk
> > and/or the way it interacts with gnunetd. Don't know if there is any
> > correlation with that issue and mine.
> 
> No, were were mostly hunting deadlocks, not segfaults :-).

Yeah, I remember now. I'd just wondered if there'd been some root
cause for both issues or something *shrug*.

> Well, the source could certainly be changed, but the real issue is that it 
> would be hard to make most of the dialogs and menus work (and look) decent at 
> that size.  Considering GNUnet's CPU and memory requirements, I think a 
> resolution of 800x600 is not that unreasonable as a minimal requirement for 
> the GUI.  Of course, I'd be more than happy to see someone else write a 
> better UI any 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.

 Tomble