Hi Raphael,
On Thursday 28 August 2014 22:01:13 Raphael Manfredi wrote:
> Funny!
> Can you show what "gtk-gnutella --version" reports?
I pulled the latest version from "devel" again, and I still get the
warning. The output of "gtk-gnutella --version" is:
gtk-gnutella/1.1-43-g7412d (2011-09-20;
Quoting Hauke Lathus from ml.softs.gtk-gnutella.devel:
:Yes, it works! But now it keeps telling me that my fresh "devel" build
:is a very ancient version...
Funny!
Can you show what "gtk-gnutella --version" reports?
Raphael
--
Hi Raphael,
On Tuesday 26 August 2014 16:17:36 Raphael Manfredi wrote:
> This is a gcc 4.9 optimizer bug. I have fixed it locally and pushed
> the fix to "devel" already. Can you please confirm it's working now?
Yes, it works! But now it keeps telling me that my fresh "devel" build
is a very a
Quoting Hauke Lathus from ml.softs.gtk-gnutella.devel:
:my gtk-gnutella from newest devel branch crashes when I try to start it.
:This is the output:
:
:14-08-21 18:39:46.883 (FATAL): Assertion failure at
:src/lib/xmalloc.c:1295: "size_is_positive(len)"
This is a gcc 4.9 optimizer bug. I have
Hi list,
my gtk-gnutella from newest devel branch crashes when I try to start it.
This is the output:
14-08-21 18:39:46.883 (FATAL): Assertion failure at
src/lib/xmalloc.c:1295: "size_is_positive(len)"
14-08-21 18:39:46.883 (WARNING): disabling locks, now in thread-unsafe
mode (2 threads)
14-0
Op 7 aug 2011, om 22:52 heeft german bloger het volgende geschreven:
> My setup uses IPv6 only. The machines don't have a IPv4 internet connection.
> After exactly 1 hour without successful bootstraping gtk-gnutella crashes
> with this error:
> 11-08-07 22:16:38 (FATAL): Assertion failure in sr
Hi,
I don't know if this is a bug or not because I don't think gtk-gnutella is
used to be run like this.
My setup uses IPv6 only. The machines don't have a IPv4 internet connection.
After exactly 1 hour without successful bootstraping gtk-gnutella crashes
with this error:
11-08-07 22:16:38 (FATAL
Quoting Hauke Lathus from ml.softs.gtk-gnutella.devel:
:OK, this is the output:
:
:upnp_possible = FALSE
:port_mapping_possible = FALSE
:natpmp_possible = FALSE
OK, so this explains the bug you were having and confirms my fix.
Raphael
On Saturday 05 March 2011, Raphael Manfredi wrote:
> Can you please show me the output of the following shell command:
>
> $ echo props -v possible | gtk-gnutella --shell
OK, this is the output:
upnp_possible = FALSE
port_mapping_possible = FALSE
natpmp_possible = FALSE
Hauke
---
Quoting Hauke Lathus from ml.softs.gtk-gnutella.devel:
:I don't know if my router supports UPnP. It likely does, but I intend to
:completely ignore this feature. I configure everything manually and
:statically where possible.
Sure.
Can you please show me the output of the following shell comma
On Saturday 05 March 2011, Raphael Manfredi wrote:
> Just to confirm: you have no UPnP nor NAT-PMP capable devices, and
> you are UDP or TCP firewalled, right?
Not quite. I am behind a NAT router, but I have manually forwarded my
configured port for both TCP and UDP, which means that I am not fir
Quoting Hauke Lathus from ml.softs.gtk-gnutella.devel:
:recent SVN versions of GtkG always crash on me after running for a while
:(where "a while" means more than ten minutes, but less than two hours).
Just to confirm: you have no UPnP nor NAT-PMP capable devices, and you
are UDP or TCP firewall
Hi list,
recent SVN versions of GtkG always crash on me after running for a while
(where "a while" means more than ten minutes, but less than two hours).
The latest crash gave me this console output:
11-03-03 22:56:11 (FATAL): Assertion failure in src/upnp/upnp.c:1463:
"igd.dev != NULL || gw.ga
On Sun, Nov 01, 2009 at 12:13:10PM +, Raphael Manfredi wrote:
> Quoting Larry Nieves from ml.softs.gtk-gnutella.devel:
> :It crashes again.
> :Revision: 17150
>
> OK, try with r17153.
Great!
It is working again as expected.
Cheers!
--
Larry Alexánder Nieves Colmenárez
El Li
Quoting Larry Nieves from ml.softs.gtk-gnutella.devel:
:It crashes again.
:Revision: 17150
OK, try with r17153.
The problem was that we were lying to the compiler in lib/parse.h, and
that is an unforgivable sin! So the compiler was optimizing some tests
away because we told it that the paramete
Quoting Larry Nieves from ml.softs.gtk-gnutella.devel:
:Yes, I can confirm the version that crashed was compiled with -O2. Next
:I tried as you suggested to compile with -O0 and the crash didn't
:happen. Bitzi lookups are working as expected.
So we do have a gcc optimizer bug. That's both comfor
Quoting Larry Nieves from ml.softs.gtk-gnutella.devel:
:On Sun, Nov 01, 2009 at 08:36:34AM +, Raphael Manfredi wrote:
:> Could you check whether r17150 (the current latest SVN), compiled with -O2
:> again, crashes during Bitzi lookups? I've changed the function where the
:> crash was happenin
On Sat, Oct 31, 2009 at 08:36:54PM +, Raphael Manfredi wrote:
> To validate this, can you confirm you're not compiling with -O0? Try to
> recompile with -O0 and check again. If that crashes then, it will rule out
> my hypothesis.
Yes, I can confirm the version that crashed was compiled with
On Sun, Nov 01, 2009 at 08:36:34AM +, Raphael Manfredi wrote:
> Could you check whether r17150 (the current latest SVN), compiled with -O2
> again, crashes during Bitzi lookups? I've changed the function where the
> crash was happening to not modify the arguments (which may be confusing the
>
I've just committed r17149 to change parse_ipv6_addr() so that it does not
modify its parameter.
After what I've witnessed today which caused me to issue r17146, I think
gcc suffers from an optimizer bug with parameter handling when these are
put in a register.
Can you try to recompile with the s
Quoting Meelis Roos from ml.softs.gtk-gnutella.devel:
:Program terminated with signal 11, Segmentation fault.
:#0 0x08244b3b in parse_ipv6_addr (s=0x95177cb "", dst=0xbffa0538
:"8JS\tT?\235??f?T?\235?", endptr=0x0) at parse.c:218
:218 *endptr = s;
Everyone seems to suffer fro
Quoting Larry Nieves from ml.softs.gtk-gnutella.devel:
:This happened twice today. The last time I made a core dump, the
:backtrace is as follows:
:
:(gdb) bt
:#0 0xb7f15430 in __kernel_vsyscall ()
:#1 0xb73eb6d0 in raise () from /lib/tls/i686/cmov/libc.so.6
:#2 0x0823d104 in crash_handler (sig
Program terminated with signal 11, Segmentation fault.
#0 0x08244b3b in parse_ipv6_addr (s=0x95177cb "", dst=0xbffa0538
"8JS\tT?\235??f?T?\235?", endptr=0x0) at parse.c:218
218 *endptr = s;
(gdb) bt
#0 0x08244b3b in parse_ipv6_addr (s=0x95177cb "", dst=0xbffa0538
"8JS\tT?\23
Freshly compiled GTKG crashes after attempting to perform a bitzi
lookup:
Last Changed Rev: 17148
Last Changed Date: 2009-10-31 15:33:29 +0100 (Sat, 31 Oct 2009)
This happened twice today. The last time I made a core dump, the
backtrace is as follows:
(gdb) bt
#0 0xb7f15430 in __kernel_vsyscall
Quoting [email protected] from ml.softs.gtk-gnutella.devel:
:setting listen_port to 0 with the 'preferences window' or the
:shell command line causes an assertion failure
I made a fix in SVN 17111 that may work for you. Difficult to say
without a stack trace.
Raphael
---
revision 17067
setting listen_port to 0 with the 'preferences window' or the
shell command line causes an assertion failure
not sure how to build debug symbols for debian.
depending on what I do I get
this with closing the preferences window:
FATAL: Assertion failure in mq.c:754: "l->data
Quoting Meelis Roos from ml.softs.gtk-gnutella.devel:
:Running rev 16961 since yesterday as ultranode, and got this crash
:today. DHT is enabled by hand. Previous uptime was about 56 days with
:DHT of that timeframe.
There has been no changes to the DHT code in recent versions, so the
problem y
Running rev 16961 since yesterday as ultranode, and got this crash
today. DHT is enabled by hand. Previous uptime was about 56 days with
DHT of that timeframe.
Core was generated by `/home/mroos/gg/bin/gtk-gnutella'.
Program terminated with signal 11, Segmentation fault.
#0 0x081639a6 in lk_han
I had rev 16943 running for quite some time. Today opened the search
pane with F8, clicked on another search and gtk-gnutella crashed.
Backtrace below, if it's of any use.
Program terminated with signal 11, Segmentation fault.
#0 0xb79cd314 in IA__g_object_remove_weak_pointer (object=0x1,
Got this after 3.5 days uptime, running as ultrapeer:
(gdb) bt
#0 0xb7f1c410 in ?? ()
#1 0xbfc1349c in ?? ()
#2 0x0006 in ?? ()
#3 0x1c7f in ?? ()
#4 0xb75d8811 in raise () from /lib/tls/i686/cmov/libc.so.6
#5 0xb75d9fb9 in abort () from /lib/tls/i686/cmov/libc.so.6
#6 0xb78bd0b4 in
On Saturday 30 May 2009, Raphael Manfredi wrote:
> OK, this must be because of a bad varargs management...
> Fixed in r16828.
Yes, r16830 works again! Many thanks!
Hauke
--
Register Now for Creativity and Technology (Ca
Quoting Hauke Hachmann from ml.softs.gtk-gnutella.devel:
:On Saturday 30 May 2009, Raphael Manfredi wrote:
:> Can you retry with r16823 to see whether it still crashes for the
:> same reason?
:
:r16823 still crashes at startup, but later than before. I can now see
:the main window for about two s
On Saturday 30 May 2009, Raphael Manfredi wrote:
> Can you retry with r16823 to see whether it still crashes for the
> same reason?
r16823 still crashes at startup, but later than before. I can now see
the main window for about two seconds. Now the reason is a segfault.
The problem is: When I th
Can you retry with r16823 to see whether it still crashes for the same reason?
Thanks,
Raphael
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creati
On Saturday 30 May 2009, Raphael Manfredi wrote:
> However, I need you to do the following on gdb:
>
> frame 6
> p trap_page
(gdb) frame 6
#6 0x006247a7 in vmm_alloc (size=8192) at vmm.c:2055
2055p = alloc_pages(size, TRUE);
(gdb) p trap_page
$1 = (void *) 0x7fde6c6ea000
By t
Quoting Hauke Hachmann from ml.softs.gtk-gnutella.devel:
:Stack trace (I hope I got this right)
:===
:#0 0x7fde690d0065 in raise () from /lib/libc.so.6
:#1 0x7fde690d3153 in abort () from /lib/libc.so.6
:#2 0x005e2d76 in assertion_failure (data=0x74d4b0) at
On Saturday 30 May 2009, Raphael Manfredi wrote:
> :Could you provide a stack trace and a cat of /proc/self/maps?
> :Maybe any of it gives some obvious glue.
>
> And please, could you turn on vmm_debug to 1 and show the last "VMM"
> messages before the crash?
OK, here it comes.
/proc/self/maps
=
On Saturday 30 May 2009, Raphael Manfredi wrote:
> :Could you provide a stack trace and a cat of /proc/self/maps?
> :Maybe any of it gives some obvious glue.
>
> And please, could you turn on vmm_debug to 1 and show the last "VMM"
> messages before the crash?
OK, I sent that. But my mail awaits mo
Quoting Christian Biere from
ml.softs.gtk-gnutella.devel:
:Hauke Hachmann wrote:
:> On Friday 29 May 2009, Christian Biere wrote:
:> > I couldn't reproduce this. Not even on a 32-bit *inux machine.
:> > You're using gtk-gnutella on a 64-bit *inux machine, right?
:>
:> Correct, I am using x86-64
Hauke Hachmann wrote:
> On Friday 29 May 2009, Christian Biere wrote:
> > I couldn't reproduce this. Not even on a 32-bit *inux machine.
> > You're using gtk-gnutella on a 64-bit *inux machine, right?
>
> Correct, I am using x86-64 Linux (current Debian "testing", which means
> software versions
On Friday 29 May 2009, Christian Biere wrote:
> I couldn't reproduce this. Not even on a 32-bit *inux machine.
> You're using gtk-gnutella on a 64-bit *inux machine, right?
Correct, I am using x86-64 Linux (current Debian "testing", which means
software versions roughly being: kernel 2.6.26, glib
Quoting Christian Biere from
ml.softs.gtk-gnutella.devel:
:I doubt this fixes Hauke's issue though. The assertion failure seems to
:imply that mmap() didn't like the hint.
Only he can tell that, but my guess is that the hint was falling in a
newly mapped region that was not loaded in the kernel
Raphael Manfredi wrote:
> Quoting Christian Biere from
> ml.softs.gtk-gnutella.devel:
> :Hauke Hachmann wrote:
> :> On Friday 29 May 2009, Christian Biere wrote:
> :> > This is probably fixed in SVN since r16807 now.
> :
> :> Nope, the newest revision (16813) still crashes on startup.
> :
> :Inde
Quoting Christian Biere from
ml.softs.gtk-gnutella.devel:
:Hauke Hachmann wrote:
:> On Friday 29 May 2009, Christian Biere wrote:
:> > This is probably fixed in SVN since r16807 now.
:
:> Nope, the newest revision (16813) still crashes on startup.
:
:Indeed, I can still reproduce the issues with
Hauke Hachmann wrote:
> On Friday 29 May 2009, Christian Biere wrote:
> > This is probably fixed in SVN since r16807 now.
> Nope, the newest revision (16813) still crashes on startup.
Indeed, I can still reproduce the issues with Help->FAQ but
it takes a bit longer than before.
> But with a diff
Quoting Hauke Hachmann from ml.softs.gtk-gnutella.devel:
:On Friday 29 May 2009, Christian Biere wrote:
:> This is probably fixed in SVN since r16807 now.
:
:Nope, the newest revision (16813) still crashes on startup. But with a
:different error message this time:
:
:FATAL: Assertion failure in v
On Friday 29 May 2009, Christian Biere wrote:
> This is probably fixed in SVN since r16807 now.
Nope, the newest revision (16813) still crashes on startup. But with a
different error message this time:
FATAL: Assertion failure in vmm.c:2311: "amount != 0"
h
---
Hauke Hachmann wrote:
> On Friday 29 May 2009, Matthew Lye wrote:
> > > I have a problem with latest svn revision 16799:...
> [...]
> >
> > That error message is from "lib/vmm.c", which was undergoing some
> > work as recently as revision 16799.
> > Just roll back to 16798 for the day if you need y
Hauke Hachmann wrote:
> On Friday 29 May 2009, Matthew Lye wrote:
> > > I have a problem with latest svn revision 16799:...
> [...]
> >
> > That error message is from "lib/vmm.c", which was undergoing some
> > work as recently as revision 16799.
> > Just roll back to 16798 for the day if you need y
On Friday 29 May 2009, Matthew Lye wrote:
> > I have a problem with latest svn revision 16799:...
[...]
>
> That error message is from "lib/vmm.c", which was undergoing some
> work as recently as revision 16799.
> Just roll back to 16798 for the day if you need your client right
> now.
That did no
Hi list,
I have a problem with latest svn revision 16799: I cannot even start the
application. Directly after invokation I get this error:
** ERROR **: pmap already contains the new region
aborting...
CRASH (pid=14792) by SIGABRT
Aborted
Any ideas?
Hauke
-
Quoting Christian Biere <[EMAIL PROTECTED]> from ml.softs.gtk-gnutella.devel:
:Have you considered that this code is reached even if dht_initialize()
:was never called?
Ouch, my fault. Of course, this is the problem. It's been fixed in r15883.
:Yes, but it's disabled by default for many good re
Raphael Manfredi wrote:
> Quoting Meelis Roos <[EMAIL PROTECTED]> from ml.softs.gtk-gnutella.devel:
> :I have seen current SVN gtk-gnutella crashing abour weekly with UDP
> :processing problems. This time I finally got a readable backtrace and
> :crash location (by the way, I had to comment out t
Quoting Meelis Roos <[EMAIL PROTECTED]> from ml.softs.gtk-gnutella.devel:
:I have seen current SVN gtk-gnutella crashing abour weekly with UDP
:processing problems. This time I finally got a readable backtrace and
:crash location (by the way, I had to comment out the crash handler to
:get sensib
I have seen current SVN gtk-gnutella crashing abour weekly with UDP
processing problems. This time I finally got a readable backtrace and
crash location (by the way, I had to comment out the crash handler to
get sensible core dumps):
Program terminated with signal 11, Segmentation fault.
#0 dh
Quoting Lloyd Bryant <[EMAIL PROTECTED]> from ml.softs.gtk-gnutella.devel:
:R14508, GTK2, Linux i686
:
:After updating to this version, I've had several crashes with the following
:error:
:
:FATAL: Assertion failure in parq.c:1228: "q->by_rel_pos != NULL"
This is fixed as of SVN r14517.
Raphael
Quoting Christian Biere <[EMAIL PROTECTED]> from ml.softs.gtk-gnutella.devel:
:There are also several places in the code where q->by_rel_pos is modified, but
:q->size is not updated, at least not anywhere close to the same code. It's
:in general an extremely bad idea to cache information about some
Lloyd Bryant wrote:
> R14508, GTK2, Linux i686
>
> After updating to this version, I've had several crashes with the following
> error:
>
> FATAL: Assertion failure in parq.c:1228: "q->by_rel_pos != NULL"
I think this assertion is very wrong. It certainly doesn't need to be fatal. If
the list i
R14508, GTK2, Linux i686
After updating to this version, I've had several crashes with the following
error:
FATAL: Assertion failure in parq.c:1228: "q->by_rel_pos != NULL"
I can't pinpoint the exact version I was running before - something from
within a day or so of the release of 0.96.4.
It
Haxe wrote:
> ** ERROR **: file sockets.h: line 149 (socket_check): assertion failed
> (s)
> aborting...
>
> I don't have a stacktrace, but perhaps the assertions are still
> useful...
Nope.
--
Christian
-
This SF.net em
Hi,
gtk-gnutella just crashed with the following error:
WARNING: Assertion failure in visual_progress.c:545: "found"
WARNING: Assertion failure in fileinfo.c:484: "data"
** ERROR **: file sockets.h: line 149 (socket_check): assertion failed
(s)
aborting...
I don't have a stacktrace, but perhap
Lloyd Bryant wrote:
> I had a fair number of downloads (150+) pending at the time of the crash.
> I was not actually doing anything in GtkG at the time of the crash - I was
> switching between several other apps, and when I went back to GtkG the
> screen was frozen (wouldn't update). I was run
version: SVN 12616, GTK2, Linux i686
I had a fair number of downloads (150+) pending at the time of the crash. I
was not actually doing anything in GtkG at the time of the crash - I was
switching between several other apps, and when I went back to GtkG the
screen was frozen (wouldn't update).
On 26 Apr 2006, [EMAIL PROTECTED] wrote:
> On Wednesday 26 April 2006 18:13, Christian Biere wrote:
>> is anyone else seeing frequent crashes with the Gtk+ 2.x GUI?
> ...
>> it just happens sooner or later e.g., when
>> I close a search,
>
> I have also had some crashes in the past months which I c
On Friday 12 August 2005 00:23, Haxe wrote:
> With GTKG from latest CVS, when I start a download, it always crashes
> with the following error message:
In reply to myself, for your information:
Despite the ongoing work in CVS, the error stayed a few days after my
first report. But with today's C
Haxe wrote:
> With GTKG from latest CVS, when I start a download, it always crashes
> with the following error message:
> ** ERROR **: file misc.h: line 433 (is_host_addr): should not be reached
> aborting...
Could you send a stack trace?
--
Christian
pgpbHs3ERhJXe.pgp
Description: PGP sign
Uuh.
With GTKG from latest CVS, when I start a download, it always crashes
with the following error message:
** ERROR **: file misc.h: line 433 (is_host_addr): should not be reached
aborting...
Hauke Hachmann
---
SF.Net email is Sponsored by
Daichi Kawahata wrote:
> I usually compile gtkg with ICU library, however since I have
> updated this library recently, gtkg crashes at startup-time.
> Formerly: ICU 2.6.1 / GCC 3.3.1
> Currently: ICU 2.6.2 / GCC 3.4.2
> GTKG: 0.95b (2004-11-14) with GTK2
> There are two version of backtrace:
>
Hi,
I usually compile gtkg with ICU library, however since I have
updated this library recently, gtkg crashes at startup-time.
Formerly: ICU 2.6.1 / GCC 3.3.1
Currently: ICU 2.6.2 / GCC 3.4.2
GTKG: 0.95b (2004-11-14) with GTK2
There are two version of backtrace:
Cflags: -Wall -ggdb
$ gdb ./gtk-
Hi,
gtk-gnutella crashed here on exit. This happened twice and the uptime was
only a few seconds or minutes. UDP was disabled.
(gdb) bt full
#0 0x in ?? ()
No symbol table info available.
#1 0x08067278 in bio_sendto (bio=0x8689000, to=0xbfbfddc8, data=0x85dc1d4,
len=23) at bsched.c
On Sun, 2004-11-07 at 15:24 +0100, Haxe wrote:
> Oops, another crash.
> When I start the newest version of gtkg from cvs, it always crashes
> within one or two minutes. The failed assertion is the following:
>
> ** ERROR **: file ggep.c: line 569 (ggep_ext_writev): assertion failed:
> (p - buf =
Oops, another crash.
When I start the newest version of gtkg from cvs, it always crashes
within one or two minutes. The failed assertion is the following:
** ERROR **: file ggep.c: line 569 (ggep_ext_writev): assertion failed:
(p - buf == needed)
aborting...
I don't have any debug info at this
On Tuesday 26 October 2004 22:33, Christian Biere wrote:
> Alright, should be fixed in CVS now.
H, not really, but now the failure is different.
I think the error before was always happening when my host tried to
start an upload, right?
Now, it doesn't crash anymore, but uploads still don't
Haxe wrote:
> ** ERROR **: file uploads.c: line 2979 (upload_write): assertion failed:
> ((ssize_t) -1 == written || (guint64) written == pos - u->pos)
> aborting...
Alright, should be fixed in CVS now.
--
Christian
pgpR6FlO93Jdz.pgp
Description: PGP signature
Haxe wrote:
> I don't know how debugging stuff works. But, of course, I'd be pleased
> to learn that :-)
You'll find all you need (if not more) under "Bug Report Howto" on the
website.
--
Christian
pgpiBKyZmPj5i.pgp
Description: PGP signature
On Tuesday 26 October 2004 19:48, Christian Biere wrote:
> Can you get the values of those variables?
How do I do that?
I don't know how debugging stuff works. But, of course, I'd be pleased
to learn that :-)
h
---
This SF.Net email is spons
Haxe wrote:
> ** ERROR **: file uploads.c: line 2979 (upload_write): assertion failed:
> ((ssize_t) -1 == written || (guint64) written == pos - u->pos)
> aborting...
Can you get the values of those variables?
--
Christian
pgpUdNyNUYok2.pgp
Description: PGP signature
Ooops! Today, my gtkg crashed three times!
The first two times, I wasn't running gtkg from the console, so I
couldn't see any text output. But then I started gtkg from the console
and after some minutes it crashed a third time, with the following
violated assertion:
** ERROR **: file uploads.c
Hi,
I managed to track down the bug that made the current GtkG version
crash on my system (FreeBSD 4.7, GTK1). It was a simple buffer
overflow in search_gui.c.
Here is a patch to fix it:
diff -c -r1.75 search_gui.c
*** search_gui.c4 Jan 2004 12:04:19 - 1.75
--- search_gui.c
Here's the relevant portion of the stack:
#4 0x4027ba8e in g_logv ()
#5 0x4027bb41 in g_log ()
#6 0x8157a9e in zfree (zone=0x8375720, ptr=0x9a6e190) at zalloc.c:277
#7 0x815723d in wfree (ptr=0x9a6e190, size=12) at walloc.c:156
#8 0x80d6793 in dmesh_ban_free_kv (key=0x9665f10, value=0x9a6e190
On Saturday, Jul 26, 2003 at 14:51, Christian Biere wrote:
> Did you really compile 0.92.1c now or did you compile a newer
> version from CVS?
This was using the source for 0.92.1c... The initial compile resulted
in a segfault, but not on the second machine I tried it on. Then,
after including "-L
Hi Conrad,
Conrad Lloyd-Knight <[EMAIL PROTECTED]> wrote:
> I had posted earlier this week about gtk-gnutella crashing upon
> startup.
Did you really compile 0.92.1c now or did you compile a newer
version from CVS? AFAIK, the problem was reading from an
unitialised buffer. Thomas Schuerger found
Hi,
I had posted earlier this week about gtk-gnutella crashing upon
startup. From the backtraces it looked like the crash occured when
calling some libz functions (_DeflateInit, etc.), yet ldd showed libz
was not included in the list of libraries to be linked at run
time. However, during compilati
Hi Nicolas,
Nicolas Pomarede <[EMAIL PROTECTED]> wrote:
> Floating point exception (core dumped)
>
> when resizing the horizontal separator bar in the search window.
>
> I'm using the gtk2 version from sources, on a mandrake 9.1.
>
> To reproduce this, go in the search tab, and move the bar th
Hello, using version 0.92.1c (as well as 0.92), I get a crash with
Floating point exception (core dumped)
when resizing the horizontal separator bar in the search window.
I'm using the gtk2 version from sources, on a mandrake 9.1.
To reproduce this, go in the search tab, and move the bar that
"clayton rollins" <[EMAIL PROTECTED]> wrote:
> (gdb) p*data
> $1 = {handle = 2, valid = 1, start_date = 143979328, last_update =
> 1055294330,
> range_start = 0, range_end = 983, status = 416}
> (gdb) p (char *)data
> $2 = 0x894f040 "\002"
Well, in contrast to the other backtraces the data her
On Sun, 22 Jun 2003 21:16:45 Christian Biere <[EMAIL PROTECTED]> wrote:
"clayton rollins" <[EMAIL PROTECTED]> wrote:
> #6 0x80d7af4 in uploads_gui_update_display (now=1055294330) at
> uploads_gui2.c:437
> data = (upload_row_data_t *) 0x894f040
If you ever see this again, could you do a
p
"clayton rollins" <[EMAIL PROTECTED]> wrote:
> Here's a full bt:
> (gdb) bt f
> #0 0x2875a9d7 in g_mem_chunk_free () from
> #/usr/local/lib/libglib-2.0.so.200
> No symbol table info available.
> #1 0x2833ca4f in _gtk_tree_data_list_free (list=0x8319d00,
> column_headers=0x8756800) at gtktree
Hey'
I can confirm this on Slackware-9.0. Crashed after ~40m with Upload pane
sorted on Status (descending - wouldn't crash sorted ascending but that
may well be coincidence.) With no such sorting gtkg ran for well over 5
hours but then crashed on Quit (but that's another bug report.)
This is f
Hi all,
I'm catching a crash in gtktreelist with the latest candidate. This only
seems to happen if I sort the upload pane by the status column. (I've tested
a few different configs; it only happens this way. Doesn't happen when
sorting by any of the other columns...) When it is set up this way
On Wed, 2003-03-26 at 18:29, Jeroen Asselman wrote:
> Did you compile with debugging output?
If you mean stuff like this:
03/03/26 20:01:38 (WARNING): malformed /uri-res/N2R? Alternate-Location:
urn:sha1:NZBOA5MERECKJYORJLLM62623
then yes. There is quite a bit about PARQ too. I just used the de
Op wo 26-03-2003, om 18:02 schreef Benny Amorsen:
> ** ERROR **: file parq.c: line 1146 (parq_upload_busy): assertion
> failed: (parq_ul != NULL)
One thing crossed my mind do you have "Enable dynamic upload slots
allocation" enabled?
>
>
> #0 0x42028801 in ?? ()
> #1 0x42029aeb in ?? ()
> #2
On Wed, 2003-03-26 at 15:50, Jeroen Asselman wrote:
> Are you running a clean CVS version? As this is starting to look like
> a memory corruption problem again to me :-sI look get into it as soon
> as I get home. Perhaps the length assertion is related to this one.
> But I hardly can imagine you r
Benny Amorsen zei:
> On Wed, 2003-03-26 at 13:36, Jeroen Asselman wrote:
>> Benny Amorsen zei:
>> > With current CVS, I keep getting this error every few minutes:
>> >
>> > ** ERROR **: file parq.c: line 1070 (parq_upload_request): assertion
>> > failed: (length > PARQ_MAX_ID_LENGTH)
>>
>> Hmm, not
With current CVS, I keep getting this error every few minutes:
** ERROR **: file parq.c: line 1070 (parq_upload_request): assertion
failed: (length > PARQ_MAX_ID_LENGTH)
Benny
signature.asc
Description: This is a digitally signed message part
Hi all,
I left current (well, I just did a CVS update and the only thing that
changed was the interface files, so very close to current, anyway) CVS
running and was greeted with a crash when I came back to it.
./run: line 11: 24953 Segmentation fault (core dumped) src/gtk-gnutella
Stack tra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm using the latest CVS and tried to right click->resume on a download
currently waiting for restart.
This crashes each time.
I can try to provide more data if you need.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+US
97 matches
Mail list logo
