gnunet-developers
[Top][All Lists]
Advanced

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

[GNUnet-developers] gnunet-gtk crashes (was Re: [Help-gnunet] Questions


From: Tom Barnes-Lawrence
Subject: [GNUnet-developers] gnunet-gtk crashes (was Re: [Help-gnunet] Questions on latest version)
Date: Wed, 10 Dec 2003 05:15:40 +0000
User-agent: Mutt/1.3.28i

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, 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).
Finally, gnunet-gtk died and I got:

valgrind: vg_scheduler.c:3570 (scheduler_sanity): Assertion 
x->__m_count >
0' failed.

sched status:

Thread 1: status = WaitMX, associated_mx = 0x41814004, associated_cv = 0x0
==1219==    at 0x4052CB0A: __pthread_mutex_lock (vg_libpthread.c:950)
==1219==    by 0x4037B42D: (within /usr/lib/libgdk-1.2.so.0.9.1)
==1219==    by 0x4049E4D7: (within /usr/lib/libglib-1.2.so.0.0.10)
==1219==    by 0x4049EAE2: (within /usr/lib/libglib-1.2.so.0.0.10)

Thread 2: status = Sleeping, associated_mx = 0x0, associated_cv = 0x0
==1219==    at 0x405E9DE1: __libc_nanosleep (in /lib/libc-2.2.5.so)
==1219==    by 0x404D109C: gnunet_util_sleep (timer.c:89)
==1219==    by 0x404C865D: cron (cron.c:524)
==1219==    by 0x4052C4EB: thread_wrapper (vg_libpthread.c:667)

Thread 3: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==1219==    at 0x40185DAD: vgAllRoadsLeadToRome_poll (vg_intercept.c:98)
==1219==    by 0x40185E7C: __poll (vg_intercept.c:386)
==1219==    by 0x40186BFD:
vgAllRoadsLeadToRome_wait_for_fd_to_be_readable_or_erring
(vg_intercept.c:925)
==1219==    by 0x4018619C: vgAllRoadsLeadToRome_recv (vg_intercept.c:519)

Thread 4: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==1219==    at 0x4002049C: memcpy (in
/usr/local/lib/valgrind/vgskin_memcheck.so)
==1219==    by 0x404CAF4C: decryptBlock (symcipher_gcry.c:96)
==1219==    by 0x404B67E7: decryptContent (contentencoding.c:91)
==1219==    by 0x404BB1BD: receiveResults (searchutil.c:258)

Thread 5: status = WaitCV, associated_mx = 0x41861AAC, associated_cv =
0x41861AC4
==1219==    at 0x4052CDB9: pthread_cond_wait (vg_libpthread.c:1095)
==1219==    by 0x404CD0EF: semaphore_down_ (semaphore.c:238)
==1219==    by 0x804F046: downloadFile_ (download.c:288)
==1219==    by 0x4052C4EB: thread_wrapper (vg_libpthread.c:667)

Thread 6: status = Sleeping, associated_mx = 0x0, associated_cv = 0x0
==1219==    at 0x40185DAD: vgAllRoadsLeadToRome_poll (vg_intercept.c:98)
==1219==    by 0x40185E7C: __poll (vg_intercept.c:386)
==1219==    by 0x40186BFD:
vgAllRoadsLeadToRome_wait_for_fd_to_be_readable_or_erring
(vg_intercept.c:925)
==1219==    by 0x4018619C: vgAllRoadsLeadToRome_recv (vg_intercept.c:519)

Thread 7: status = WaitCV, associated_mx = 0x41837C14, associated_cv =
0x41837C2C
==1219==    at 0x4052CDB9: pthread_cond_wait (vg_libpthread.c:1095)
==1219==    by 0x404CD0EF: semaphore_down_ (semaphore.c:238)
==1219==    by 0x804F046: downloadFile_ (download.c:288)
==1219==    by 0x4052C4EB: thread_wrapper (vg_libpthread.c:667)

Thread 8: status = Sleeping, associated_mx = 0x0, associated_cv = 0x0
==1219==    at 0x40185DAD: vgAllRoadsLeadToRome_poll (vg_intercept.c:98)
==1219==    by 0x40185E7C: __poll (vg_intercept.c:386)
==1219==    by 0x40186BFD:
vgAllRoadsLeadToRome_wait_for_fd_to_be_readable_or_erring
(vg_intercept.c:925)
==1219==    by 0x4018619C: vgAllRoadsLeadToRome_recv (vg_intercept.c:519)


Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.

If that doesn't help, please report this bug to: address@hidden

In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using.  Thanks.


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

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

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

 Tom




reply via email to

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