Re: [GNUnet-developers] gnunet-gtk crashes (was Re: [Help-gnunet] Questions on latest version)

[Christian Grothoff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

On Wednesday 10 December 2003 12:15 am, Tom Barnes-Lawrence wrote:
> Long, long ago, in a galaxy not so far away,
>
> On Wed, Sep 03, 2003 at 01:54:32PM -0500, Christian Grothoff wrote:
> > > Program received signal SIGSEGV, Segmentation fault.
> > > [Switching to Thread 1024 (LWP 799)]
> > > 0x08055d08 in _IO_stdin_used ()
> > > (gdb) ba
> > > #0  0x08055d08 in _IO_stdin_used ()
> > > #1  0x08055d03 in _IO_stdin_used ()
> > > #2  0x00000000 in ?? ()
> > >
> > > after trying to start a download. I forget what caused the segfault a
> > > few days ago, but in the past it's generally been from simply starting
> > > searches. Whether it's been for unusual keywords or common keywords or
> > > second searches or first searches, or what, has *never* been clear to
> > > me.
> >
> > That trace doesn't really say anything (stack trace is garbage).  Could
> > be pthreads (glibc-version?), could be anything.  What platform are you
> > using? If it is Linux/x86, I'd suggest starting gnunet-gtk with valgrind
> > (x86 memory debugger), that may tell us which component is to blame. Yes,
> > it will be slow - -- on a P4 performance is acceptable.  Do other GTK
> > applications run nicely?
>
>  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.

>  Well, as it was running, it said:
> (snip)
> ==1219== Estimated CPU clock rate is 451 MHz
> ==1219== For more details, rerun with: -v
> ==1219==
> ==1219== pthread_mutex_destroy: mutex is still in use
> ==1219==    at 0x4052BDD0: pthread_error (vg_libpthread.c:288)
> ==1219==    by 0x4052CCBF: __pthread_mutex_destroy (vg_libpthread.c:1015)
> ==1219==    by 0x405E61CE: closedir (in /lib/libc-2.2.5.so)
> ==1219==    by 0x404D038E: scanDirectory (storage.c:417)
> ==1219== valgrind's libpthread.so: KLUDGED call to: pthread_cond_destroy
> ==1219== valgrind's libpthread.so: KLUDGED call to: pthread_cond_destroy
> ==1219== valgrind's libpthread.so: KLUDGED call to: pthread_cond_destroy
>
> Which sounds unhealthy, but gnunet-gtk kept running for a few minutes,
> till I wondered if maybe I *hadn't* seen a crash in the latest version
> (I've been seeing the thing crash for as long as I can remember, and if
> you look in the archives, I DID mention it, but nobody seemed interested
> at the time).

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.

> Finally, gnunet-gtk died and I got:
>
> valgrind: vg_scheduler.c:3570 (scheduler_sanity): Assertion
> x->__m_count >
> 0' failed.
> <<<< snip >>>>>>>>>
>
>
> ...
> 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.  

> > > > For me, it has been rock solid for the
> > > > last versions (what GTK version are you using???)
> > >
> > > The debian/stable package of libgtk1.2 (1.2.10-11)
> > > which has the filename of libgtk-1.2.so.0.9.1 (don't ask me how they
> > > come up with the numbers...)
> >
> > Same version that my RH machine presumably uses (1.2-so.0.9.1), which
> > does work.  Puzzling.
>
>  As to your previous questions on how other GTK programs behave, I don't
> remember many of them segfaulting on me. I certainly don't remember
> *any* segfaulting as *quickly* as gnunet-gtk does for me.
>
>  In case you're wondering, yes, perhaps it could be wonky memory, but it
> would seem odd that it doesn't seem to affect other stuff, and I did
> run memcheck86 (or whatever the thing's called) on my system a few years
> back. I've not had a memory upgrade since then.
>
>  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 :-).

>  Before I forget, I'd like to point out that my nice 17" monitor blew up
> over the weekend, so I'm currently stuck with an ancient 14" one at
> 640x480. So gnunet-gtk's refusal to be resized to any less than 780 pixels
> wide is a bit of a PITA to me...

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 :-).

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/2PrU9tNtMeXQLkIRAuWGAJ9TMLAw8tLAkHrsBgXF9TP43pfZLQCgkZ3z
muW05HtRjQkH56XSJr67/W8=
=atQT
-----END PGP SIGNATURE-----