Menu
▾
▴
gtk-gnutella-devel
|
From: clayton r. <cro...@ho...> - 2003-06-23 01:12:25
|
Christian Biere <chr...@gm...> wrote:
>
>"clayton rollins" <cro...@ho...> wrote:
>
> > gtk-gnutella in free(): warning: chunk is already free
> > gtk-gnutella in free(): warning: chunk is already free
> > gtk-gnutella in free(): warning: chunk is already free
> > gtk-gnutella in free(): warning: junk pointer, too high to make sense
> > Segmentation fault (core dumped)
>
>If you can reproduce that, could you try to run gtk-gnutella with
>MALLOC_OPTIONS="A"? See malloc(3) for details. This should show
>which call to free() produces the warnings above.
>
Done. I'm not really sure what you want from it, though. It now does:
gtk-gnutella in free(): error: chunk is already free
Abort (core dumped)
(just a single time.)
The bt from uploads_gui_update_display() to the kill is:
#0 0x28a11c84 in kill () from /usr/lib/libc.so.4
No symbol table info available.
#1 0x28a53212 in abort () from /usr/lib/libc.so.4
No symbol table info available.
#2 0x28a51cfd in isatty () from /usr/lib/libc.so.4
No symbol table info available.
#3 0x28a51d33 in isatty () from /usr/lib/libc.so.4
No symbol table info available.
#4 0x28a52c2a in isatty () from /usr/lib/libc.so.4
No symbol table info available.
#5 0x28a52e91 in free () from /usr/lib/libc.so.4
No symbol table info available.
#6 0x2876b9e9 in g_free (mem=0x8948da0) at gmem.c:186
No locals.
#7 0x80c1cdf in uploads_gui_update_display (now=1056344143) at
uploads_gui2.c:441
data = (upload_row_data_t *) 0x8948da0
last_update = 1056344143
model = (GtkTreeModel *) 0x878db80
iter = {stamp = -1025953160, user_data = 0x8ad1de8, user_data2 =
0x0,
user_data3 = 0x0}
status = {status = GTA_UL_QUEUED, pos = 0, bps = 1, avg_bps = 1,
last_update = 1056344442, parq_position = 8, parq_size = 54, parq_lifetime
= 343,
parq_retry = 253, parq_queue_no = 4}
all_removed = 0
valid = 0
to_remove = (GSList *) 0x88af588
(I'll recompile libc with debugging, if you think it's necessary.)
Clayton
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
|
|
From: clayton r. <cro...@ho...> - 2003-06-23 03:34:04
|
Christian Biere <chr...@gm...> wrote: > >Mmhmhmhm, I've just compiled GTKG with gcc 2.95.3 and a few minutes >later it crashed... If you have gcc 3.3 around could you try to >compile with it instead? > I'll see what I can do. (I don't have anything newer than 2.95.4, currently.) BTW, applying your previous patch didn't fix the problem. -Clayton _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail |
|
From: Christian B. <chr...@gm...> - 2003-06-24 04:21:22
|
"clayton rollins" <cro...@ho...> wrote: > I'll see what I can do. (I don't have anything newer than 2.95.4, > currently.) BTW, applying your previous patch didn't fix the problem. OK, all engines reverse. That was just (bad) luck. Sometimes GTKG runs for days without problems and other times it crashes due to this bug within seconds. It's either a bug in GTK+ or a lack of documentation. I've found that it's possible that a list store contains the same row twice. This is likely to be caused by gtk_list_store_set() because if the GtkTreeView is sorted by the status column and the status string is changed, the order has to be corrected. I've fixed this by a workaround. The patch is attached in case the public CVS repository is still heavily out-of-sync. You better don't tell me, this didn't fix it! -- Christian |
|
From: Christian B. <chr...@gm...> - 2003-06-24 04:25:54
Attachments:
uploads_gui2.c.udif
|
Christian Biere <chr...@gm...> wrote: > I've fixed this by a workaround. The patch is attached in case the > public CVS repository is still heavily out-of-sync. Didn't I write it's attached? -- Christian |
|
From: clayton r. <cro...@ho...> - 2003-06-25 16:59:05
|
Christian Biere <chr...@gm...> wrote: > >I've fixed this by a workaround. The patch is attached in case the >public CVS repository is still heavily out-of-sync. > Sorry, I hadn't been paying attention to this account; it's a bit trickier than I assumed to set up a second compiler. I have a really nice pushed source right now, otherwise I'd test the patch now. I'll let you know if I have any further problems. Thanks, Clayton _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail |
|
From: clayton r. <cro...@ho...> - 2003-06-25 19:34:03
|
"clayton rollins" <cro...@ho...> wrote: > >Christian Biere <chr...@gm...> wrote: >> >>I've fixed this by a workaround. The patch is attached in case the >>public CVS repository is still heavily out-of-sync. >> > >Sorry, I hadn't been paying attention to this account; it's a bit trickier >than I assumed to set up a second compiler. I have a really nice pushed >source right now, otherwise I'd test the patch now. I'll let you know if I >have any further problems. > I've been running stable for a while now with your patch; it appears to be fixed. (It usually took <5 minutes to crash before.) Thanks again, Clayton _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail |
|
From: Christian B. <chr...@gm...> - 2003-06-23 02:28:21
Attachments:
uploads_gui2.c.udif
|
"clayton rollins" <cro...@ho...> wrote: > #6 0x2876b9e9 in g_free (mem=0x8948da0) at gmem.c:186 > No locals. > #7 0x80c1cdf in uploads_gui_update_display (now=1056344143) at > uploads_gui2.c:441 > data = (upload_row_data_t *) 0x8948da0 The only explanation I can think of is that somehow the same row gets removed twice from the model i.e., removing the row failed before. Alternatively, data might not be nullified but if my eyes ain't broken data is always set to NULL, isn't it? > (I'll recompile libc with debugging, if you think it's necessary.) That wouldn't help here. Please, try the attached patch. data->status might not be initialized at the beginning although I don't think this fixes the bug. Thanks, -- Christian |
|
From: Christian B. <chr...@gm...> - 2003-06-23 03:12:07
|
Christian Biere <chr...@gm...> wrote: > The only explanation I can think of is that somehow the same row > gets removed twice from the model i.e., removing the row failed > before. Alternatively, data might not be nullified but if my eyes > ain't broken data is always set to NULL, isn't it? Mmhmhmhm, I've just compiled GTKG with gcc 2.95.3 and a few minutes later it crashed... If you have gcc 3.3 around could you try to compile with it instead? -- Christian |
|
From: Mihai T. L. <mi...@em...> - 2003-06-23 12:49:49
|
Hello,
Here is the error I get while GTKG checks the SHA1 (at about
2-3% completion):
** ERROR **: file downloads.c: line 6381 (download_verify_progress): assertion failed: (d->status == GTA_DL_VERIFYING)
aborting...
search_init
I use the latest CVS on RedHat 9, compiled with gcc
3.2.2. Please let me know if I can help more.
Mihai
|
|
From: <Rap...@po...> - 2003-06-23 22:39:40
|
Quoting "Mihai T. Lazarescu" <mi...@em...> from ml.softs.gtk-gnutella.devel: :assertion failed: (d->status == GTA_DL_VERIFYING) : aborting... : :I use the latest CVS on RedHat 9, compiled with gcc :3.2.2. Please let me know if I can help more. The stack trace would help tremendously see a common pattern between all those bugs... Raphael |
|
From: Mihai T. L. <mi...@em...> - 2003-06-23 22:56:12
|
How can I get a stack trace in case of an assertion failure? There is no core left. Perhaps replacing the exit of the assert with an instructions that does generate a core dump (like trying to write something to an illegal address)? I can add that it seems a kind of random. It does not happen at the same point in the checksum after GTKG restart and other checksums may be completed without a flaw. Looks like a memory corruption/lack of initialization?... Let me know how to proceed. Thanks for the help. Mihai On 23 Jun 2003, Raphael Manfredi wrote: > Quoting "Mihai T. Lazarescu" <mi...@em...> from ml.softs.gtk-gnutella.devel: > :assertion failed: (d->status == GTA_DL_VERIFYING) > : aborting... > : > :I use the latest CVS on RedHat 9, compiled with gcc > :3.2.2. Please let me know if I can help more. > > The stack trace would help tremendously see a common pattern between all > those bugs... > > Raphael |
|
From: V A. B. <va...@cr...> - 2003-06-24 00:29:13
|
You can run gtk-gnutella in gdb. Recompile it with debugging symbols if necessary. Grep in the source code for the assert that is failing, then set a breakpoint just before or at that line. Then in gdb, execute the 'bt' (backtrace) command in the instance of a condition that will yield an assert failure. You can tell if there will be an assert failure by using the 'print' command in gdb to display the values of the different variables. If it is memory corruption of the stack, you should be able to see that in the debugger's stack trace (backtrace). You can analyze the frames to find the exact point of the corruption. If it is an uninit'd variable, you should be able to determine that from the print command in the debugger. - VAB On Tue, 24 Jun 2003, Mihai T. Lazarescu wrote: > How can I get a stack trace in case of an assertion failure? > There is no core left. Perhaps replacing the exit of the > assert with an instructions that does generate a core dump > (like trying to write something to an illegal address)? > > I can add that it seems a kind of random. It does not happen > at the same point in the checksum after GTKG restart and other > checksums may be completed without a flaw. Looks like a memory > corruption/lack of initialization?... > > Let me know how to proceed. Thanks for the help. > > Mihai > > On 23 Jun 2003, Raphael Manfredi wrote: > > > Quoting "Mihai T. Lazarescu" <mi...@em...> from ml.softs.gtk-gnutella.devel: > > :assertion failed: (d->status == GTA_DL_VERIFYING) > > : aborting... > > : > > :I use the latest CVS on RedHat 9, compiled with gcc > > :3.2.2. Please let me know if I can help more. > > > > The stack trace would help tremendously see a common pattern between all > > those bugs... > > > > Raphael > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Gtk-gnutella-devel mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel > |
|
From: Mihai T. L. <mi...@em...> - 2003-06-24 00:38:32
|
Thanks, I'll do that next time the error occurs. Mihai On Mon, 23 Jun 2003, V Alex Brennen wrote: > > You can run gtk-gnutella in gdb. Recompile it with > debugging symbols if necessary. Grep in the source > code for the assert that is failing, then set a > breakpoint just before or at that line. Then > in gdb, execute the 'bt' (backtrace) command > in the instance of a condition that will yield > an assert failure. > > You can tell if there will be an assert failure > by using the 'print' command in gdb to display > the values of the different variables. > > If it is memory corruption of the stack, you > should be able to see that in the debugger's > stack trace (backtrace). You can analyze > the frames to find the exact point of the > corruption. If it is an uninit'd variable, > you should be able to determine that from > the print command in the debugger. > > > - VAB > > On Tue, 24 Jun 2003, Mihai T. Lazarescu wrote: > > > How can I get a stack trace in case of an assertion failure? > > There is no core left. Perhaps replacing the exit of the > > assert with an instructions that does generate a core dump > > (like trying to write something to an illegal address)? > > > > I can add that it seems a kind of random. It does not happen > > at the same point in the checksum after GTKG restart and other > > checksums may be completed without a flaw. Looks like a memory > > corruption/lack of initialization?... > > > > Let me know how to proceed. Thanks for the help. > > > > Mihai > > > > On 23 Jun 2003, Raphael Manfredi wrote: > > > > > Quoting "Mihai T. Lazarescu" <mi...@em...> from ml.softs.gtk-gnutella.devel: > > > :assertion failed: (d->status == GTA_DL_VERIFYING) > > > : aborting... > > > : > > > :I use the latest CVS on RedHat 9, compiled with gcc > > > :3.2.2. Please let me know if I can help more. > > > > > > The stack trace would help tremendously see a common pattern between all > > > those bugs... > > > > > > Raphael > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: INetU > > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > > _______________________________________________ > > Gtk-gnutella-devel mailing list > > Gtk...@li... > > https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel > > > |
|
From: Christian B. <chr...@gm...> - 2003-06-24 00:36:22
|
"Mihai T. Lazarescu" <mi...@em...> wrote: > How can I get a stack trace in case of an assertion failure? > There is no core left. ulimit -c unlimited -- Christian |
|
From: Mihai T. L. <mi...@em...> - 2003-06-24 01:03:55
|
It's not a matter of settings. assert calls abort(), whose behavior is just exit and not generate a core dump. Mihai On Tue, 24 Jun 2003, Christian Biere wrote: > "Mihai T. Lazarescu" <mi...@em...> wrote: > > > How can I get a stack trace in case of an assertion failure? > > There is no core left. > > ulimit -c unlimited > > -- > Christian > |
|
From: Christian B. <chr...@gm...> - 2003-06-24 01:16:12
|
"Mihai T. Lazarescu" <mi...@em...> wrote:
> It's not a matter of settings. assert calls abort(), whose
> behavior is just exit and not generate a core dump.
What operating system do you use? My man pages claim the following:
Name Default Action Description
SIGHUP terminate process terminal line hangup
SIGINT terminate process interrupt program
SIGQUIT create core image quit program
SIGILL create core image illegal instruction
SIGTRAP create core image trace trap
SIGABRT create core image abort(3) call (formerly SIGIOT)
--
Christian
|
|
From: Mirar <mir...@mi...> - 2003-06-24 06:29:20
|
"Mihai T. Lazarescu" <mi...@em...> writes: > It's not a matter of settings. assert calls abort(), whose > behavior is just exit and not generate a core dump. You're thinking about _exit(). abort() is generally for dumping a core, if it's allowed. Core size set with ulimit/limit/setrlimit/sysconf. /Mirar |
|
From: Mihai T. L. <mi...@em...> - 2003-06-24 09:33:16
|
Confirm. Sorry for the mislead. Mihai On 24 Jun 2003, Mirar wrote: > "Mihai T. Lazarescu" <mi...@em...> writes: > > > It's not a matter of settings. assert calls abort(), whose > > behavior is just exit and not generate a core dump. > > You're thinking about _exit(). abort() is generally for dumping a > core, if it's allowed. > Core size set with ulimit/limit/setrlimit/sysconf. > > /Mirar > |
|
From: <Rap...@po...> - 2003-06-24 06:18:26
|
Quoting gtk...@li... from ml.softs.gtk-gnutella.devel: :-=-=-=-=-=- : :"Mihai T. Lazarescu" <mi...@em...> wrote: : :> How can I get a stack trace in case of an assertion failure? :> There is no core left. : :ulimit -c unlimited Or try also this: ulimit -S -c unlimited BEFORE launching gtk-gnutella, of course, and in the same shell used to launch it! Raphael |
|
From: Mihai T. L. <mi...@em...> - 2003-06-25 22:11:59
|
I got a stack trace (attached) for the crash, that happens
while computing SHA1 after download completion.
I also noticed that the corresponding line in the download
panel changes from 'Computing SHA1' to 'Waiting for SHA1'
or something like this just before the abort.
I don't know if this is already fixed in the CVS. I keep
getting the version of 15/6 (is this frozen on the server or
is my cvs configuration broken?)
Mihai
(gdb) bt full
#0 0xffffe002 in ?? ()
No symbol table info available.
#1 0x42028b93 in abort () from /lib/tls/libc.so.6
No symbol table info available.
#2 0x401be421 in g_logv () from /usr/lib/libglib-1.2.so.0
No symbol table info available.
#3 0x401be464 in g_log () from /usr/lib/libglib-1.2.so.0
No symbol table info available.
#4 0x081094c8 in download_verify_progress (d=0x9160d50, hashed=19050496)
at downloads.c:6381
No locals.
#5 0x08142855 in d_step_compute (h=0x83e0670, u=0x84135d8, ticks=64)
at verify.c:242
vd = (struct verifyd *) 0x84135d8
r = 65536
amount = 65536
res = 0
remain = 65536
used = 16
#6 0x08141f47 in bg_sched_timer () at bg.c:987
bt = (struct bgtask *) 0x83e0670
remain = 150000
target = 75000
ticks = 64
ret = 3221222696
#7 0x081194d5 in main_timer (p=0x0) at main.c:280
now = 1056578401
#8 0x401bc9a5 in g_timeout_dispatch () from /usr/lib/libglib-1.2.so.0
No symbol table info available.
#9 0x401bb97e in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
No symbol table info available.
#10 0x401bbe59 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
No symbol table info available.
#11 0x401bc0f4 in g_main_run () from /usr/lib/libglib-1.2.so.0
No symbol table info available.
#12 0x400c527f in gtk_main () from /usr/lib/libgtk-1.2.so.0
No symbol table info available.
#13 0x080d5676 in main_gui_run () at main_gui.c:650
coord = {0, 1, 1022, 764}
#14 0x081198f6 in main (argc=1, argv=0xbffff6e4, env=0xbffff6ec) at main.c:463
i = 256
#15 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
No symbol table info available.
On Mon, 23 Jun 2003, Mihai T. Lazarescu wrote:
> Hello,
>
> Here is the error I get while GTKG checks the SHA1 (at about
> 2-3% completion):
>
> ** ERROR **: file downloads.c: line 6381 (download_verify_progress): assertion failed: (d->status == GTA_DL_VERIFYING)
> aborting...
> search_init
>
> I use the latest CVS on RedHat 9, compiled with gcc
> 3.2.2. Please let me know if I can help more.
>
> Mihai
|
|
From: <Rap...@po...> - 2003-06-26 05:53:57
|
Quoting "Mihai T. Lazarescu" <mi...@em...> from ml.softs.gtk-gnutella.devel: :I don't know if this is already fixed in the CVS. I keep :getting the version of 15/6 (is this frozen on the server or :is my cvs configuration broken?) Sourceforge is having a delayed anonymous CVS server, but the lag should only be ~24 hours. If your CVS is frozen to a particular date, maybe you used "-D" in the past. In that case, use "-D ''" to remove the date freeze. Raphael |
|
From: Christian B. <chr...@gm...> - 2003-06-26 11:25:28
|
Rap...@po... (Raphael Manfredi) wrote: > Sourceforge is having a delayed anonymous CVS server, but the lag > should only be ~24 hours. Nope, anonymous CVS hasn't been updated for about 10 days. Unfortunately, this also concerns the nightly CVS tarballs. -- Christian |
|
From: <Rap...@po...> - 2003-06-26 18:43:35
|
:Rap...@po... (Raphael Manfredi) wrote: :> Sourceforge is having a delayed anonymous CVS server, but the lag :> should only be ~24 hours. : :Nope, anonymous CVS hasn't been updated for about 10 days. Unfortunately, :this also concerns the nightly CVS tarballs. Jeroen has setup a server that copies the developer's CVS tree. Do you wish to make that address public, Jeroen? Raphael |
|
From: Jeroen A. <je...@as...> - 2003-06-26 21:37:04
|
Op do 26-06-2003, om 20:43 schreef Raphael Manfredi: > Jeroen has setup a server that copies the developer's CVS tree. Do > you wish to make that address public, Jeroen? Sure,=20 http://gtk-gnutella.asselman.com but don't complain if it aint that fast. I am only on a cable modem. --=20 Jeroen Asselman <je...@as...> |
|
From: Martin P. <ma...@li...> - 2003-06-26 21:22:50
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Thursday 26 June 2003 20:43, Raphael Manfredi wrote: > :Rap...@po... (Raphael Manfredi) wrote: > :> Sourceforge is having a delayed anonymous CVS server, but the lag > :> should only be ~24 hours. > : > :Nope, anonymous CVS hasn't been updated for about 10 days. Unfortunately, > :this also concerns the nightly CVS tarballs. > > Jeroen has setup a server that copies the developer's CVS tree. Do > you wish to make that address public, Jeroen? Or could you please publish a diff between the current cvs (which should be= =20 available at least for developers, like it is the case with my projects) an= d=20 the last publicly available version ? It's just because I have the same assertion here, and as long as I cannot=20 finish the file causing this I'm unable to continue running gtkg... That would be great... regards Martin =2D --=20 LibChipcard - http://www.libchipcard.de =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE++2UYiVxhnDyjV4MRArvSAJ4+8+MrzM3ZX1IMgabA3VmV3JkgZwCdHu96 =46ce9RX3HZz4d7GjfnMFtrKg=3D =3DjiRO =2D----END PGP SIGNATURE----- |
Thanks for helping keep SourceForge clean.
X