d4x crashes in strlen () from /lib64/libc.so.6
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gtk+2.0 (Debian) |
Fix Released
|
Unknown
|
|||
gtk+2.0 (Ubuntu) |
Invalid
|
High
|
Sebastien Bacher |
Bug Description
Automatically imported from Debian bug report #339419 http://
In Debian Bug tracker #339419, Cai Qian (caiqian-debian) wrote : Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6 | #1 |
In Debian Bug tracker #339419, Relf (relf) wrote : | #2 |
Cai Qian wrote:
>> d4x on attempt to process a link like
>> ftp://a5:<email address hidden>
>>
>> Please note that this particular link is already expired (i.e., login is incorrect and d4x survives).
>> To get a fresh one, open http://
>> wait 15 sec, click "Click here to continue to the download page.", wait another 15 sec and
>> find the link under "FileFactory FTP -- Click here to download".
>>
> I can't reproduce it, as it is said "No such file or directory." Can you check
> the link?
To reproduce:
1) open http://
2) wait 15 sec
3) click at "Click here to continue to the download page."
4) wait another 15 sec
5) find a link to ftp under "FileFactory FTP -- Click here to download"
6) try to download this link with d4x
Max
In Debian Bug tracker #339419, Cai Qian (caiqian-debian) wrote : | #3 |
Hi,
From: Max Alekseyev <email address hidden>
Subject: Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
Date: Fri, 18 Nov 2005 11:37:58 -0800
> To reproduce:
> 1) open http://
> 2) wait 15 sec
> 3) click at "Click here to continue to the download page."
> 4) wait another 15 sec
> 5) find a link to ftp under "FileFactory FTP -- Click here to download"
> 6) try to download this link with d4x
>
> Max
>
I suppose this file has been removed, as I got
550 /e/edbf5d055412
directory
Cai Qian
In Debian Bug tracker #339419, Relf (relf) wrote : | #4 |
Cai Qian wrote:
>> To reproduce:
>> 1) open http://
>> 2) wait 15 sec
>> 3) click at "Click here to continue to the download page."
>> 4) wait another 15 sec
>> 5) find a link to ftp under "FileFactory FTP -- Click here to download"
>> 6) try to download this link with d4x
>>
>> Max
>>
> I suppose this file has been removed, as I got
>
> 550 /e/edbf5d055412
> directory
Please try to start with any of the following links at step 1:
http://
http://
http://
Max
In Debian Bug tracker #339419, Cai Qian (caiqian-debian) wrote : d4x | #5 |
forworded 339419 Maxim Koshelev
tags 339419 confirmed
In Debian Bug tracker #339419, Cai Qian (caiqian-debian) wrote : | #6 |
forwarded 339419 Maxim Koshelev
In Debian Bug tracker #339419, Cai Qian (caiqian-debian) wrote : | #7 |
reassign 339419 libgtk2.0-0
Hi,
This bug is caused by mismatch versions between libgtk2.0-0 (2.8.3-1) and
libglib2.0-0 (2.6.10-1) in unstable. If use both 2.8 or 2.6, d4x will not
crash.
Cai Qian
Debian Bug Importer (debzilla) wrote : | #8 |
Automatically imported from Debian bug report #339419 http://
Debian Bug Importer (debzilla) wrote : | #9 |
Message-Id: <email address hidden>
Date: Tue, 15 Nov 2005 22:15:11 -0800
From: Max <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: d4x crashes in strlen () from /lib64/libc.so.6
Package: d4x
Version: 2.5.6-2
Severity: grave
Justification: renders package unusable
d4x on attempt to process a link like
ftp://a5:<email address hidden>
Please note that this particular link is already expired (i.e., login is incorrect and d4x survives).
To get a fresh one, open http://
wait 15 sec, click "Click here to continue to the download page.", wait another 15 sec and
find the link under "FileFactory FTP -- Click here to download".
100% reproduciable here
Top of backtrace is
#0 0x00002aaaac8e4a20 in strlen () from /lib64/libc.so.6
#1 0x00002aaaac47af6a in std::string:
#2 0x0000000000455f2d in std::operator+
#3 0x0000000000438e84 in std::operator+
#4 0x000000000043af15 in std::operator+
#5 0x00002aaaaabc9b1c in start_thread () from /lib64/
#6 0x00002aaaac93d3e2 in clone () from /lib64/libc.so.6
#7 0x0000000000000000 in ?? ()
....
At the end of strace log I see
[pid 4293] rt_sigprocmask(
[pid 4293] rt_sigprocmask(
[pid 4293] select(7, [6], NULL, NULL, {300, 0}) = 1 (in [6], left {300, 0})
[pid 4293] recvfrom(6, "\n", 1, 0, NULL, NULL) = 1
[pid 4293] rt_sigprocmask(
[pid 4293] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 4293 detached
[pid 4241] <... poll resumed> [{fd=5, events=POLLIN}], 1, 249) = -1 EINTR (Interrupted system call)
[pid 4242] <... futex resumed> ) = -1 EINTR (Interrupted system call)
[pid 4244] <... select resumed> ) = ? ERESTARTNOHAND (To be restarted)
[pid 4242] +++ killed by SIGSEGV +++
[pid 4244] +++ killed by SIGSEGV +++
+++ killed by SIGSEGV +++
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'sarge-
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.64
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=
Versions of packages d4x depends on:
ii d4x-common 2.5.6-2 graphical download manager - commo
ii libao2 0.8.6-1.1 Cross Platform Audio Output Librar
ii libatk1.0-0 1.10.3-1 The ATK accessibility toolkit
ii libc6 2.3.5-7 GNU C Library: Shared libraries an
ii libgcc1 1:4.0.2-3 GCC support library
ii libglib2.0-0 2.8.3-1 The GLib library of C routines
ii libgtk2.0-0 2.6.10-1 The GTK+ graphical user interface
ii libpango1.0-0 1.8.2-3 Layou...
Debian Bug Importer (debzilla) wrote : | #10 |
Message-Id: <email address hidden>
Date: Fri, 18 Nov 2005 14:40:40 +0000 (GMT)
From: Cai Qian <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
Hi,
From: Max <email address hidden>
Subject: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
Date: Tue, 15 Nov 2005 22:15:11 -0800
> Package: d4x
> Version: 2.5.6-2
> Severity: grave
> Justification: renders package unusable
>
> d4x on attempt to process a link like
> ftp://a5:<email address hidden>
>
> Please note that this particular link is already expired (i.e., login is incorrect and d4x survives).
> To get a fresh one, open http://
> wait 15 sec, click "Click here to continue to the download page.", wait another 15 sec and
> find the link under "FileFactory FTP -- Click here to download".
>
I can't reproduce it, as it is said "No such file or directory." Can you check
the link?
Cai Qian
Debian Bug Importer (debzilla) wrote : | #11 |
Message-ID: <email address hidden>
Date: Fri, 18 Nov 2005 11:37:58 -0800
From: Max Alekseyev <email address hidden>
To: Cai Qian <email address hidden>
CC: <email address hidden>
Subject: Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
Cai Qian wrote:
>> d4x on attempt to process a link like
>> ftp://a5:<email address hidden>
>>
>> Please note that this particular link is already expired (i.e., login is incorrect and d4x survives).
>> To get a fresh one, open http://
>> wait 15 sec, click "Click here to continue to the download page.", wait another 15 sec and
>> find the link under "FileFactory FTP -- Click here to download".
>>
> I can't reproduce it, as it is said "No such file or directory." Can you check
> the link?
To reproduce:
1) open http://
2) wait 15 sec
3) click at "Click here to continue to the download page."
4) wait another 15 sec
5) find a link to ftp under "FileFactory FTP -- Click here to download"
6) try to download this link with d4x
Max
Debian Bug Importer (debzilla) wrote : | #12 |
Message-Id: <email address hidden>
Date: Fri, 18 Nov 2005 20:20:04 +0000 (GMT)
From: Cai Qian <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
Hi,
From: Max Alekseyev <email address hidden>
Subject: Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
Date: Fri, 18 Nov 2005 11:37:58 -0800
> To reproduce:
> 1) open http://
> 2) wait 15 sec
> 3) click at "Click here to continue to the download page."
> 4) wait another 15 sec
> 5) find a link to ftp under "FileFactory FTP -- Click here to download"
> 6) try to download this link with d4x
>
> Max
>
I suppose this file has been removed, as I got
550 /e/edbf5d055412
directory
Cai Qian
Debian Bug Importer (debzilla) wrote : | #13 |
Message-ID: <email address hidden>
Date: Fri, 18 Nov 2005 12:32:45 -0800
From: Max Alekseyev <email address hidden>
To: Cai Qian <email address hidden>
CC: <email address hidden>
Subject: Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
Cai Qian wrote:
>> To reproduce:
>> 1) open http://
>> 2) wait 15 sec
>> 3) click at "Click here to continue to the download page."
>> 4) wait another 15 sec
>> 5) find a link to ftp under "FileFactory FTP -- Click here to download"
>> 6) try to download this link with d4x
>>
>> Max
>>
> I suppose this file has been removed, as I got
>
> 550 /e/edbf5d055412
> directory
Please try to start with any of the following links at step 1:
http://
http://
http://
Max
Debian Bug Importer (debzilla) wrote : | #14 |
Message-Id: <email address hidden>
Date: Fri, 18 Nov 2005 22:00:07 +0000 (GMT)
From: Cai Qian <email address hidden>
To: <email address hidden>
Subject: d4x
forworded 339419 Maxim Koshelev
tags 339419 confirmed
Debian Bug Importer (debzilla) wrote : | #15 |
Message-Id: <email address hidden>
Date: Fri, 18 Nov 2005 22:17:36 +0000 (GMT)
From: Cai Qian <email address hidden>
To: <email address hidden>
Subject: d4x
forwarded 339419 Maxim Koshelev
Debian Bug Importer (debzilla) wrote : | #16 |
Message-Id: <email address hidden>
Date: Sat, 19 Nov 2005 17:07:20 +0000 (GMT)
From: Cai Qian <email address hidden>
To: <email address hidden>
Cc: <email address hidden>, Max <email address hidden>
Subject: d4x crashes in strlen () from /lib64/libc.so.6
reassign 339419 libgtk2.0-0
Hi,
This bug is caused by mismatch versions between libgtk2.0-0 (2.8.3-1) and
libglib2.0-0 (2.6.10-1) in unstable. If use both 2.8 or 2.6, d4x will not
crash.
Cai Qian
In Debian Bug tracker #339419, Relf (relf) wrote : | #17 |
Cai Qian wrote:
> This bug is caused by mismatch versions between libgtk2.0-0 (2.8.3-1) and
> libglib2.0-0 (2.6.10-1) in unstable. If use both 2.8 or 2.6, d4x will not
> crash.
Could you provide a simpler testcase?
Max
Debian Bug Importer (debzilla) wrote : | #18 |
Message-ID: <email address hidden>
Date: Sat, 19 Nov 2005 12:46:09 -0800
From: Max Alekseyev <email address hidden>
To: Cai Qian <email address hidden>
CC: <email address hidden>
Subject: Re: d4x crashes in strlen () from /lib64/libc.so.6
Cai Qian wrote:
> This bug is caused by mismatch versions between libgtk2.0-0 (2.8.3-1) and
> libglib2.0-0 (2.6.10-1) in unstable. If use both 2.8 or 2.6, d4x will not
> crash.
Could you provide a simpler testcase?
Max
In Debian Bug tracker #339419, Cai Qian (caiqian-debian) wrote : | #19 |
From: Max Alekseyev <email address hidden>
Subject: Re: d4x crashes in strlen () from /lib64/libc.so.6
Date: Sat, 19 Nov 2005 12:46:09 -0800
> Cai Qian wrote:
>
> > This bug is caused by mismatch versions between libgtk2.0-0 (2.8.3-1) and
> > libglib2.0-0 (2.6.10-1) in unstable. If use both 2.8 or 2.6, d4x will not
> > crash.
>
> Could you provide a simpler testcase?
>
> Max
You can try packages in experimental.
http://
Cai Qian
Debian Bug Importer (debzilla) wrote : | #20 |
Message-Id: <email address hidden>
Date: Sun, 20 Nov 2005 09:23:19 +0000 (GMT)
From: Cai Qian <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: Re: d4x crashes in strlen () from /lib64/libc.so.6
From: Max Alekseyev <email address hidden>
Subject: Re: d4x crashes in strlen () from /lib64/libc.so.6
Date: Sat, 19 Nov 2005 12:46:09 -0800
> Cai Qian wrote:
>
> > This bug is caused by mismatch versions between libgtk2.0-0 (2.8.3-1) and
> > libglib2.0-0 (2.6.10-1) in unstable. If use both 2.8 or 2.6, d4x will not
> > crash.
>
> Could you provide a simpler testcase?
>
> Max
You can try packages in experimental.
http://
Cai Qian
Sebastien Bacher (seb128) wrote : | #21 |
not a GTK bug
In Debian Bug tracker #339419, Steve Langasek (vorlon) wrote : Re: d4x crashes in strlen() from lib64/libc.so.6 | #22 |
reassign 339419 libglib2.0-0 2.8.3-1
tags 339419 moreinfo
thanks
If this is a bug in a library, it must be a bug in glib for failing to
maintain compatibility between 2.6 and 2.8. But there is insufficient
information in the bug log to demonstrate that this is a lib bug.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
Debian Bug Importer (debzilla) wrote : | #23 |
Message-ID: <email address hidden>
Date: Tue, 20 Dec 2005 22:07:23 -0800
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: Re: d4x crashes in strlen() from lib64/libc.so.6
--3siQDZowHQqNOShm
Content-Type: text/plain; charset=us-ascii
Content-
Content-
reassign 339419 libglib2.0-0 2.8.3-1
tags 339419 moreinfo
thanks
If this is a bug in a library, it must be a bug in glib for failing to
maintain compatibility between 2.6 and 2.8. But there is insufficient
information in the bug log to demonstrate that this is a lib bug.
--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
--3siQDZowHQqNOShm
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDqPEbKN6
Nt3ln+qtYWffKfL
=5XHw
-----END PGP SIGNATURE-----
--3siQDZowHQqNO
In Debian Bug tracker #339419, Sebastien Bacher (seb128) wrote : Re: Bug#339419: d4x crashes in strlen() from lib64/libc.so.6 | #24 |
Le mardi 20 décembre 2005 à 22:07 -0800, Steve Langasek a écrit :
> If this is a bug in a library, it must be a bug in glib for failing to
> maintain compatibility between 2.6 and 2.8. But there is insufficient
> information in the bug log to demonstrate that this is a lib bug.
I doubt that's a glib bug, the backtrace has no mention of it and they
are not likely to have broken compatibility on it.
--
Sebastien Bacher
Debian Bug Importer (debzilla) wrote : | #25 |
Message-Id: <1135157503.
Date: Wed, 21 Dec 2005 10:31:43 +0100
From: Sebastien Bacher <email address hidden>
To: Steve Langasek <email address hidden>, <email address hidden>
Subject: Re: Bug#339419: d4x crashes in strlen() from lib64/libc.so.6
Le mardi 20 d=E9cembre 2005 =E0 22:07 -0800, Steve Langasek a =E9crit :
> If this is a bug in a library, it must be a bug in glib for failing to
> maintain compatibility between 2.6 and 2.8. But there is insufficient
> information in the bug log to demonstrate that this is a lib bug.=20
I doubt that's a glib bug, the backtrace has no mention of it and they
are not likely to have broken compatibility on it.
--
Sebastien Bacher
In Debian Bug tracker #339419, Loïc Minier (lool) wrote : | #26 |
Hi,
On Sat, Nov 19, 2005, Cai Qian wrote:
> This bug is caused by mismatch versions between libgtk2.0-0 (2.8.3-1) and
> libglib2.0-0 (2.6.10-1) in unstable. If use both 2.8 or 2.6, d4x will not
> crash.
The updates went as follow:
- initially, gtk 2.6 and glib 2.6 were in unstable and testing
- glib 2.8 was uploaded to unstable, and reached testing
- gtk 2.8 was just uploaded to unstable
At no point in time was a Gtk 2.8 at a place with Glib 2.6. In fact
glib 2.6 is gone for a while, except from stable.
The reporter had libgtk2.0-0 2.6.10-1 and libglib2.0-0 2.8.3-1, perhaps
that's what you meant.
Please provide a backtrace of the crash with libglib2.0-dbg and
libgtk2.0-dbg installed. If these libraries don't appear in the
backtrace, it's unlikely a Glib or Gtk bug.
Bye,
--
Loïc Minier <email address hidden>
Current Earth status: NOT DESTROYED
Debian Bug Importer (debzilla) wrote : | #27 |
Message-ID: <email address hidden>
Date: Wed, 21 Dec 2005 11:35:13 +0100
From: =?iso-8859-
To: Cai Qian <email address hidden>
Cc: <email address hidden>, Max <email address hidden>
Subject: Re: d4x crashes in strlen () from /lib64/libc.so.6
Hi,
On Sat, Nov 19, 2005, Cai Qian wrote:
> This bug is caused by mismatch versions between libgtk2.0-0 (2.8.3-1) a=
nd
> libglib2.0-0 (2.6.10-1) in unstable. If use both 2.8 or 2.6, d4x will n=
ot
> crash.
The updates went as follow:
- initially, gtk 2.6 and glib 2.6 were in unstable and testing
- glib 2.8 was uploaded to unstable, and reached testing
- gtk 2.8 was just uploaded to unstable
At no point in time was a Gtk 2.8 at a place with Glib 2.6. In fact
glib 2.6 is gone for a while, except from stable.
The reporter had libgtk2.0-0 2.6.10-1 and libglib2.0-0 2.8.3-1, perhaps
that's what you meant.
Please provide a backtrace of the crash with libglib2.0-dbg and
libgtk2.0-dbg installed. If these libraries don't appear in the
backtrace, it's unlikely a Glib or Gtk bug.
Bye,
--=20
Lo=EFc Minier <email address hidden>
Current Earth status: NOT DESTROYED
In Debian Bug tracker #339419, Relf (relf) wrote : | #28 |
Loïc Minier wrote:
> Please provide a backtrace of the crash with libglib2.0-dbg and
> libgtk2.0-dbg installed. If these libraries don't appear in the
> backtrace, it's unlikely a Glib or Gtk bug.
They called libglib2.0-0-dbg and libgtk2.0-0-dbg here.
These are new backtraces from all 4 threads:
(gdb) run
Starting program: /usr/bin/d4x
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 46912547122192 (LWP 23012)]
[New Thread 1082132832 (LWP 23015)]
[New Thread 1090525536 (LWP 23016)]
[New Thread 1098918240 (LWP 23033)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1098918240 (LWP 23033)]
0x00002aaaac900e60 in strlen () from /lib64/libc.so.6
(gdb) info threads
* 4 Thread 1098918240 (LWP 23033) 0x00002aaaac900e60 in strlen ()
from /lib64/libc.so.6
3 Thread 1090525536 (LWP 23016) 0x00002aaaac9527b6 in select ()
from /lib64/libc.so.6
2 Thread 1082132832 (LWP 23015) 0x00002aaaaabcbb6a in pthread_
1 Thread 46912547122192 (LWP 23012) 0x00002aaaac950870 in poll ()
from /lib64/libc.so.6
(gdb) bt
#0 0x00002aaaac900e60 in strlen () from /lib64/libc.so.6
#1 0x00002aaaac49670a in std::string:
#2 0x0000000000455f2d in std::operator+
#3 0x0000000000438e84 in std::operator+
#4 0x000000000043af15 in std::operator+
#5 0x00002aaaaabc9b1c in start_thread () from /lib64/
#6 0x00002aaaac959c22 in clone () from /lib64/libc.so.6
#7 0x0000000000000000 in ?? ()
(gdb) thread 3
[Switching to thread 3 (Thread 1090525536 (LWP 23016))]#0 0x00002aaaac9527b6 in select () from /lib64/libc.so.6
(gdb) bt
#0 0x00002aaaac9527b6 in select () from /lib64/libc.so.6
#1 0x000000000044df42 in std::operator+
#2 0x000000000044e12a in std::operator+
#3 0x00002aaaaabc9b1c in start_thread () from /lib64/
#4 0x00002aaaac959c22 in clone () from /lib64/libc.so.6
#5 0x0000000000000000 in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 1082132832 (LWP 23015))]#0 0x00002aaaaabcbb6a in pthread_
(gdb) bt
#0 0x00002aaaaabcbb6a in pthread_
from /lib64/
#1 0x0000000000430afb in std::operator+
#2 0x0000000000430c93 in std::operator+
#3 0x00002aaaaabc9b1c in start_thread () from /lib64/
#4 0x00002aaaac959c22 in clone () from /lib64/libc.so.6
#5 0x0000000000000000 in ?? ()
(gdb) thread 1
[Switching to thread 1 (Thread 46912547122192 (LWP 23012))]#0 0x00002aaaac950870 in poll () from /lib64/libc.so.6
(gdb) bt
#0 0x00002aaaac950870 in poll () from /lib64/libc.so.6
#1 0x00002aaaaad024c0 in g_main_
dispatch=1, self=<v...
Debian Bug Importer (debzilla) wrote : | #29 |
Message-ID: <email address hidden>
Date: Wed, 21 Dec 2005 03:37:04 -0800
From: Max Alekseyev <email address hidden>
To: =?ISO-8859-
CC: Cai Qian <email address hidden>, <email address hidden>
Subject: Re: d4x crashes in strlen () from /lib64/libc.so.6
Lo=EFc Minier wrote:
> Please provide a backtrace of the crash with libglib2.0-dbg and
> libgtk2.0-dbg installed. If these libraries don't appear in the
> backtrace, it's unlikely a Glib or Gtk bug.
They called libglib2.0-0-dbg and libgtk2.0-0-dbg here.
These are new backtraces from all 4 threads:
(gdb) run
Starting program: /usr/bin/d4x
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 46912547122192 (LWP 23012)]
[New Thread 1082132832 (LWP 23015)]
[New Thread 1090525536 (LWP 23016)]
[New Thread 1098918240 (LWP 23033)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1098918240 (LWP 23033)]
0x00002aaaac900e60 in strlen () from /lib64/libc.so.6
(gdb) info threads
* 4 Thread 1098918240 (LWP 23033) 0x00002aaaac900e60 in strlen ()
from /lib64/libc.so.6
3 Thread 1090525536 (LWP 23016) 0x00002aaaac9527b6 in select ()
from /lib64/libc.so.6
2 Thread 1082132832 (LWP 23015) 0x00002aaaaabcbb6a in pthread_cond_wa=
it@@GLIBC_2.3.2 () from /lib64/
1 Thread 46912547122192 (LWP 23012) 0x00002aaaac950870 in poll ()
from /lib64/libc.so.6
(gdb) bt
#0 0x00002aaaac900e60 in strlen () from /lib64/libc.so.6
#1 0x00002aaaac49670a in std::string:
.so.6
#2 0x0000000000455f2d in std::operator+
d::allocator<char> > ()
#3 0x0000000000438e84 in std::operator+
d::allocator<char> > ()
#4 0x000000000043af15 in std::operator+
d::allocator<char> > ()
#5 0x00002aaaaabc9b1c in start_thread () from /lib64/
#6 0x00002aaaac959c22 in clone () from /lib64/libc.so.6
#7 0x0000000000000000 in ?? ()
(gdb) thread 3
[Switching to thread 3 (Thread 1090525536 (LWP 23016))]#0 0x00002aaaac95=
27b6 in select () from /lib64/libc.so.6
(gdb) bt
#0 0x00002aaaac9527b6 in select () from /lib64/libc.so.6
#1 0x000000000044df42 in std::operator+
d::allocator<char> > ()
#2 0x000000000044e12a in std::operator+
d::allocator<char> > ()
#3 0x00002aaaaabc9b1c in start_thread () from /lib64/
#4 0x00002aaaac959c22 in clone () from /lib64/libc.so.6
#5 0x0000000000000000 in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 1082132832 (LWP 23015))]#0 0x00002aaaaabc=
bb6a in pthread_
(gdb) bt
#0 0x00002aaaaabcbb6a in pthread_
from /lib64/
#1 0x0000000000430afb in std::operator+
d::allocator<char> > ()
#2 0x0000000000430c93 in std::operator+
d::allocator<char> > ()
#3 0x00002aaaaabc9b1c in start_thread () from /lib64/
#4 0x00002aaaac959c22 in clone () from /lib64/libc.so.6
#5 0x0000000000000000 in...
In Debian Bug tracker #339419, Loïc Minier (lool) wrote : | #30 |
Hi,
On Wed, Dec 21, 2005, Max Alekseyev wrote:
> They called libglib2.0-0-dbg and libgtk2.0-0-dbg here.
Examining the second backtrace still doesn't point at them, my comments
are below.
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1098918240 (LWP 23033)]
> 0x00002aaaac900e60 in strlen () from /lib64/libc.so.6
The segfault happens in Thread 1098918240...
> (gdb) info threads
> * 4 Thread 1098918240 (LWP 23033) 0x00002aaaac900e60 in strlen ()
> from /lib64/libc.so.6
... which is thread 4.
> 3 Thread 1090525536 (LWP 23016) 0x00002aaaac9527b6 in select ()
> from /lib64/libc.so.6
Another thread is in select(), waiting for something to happen on some
file descriptors.
> 2 Thread 1082132832 (LWP 23015) 0x00002aaaaabcbb6a in
> pthread_
That thread is waiting for a lock.
> 1 Thread 46912547122192 (LWP 23012) 0x00002aaaac950870 in poll ()
> from /lib64/libc.so.6
And that one is also waiting for some even on some file descriptor.
There's one alive thread, thread 4, even if I can't tell whether you
are running SMP.
> (gdb) bt
> #0 0x00002aaaac900e60 in strlen () from /lib64/libc.so.6
The actual crash happens here, probably because a borken address was
passed to strlen().
> #1 0x00002aaaac49670a in std::string:
> /usr/lib/
This function probably only relayed the string to strlen().
> #2 0x0000000000455f2d in std::operator+
> std::allocator<
> #3 0x0000000000438e84 in std::operator+
> std::allocator<
> #4 0x000000000043af15 in std::operator+
> std::allocator<
> #5 0x00002aaaaabc9b1c in start_thread () from /lib64/
> #6 0x00002aaaac959c22 in clone () from /lib64/libc.so.6
> #7 0x0000000000000000 in ?? ()
Now for that part, I can't tell, but it looks like some strings were
concatenated together.
Could you please install libc6-dbg so that we see clearer in these
calls?
Also, would you rebuild d4x with debugging symbols as explained at
<http://
less I suppose.
Thanks,
--
Loïc Minier <email address hidden>
Debian Bug Importer (debzilla) wrote : | #31 |
Message-ID: <email address hidden>
Date: Wed, 21 Dec 2005 13:58:13 +0100
From: =?iso-8859-
To: Max Alekseyev <email address hidden>
Cc: Cai Qian <email address hidden>, <email address hidden>
Subject: Re: d4x crashes in strlen () from /lib64/libc.so.6
Hi,
On Wed, Dec 21, 2005, Max Alekseyev wrote:
> They called libglib2.0-0-dbg and libgtk2.0-0-dbg here.
Examining the second backtrace still doesn't point at them, my comments
are below.
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1098918240 (LWP 23033)]
> 0x00002aaaac900e60 in strlen () from /lib64/libc.so.6
The segfault happens in Thread 1098918240...
> (gdb) info threads
> * 4 Thread 1098918240 (LWP 23033) 0x00002aaaac900e60 in strlen ()
> from /lib64/libc.so.6
... which is thread 4.
> 3 Thread 1090525536 (LWP 23016) 0x00002aaaac9527b6 in select ()
> from /lib64/libc.so.6
Another thread is in select(), waiting for something to happen on some
file descriptors.
> 2 Thread 1082132832 (LWP 23015) 0x00002aaaaabcbb6a in=20
> pthread_
That thread is waiting for a lock.
> 1 Thread 46912547122192 (LWP 23012) 0x00002aaaac950870 in poll ()
> from /lib64/libc.so.6
And that one is also waiting for some even on some file descriptor.
There's one alive thread, thread 4, even if I can't tell whether you
are running SMP.
> (gdb) bt
> #0 0x00002aaaac900e60 in strlen () from /lib64/libc.so.6
The actual crash happens here, probably because a borken address was
passed to strlen().
> #1 0x00002aaaac49670a in std::string:
> /usr/lib/
This function probably only relayed the string to strlen().
> #2 0x0000000000455f2d in std::operator+
> std::allocator<
> #3 0x0000000000438e84 in std::operator+
> std::allocator<
> #4 0x000000000043af15 in std::operator+
> std::allocator<
> #5 0x00002aaaaabc9b1c in start_thread () from /lib64/
> #6 0x00002aaaac959c22 in clone () from /lib64/libc.so.6
> #7 0x0000000000000000 in ?? ()
Now for that part, I can't tell, but it looks like some strings were
concatenated together.
Could you please install libc6-dbg so that we see clearer in these
calls?
Also, would you rebuild d4x with debugging symbols as explained at
<http://
less I suppose.
Thanks,
--=20
Lo=EFc Minier <email address hidden>
In Debian Bug tracker #339419, Steve Langasek (vorlon) wrote : Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6 | #32 |
On Wed, Dec 21, 2005 at 01:58:13PM +0100, Loïc Minier wrote:
> > (gdb) bt
> > #0 0x00002aaaac900e60 in strlen () from /lib64/libc.so.6
> The actual crash happens here, probably because a borken address was
> passed to strlen().
> > #1 0x00002aaaac49670a in std::string:
> > /usr/lib/
> This function probably only relayed the string to strlen().
> > #2 0x0000000000455f2d in std::operator+
> > std::allocator<
> > #3 0x0000000000438e84 in std::operator+
> > std::allocator<
> > #4 0x000000000043af15 in std::operator+
> > std::allocator<
> > #5 0x00002aaaaabc9b1c in start_thread () from /lib64/
> > #6 0x00002aaaac959c22 in clone () from /lib64/libc.so.6
> > #7 0x0000000000000000 in ?? ()
> Now for that part, I can't tell, but it looks like some strings were
> concatenated together.
> Could you please install libc6-dbg so that we see clearer in these
> calls?
All that will do is let you look at the value passed to strlen(); it won't
tell you much about why it's wrong or where it came from.
> Also, would you rebuild d4x with debugging symbols as explained at
> <http://
> less I suppose.
I didn't see much evidence here that gdb was confused?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
In Debian Bug tracker #339419, Loïc Minier (lool) wrote : | #33 |
On Wed, Dec 21, 2005, Steve Langasek wrote:
> All that will do is let you look at the value passed to strlen(); it won't
> tell you much about why it's wrong or where it came from.
I imaginated it would help tracing a 64 bits -> 32-bits cast would that
be the problem here.
What do you suggest?
--
Loïc Minier <email address hidden>
Current Earth status: NOT DESTROYED
In Debian Bug tracker #339419, Steve Langasek (vorlon) wrote : | #34 |
On Wed, Dec 21, 2005 at 07:59:06PM +0100, Loïc Minier wrote:
> On Wed, Dec 21, 2005, Steve Langasek wrote:
> > All that will do is let you look at the value passed to strlen(); it won't
> > tell you much about why it's wrong or where it came from.
> I imaginated it would help tracing a 64 bits -> 32-bits cast would that
> be the problem here.
Well, it may show you that this is the problem, but it won't really show you
where it's happening if the guilty function isn't already in the backtrace.
(I'm assuming we can rule out this being a libstdc++ or libc bug.)
Also, aren't broken 64bit->32bit casts all fatal errors under gcc4? d4x has
been built with gcc-4.0, as had gtk+2.0 2.6.10.
> What do you suggest?
valgrind?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
Debian Bug Importer (debzilla) wrote : | #35 |
Message-ID: <email address hidden>
Date: Wed, 21 Dec 2005 10:53:06 -0800
From: Steve Langasek <email address hidden>
To: =?iso-8859-
<email address hidden>
Cc: Max Alekseyev <email address hidden>, Cai Qian <email address hidden>
Subject: Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
--Qz2CZ664xQdCRdPu
Content-Type: text/plain; charset=iso-8859-1
Content-
Content-
On Wed, Dec 21, 2005 at 01:58:13PM +0100, Lo=EFc Minier wrote:
> > (gdb) bt
> > #0 0x00002aaaac900e60 in strlen () from /lib64/libc.so.6
> The actual crash happens here, probably because a borken address was
> passed to strlen().
> > #1 0x00002aaaac49670a in std::string:
> > /usr/lib/
> This function probably only relayed the string to strlen().
> > #2 0x0000000000455f2d in std::operator+
=20
> > std::allocator<
> > #3 0x0000000000438e84 in std::operator+
=20
> > std::allocator<
> > #4 0x000000000043af15 in std::operator+
=20
> > std::allocator<
> > #5 0x00002aaaaabc9b1c in start_thread () from /lib64/
> > #6 0x00002aaaac959c22 in clone () from /lib64/libc.so.6
> > #7 0x0000000000000000 in ?? ()
> Now for that part, I can't tell, but it looks like some strings were
> concatenated together.
> Could you please install libc6-dbg so that we see clearer in these
> calls?
All that will do is let you look at the value passed to strlen(); it won't
tell you much about why it's wrong or where it came from.
> Also, would you rebuild d4x with debugging symbols as explained at
> <http://
> less I suppose.
I didn't see much evidence here that gdb was confused?
--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
--Qz2CZ664xQdCRdPu
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDqaSSKN6
0BBYaWjGms9EkVk
=tJ26
-----END PGP SIGNATURE-----
--Qz2CZ664xQdCR
Debian Bug Importer (debzilla) wrote : | #36 |
Message-ID: <email address hidden>
Date: Wed, 21 Dec 2005 19:59:06 +0100
From: =?iso-8859-
To: Steve Langasek <email address hidden>
Cc: <email address hidden>, Max Alekseyev <email address hidden>,
Cai Qian <email address hidden>
Subject: Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
On Wed, Dec 21, 2005, Steve Langasek wrote:
> All that will do is let you look at the value passed to strlen(); it wo=
n't
> tell you much about why it's wrong or where it came from.
I imaginated it would help tracing a 64 bits -> 32-bits cast would that
be the problem here.
What do you suggest?
--=20
Lo=EFc Minier <email address hidden>
Current Earth status: NOT DESTROYED
Debian Bug Importer (debzilla) wrote : | #37 |
Message-ID: <email address hidden>
Date: Wed, 21 Dec 2005 11:14:28 -0800
From: Steve Langasek <email address hidden>
To: =?iso-8859-
Cc: <email address hidden>, Max Alekseyev <email address hidden>,
Cai Qian <email address hidden>
Subject: Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
--UTZ8bGhNySVQ9LYl
Content-Type: text/plain; charset=iso-8859-1
Content-
Content-
On Wed, Dec 21, 2005 at 07:59:06PM +0100, Lo=EFc Minier wrote:
> On Wed, Dec 21, 2005, Steve Langasek wrote:
> > All that will do is let you look at the value passed to strlen(); it wo=
n't
> > tell you much about why it's wrong or where it came from.
> I imaginated it would help tracing a 64 bits -> 32-bits cast would that
> be the problem here.
Well, it may show you that this is the problem, but it won't really show you
where it's happening if the guilty function isn't already in the backtrace.
(I'm assuming we can rule out this being a libstdc++ or libc bug.)
Also, aren't broken 64bit->32bit casts all fatal errors under gcc4? d4x has
been built with gcc-4.0, as had gtk+2.0 2.6.10.
> What do you suggest?
valgrind?
--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
--UTZ8bGhNySVQ9LYl
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDqamUKN6
3TS9U5XofcAX2SE
=i/hp
-----END PGP SIGNATURE-----
--UTZ8bGhNySVQ9
In Debian Bug tracker #339419, Relf (relf) wrote : | #38 |
Steve Langasek wrote:
> valgrind?
This is the output of valgrind with libc6-dbg:
$ valgrind d4x
==31813== Memcheck, a memory error detector.
==31813== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==31813== Using LibVEX rev 1367, a library for dynamic binary translation.
==31813== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==31813== Using valgrind-
==31813== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==31813== For more details, rerun with: -v
==31813==
==31813== Conditional jump or move depends on uninitialised value(s)
==31813== at 0x11910B6E: (within /lib/ld-2.3.5.so)
==31813== by 0x11906BD1: (within /lib/ld-2.3.5.so)
==31813== by 0x139FD150: dl_open_worker (dl-open.c:259)
==31813== by 0x1190B920: (within /lib/ld-2.3.5.so)
==31813== by 0x139FDA0A: _dl_open (dl-open.c:577)
==31813== by 0x139FEE47: do_dlopen (dl-libc.c:80)
==31813== by 0x1190B920: (within /lib/ld-2.3.5.so)
==31813== by 0x139FEF61: __libc_dlopen_mode (dl-libc.c:42)
==31813== by 0x139DABBA: __nss_lookup_
==31813== by 0x139DAD53: __nss_lookup (nsswitch.c:150)
==31813== by 0x1399148B: getpwuid_
==31813== by 0x11D96F40: (within /usr/lib/
==31813==
==31813== Conditional jump or move depends on uninitialised value(s)
==31813== at 0x11910B79: (within /lib/ld-2.3.5.so)
==31813== by 0x11906BD1: (within /lib/ld-2.3.5.so)
==31813== by 0x139FD150: dl_open_worker (dl-open.c:259)
==31813== by 0x1190B920: (within /lib/ld-2.3.5.so)
==31813== by 0x139FDA0A: _dl_open (dl-open.c:577)
==31813== by 0x139FEE47: do_dlopen (dl-libc.c:80)
==31813== by 0x1190B920: (within /lib/ld-2.3.5.so)
==31813== by 0x139FEF61: __libc_dlopen_mode (dl-libc.c:42)
==31813== by 0x139DABBA: __nss_lookup_
==31813== by 0x139DAD53: __nss_lookup (nsswitch.c:150)
==31813== by 0x1399148B: getpwuid_
==31813== by 0x11D96F40: (within /usr/lib/
==31813==
==31813== Conditional jump or move depends on uninitialised value(s)
==31813== at 0x11910B84: (within /lib/ld-2.3.5.so)
==31813== by 0x11906BD1: (within /lib/ld-2.3.5.so)
==31813== by 0x139FD150: dl_open_worker (dl-open.c:259)
==31813== by 0x1190B920: (within /lib/ld-2.3.5.so)
==31813== by 0x139FDA0A: _dl_open (dl-open.c:577)
==31813== by 0x139FEE47: do_dlopen (dl-libc.c:80)
==31813== by 0x1190B920: (within /lib/ld-2.3.5.so)
==31813== by 0x139FEF61: __libc_dlopen_mode (dl-libc.c:42)
==31813== by 0x139DABBA: __nss_lookup_
==31813== by 0x139DAD53: __nss_lookup (nsswitch.c:150)
==31813== by 0x1399148B: getpwuid_
==31813== by 0x11D96F40: (within /usr/lib/
==31813==
==31813== Conditional jump or move depends on uninitialised value(s)
==31813== at 0x11910CE1: (within /lib/ld-2.3.5.so)
==31813== by 0x11906CDB: (within /lib/ld-2.3.5.so)
==31813== by 0x139FD150: dl_open_worker (dl-open.c:259)
==31813== by 0x1190B920: (...
In Debian Bug tracker #339419, Steve Langasek (vorlon) wrote : | #39 |
reassign 339419 d4x 2.5.6-2
tags 339419 patch
thanks
On Wed, Dec 21, 2005 at 01:05:10PM -0800, Max Alekseyev wrote:
> Steve Langasek wrote:
> >valgrind?
> This is the output of valgrind with libc6-dbg:
Ok, most of this looks like pretty typical garbage output, with a few
messages related to locales and themes that I don't usually see. Are you
using any particular gtk theme here? Do you see the same error if you set
LANG=C instead of LANG=ru_RU.KOI8-R?
Also, I've tested d4x on alpha now, and it bombs out *immediately* upon
clicking 'New download'. The app is completely non-64bit-safe. I've
audited the package for *one* common cause of 64-bit problems in gtk apps,
and attached the patch here. I don't know whether this is the same bug
you're seeing on amd64, but I don't think it's worth trying to look any
further for library bugs until this is resolved.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
In Debian Bug tracker #339419, Relf (relf) wrote : | #40 |
Steve Langasek wrote:
>> This is the output of valgrind with libc6-dbg:
>
> Ok, most of this looks like pretty typical garbage output, with a few
> messages related to locales and themes that I don't usually see. Are you
> using any particular gtk theme here?
I use Smokey Blue theme.
> Do you see the same error if you set LANG=C instead of LANG=ru_RU.KOI8-R?
Yes, I do see it even with LANG=C.
It worth to mention that this bug is somehow related to those FileFactory links (as specified in my original bugreport).
d4x works fine on links to other sites.
Max
Debian Bug Importer (debzilla) wrote : | #41 |
Message-ID: <email address hidden>
Date: Wed, 21 Dec 2005 20:08:35 -0800
From: Steve Langasek <email address hidden>
To: Max Alekseyev <email address hidden>
Cc: =?iso-8859-
<email address hidden>, Cai Qian <email address hidden>
Subject: Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
--/WwmFnJnmDyWGHa4
Content-Type: multipart/mixed; boundary=
Content-
--J2SCkAp4GZ/dPZZf
Content-Type: text/plain; charset=us-ascii
Content-
Content-
reassign 339419 d4x 2.5.6-2
tags 339419 patch
thanks
On Wed, Dec 21, 2005 at 01:05:10PM -0800, Max Alekseyev wrote:
> Steve Langasek wrote:
> >valgrind?
> This is the output of valgrind with libc6-dbg:
Ok, most of this looks like pretty typical garbage output, with a few
messages related to locales and themes that I don't usually see. Are you
using any particular gtk theme here? Do you see the same error if you set
LANG=3DC instead of LANG=3Dru_
Also, I've tested d4x on alpha now, and it bombs out *immediately* upon
clicking 'New download'. The app is completely non-64bit-safe. I've
audited the package for *one* common cause of 64-bit problems in gtk apps,
and attached the patch here. I don't know whether this is the same bug
you're seeing on amd64, but I don't think it's worth trying to look any
further for library bugs until this is resolved.
--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
--J2SCkAp4GZ/dPZZf
Content-Type: text/plain; charset=us-ascii
Content-
Content-
diff -u d4x-2.5.
--- d4x-2.5.
+++ d4x-2.5.
@@ -1,3 +1,11 @@
+d4x (2.5.6-2.1) unstable; urgency=3Dlow
+
+ * Non-maintainer upload.
+ * *GTKTYPE* *IS* *NOT* *AN* *INTEGER* *STOP* *BLOODY* *CASTING* *IT* *AS*
+ *ONE*
+
+ -- Steve Langasek <email address hidden> Wed, 21 Dec 2005 16:06:21 -0800
+
d4x (2.5.6-2) unstable; urgency=3Dlow
=20
* New maintainer (Closes: #336165)
only in patch2:
unchanged:
--- d4x-2.5.
+++ d4x-2.5.
@@ -43,7 +43,7 @@
=20
=20
GtkWidget *my_gtk_
ULL);
-guint my_gtk_
+GtkType my_gtk_
=20
GtkWidget *d4x_scheduler_
void d4x_scheduler_
only in patch2:
unchanged:
--- d4x-2.5.
+++ d4x-2.5.
@@ -813,8 +813,8 @@
=20
};
=20
-guint my_gtk_
- static guint my_aeditor_
+GtkType my_gtk_
+ static GtkType my_aeditor_
if (!my_aeditor_type){
GTypeInfo my_aeditor_info=3D{
sizeof(
only in patch2:
unchanged:
--- d4x-2.5.
+++ d4x-2.5.
@@ -117,8 +117,8 @@
...
In Debian Bug tracker #339419, Steve Langasek (vorlon) wrote : | #42 |
On Wed, Dec 21, 2005 at 08:25:52PM -0800, Max Alekseyev wrote:
> Steve Langasek wrote:
> >>This is the output of valgrind with libc6-dbg:
> >Ok, most of this looks like pretty typical garbage output, with a few
> >messages related to locales and themes that I don't usually see. Are you
> >using any particular gtk theme here?
> I use Smokey Blue theme.
Ok.
> >Do you see the same error if you set LANG=C instead of LANG=ru_RU.KOI8-R?
> Yes, I do see it even with LANG=C.
> It worth to mention that this bug is somehow related to those FileFactory
> links (as specified in my original bugreport).
> d4x works fine on links to other sites.
Well, after fixing the dialog crash, the link from the bug report works fine
for me on alpha. Perhaps you could test using the patch I sent in the last
mail, to confirm the bug still exists?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
Debian Bug Importer (debzilla) wrote : | #43 |
Message-ID: <email address hidden>
Date: Wed, 21 Dec 2005 20:25:52 -0800
From: Max Alekseyev <email address hidden>
To: Steve Langasek <email address hidden>
CC: =?KOI8-
Cai Qian <email address hidden>
Subject: Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
Steve Langasek wrote:
>> This is the output of valgrind with libc6-dbg:
>
> Ok, most of this looks like pretty typical garbage output, with a few
> messages related to locales and themes that I don't usually see. Are you
> using any particular gtk theme here?
I use Smokey Blue theme.
> Do you see the same error if you set LANG=C instead of LANG=ru_RU.KOI8-R?
Yes, I do see it even with LANG=C.
It worth to mention that this bug is somehow related to those FileFactory links (as specified in my original bugreport).
d4x works fine on links to other sites.
Max
Debian Bug Importer (debzilla) wrote : | #44 |
Message-ID: <email address hidden>
Date: Wed, 21 Dec 2005 20:48:51 -0800
From: Steve Langasek <email address hidden>
To: Max Alekseyev <email address hidden>
Cc: =?iso-8859-
<email address hidden>, Cai Qian <email address hidden>
Subject: Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
--XWOWbaMNXpFDWE00
Content-Type: text/plain; charset=us-ascii
Content-
Content-
On Wed, Dec 21, 2005 at 08:25:52PM -0800, Max Alekseyev wrote:
> Steve Langasek wrote:
> >>This is the output of valgrind with libc6-dbg:
> >Ok, most of this looks like pretty typical garbage output, with a few
> >messages related to locales and themes that I don't usually see. Are you
> >using any particular gtk theme here?
> I use Smokey Blue theme.
Ok.
> >Do you see the same error if you set LANG=3DC instead of LANG=3Dru_RU.KO=
I8-R?
> Yes, I do see it even with LANG=3DC.
> It worth to mention that this bug is somehow related to those FileFactory=
=20
> links (as specified in my original bugreport).
> d4x works fine on links to other sites.
Well, after fixing the dialog crash, the link from the bug report works fine
for me on alpha. Perhaps you could test using the patch I sent in the last
mail, to confirm the bug still exists?
--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
--XWOWbaMNXpFDWE00
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDqjAzKN6
PJw2J7Gv1BCIPZz
=rRBm
-----END PGP SIGNATURE-----
--XWOWbaMNXpFDW
In Debian Bug tracker #339419, Relf (relf) wrote : | #45 |
Steve Langasek wrote:
> Well, after fixing the dialog crash, the link from the bug report works fine
> for me on alpha. Perhaps you could test using the patch I sent in the last
> mail, to confirm the bug still exists?
>
Unfortunately it still crashes even with the patch.
Max
Debian Bug Importer (debzilla) wrote : | #46 |
Message-ID: <email address hidden>
Date: Thu, 22 Dec 2005 00:29:58 -0800
From: Max Alekseyev <email address hidden>
To: Steve Langasek <email address hidden>
CC: =?KOI8-
Cai Qian <email address hidden>
Subject: Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
Steve Langasek wrote:
> Well, after fixing the dialog crash, the link from the bug report works fine
> for me on alpha. Perhaps you could test using the patch I sent in the last
> mail, to confirm the bug still exists?
>
Unfortunately it still crashes even with the patch.
Max
In Debian Bug tracker #339419, Steve Langasek (vorlon) wrote : | #47 |
On Thu, Dec 22, 2005 at 12:29:58AM -0800, Max Alekseyev wrote:
> Steve Langasek wrote:
> >Well, after fixing the dialog crash, the link from the bug report works
> >fine
> >for me on alpha. Perhaps you could test using the patch I sent in the last
> >mail, to confirm the bug still exists?
> Unfortunately it still crashes even with the patch.
Well, then I'm afraid I'm out of ideas; the valgrind output doesn't give any
clear pointers, and I can't reproduce the bug on the only 64-bit system
under my control. But at least the problem seems to be very specific to
d4x, since hundreds of other gtk-based applications have been running fine
using the glib/gtk combination on all architectures for some time.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
Debian Bug Importer (debzilla) wrote : | #48 |
Message-ID: <email address hidden>
Date: Sun, 25 Dec 2005 02:35:38 -0800
From: Steve Langasek <email address hidden>
To: Max Alekseyev <email address hidden>, <email address hidden>
Cc: <email address hidden>, "c Minier <email address hidden>, <email address hidden>,
Cai Qian <email address hidden>
Subject: Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
--YToU2i3Vx8H2dn7O
Content-Type: text/plain; charset=us-ascii
Content-
Content-
On Thu, Dec 22, 2005 at 12:29:58AM -0800, Max Alekseyev wrote:
> Steve Langasek wrote:
> >Well, after fixing the dialog crash, the link from the bug report works=
=20
> >fine
> >for me on alpha. Perhaps you could test using the patch I sent in the l=
ast
> >mail, to confirm the bug still exists?
> Unfortunately it still crashes even with the patch.
Well, then I'm afraid I'm out of ideas; the valgrind output doesn't give any
clear pointers, and I can't reproduce the bug on the only 64-bit system
under my control. But at least the problem seems to be very specific to
d4x, since hundreds of other gtk-based applications have been running fine
using the glib/gtk combination on all architectures for some time.
--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
--YToU2i3Vx8H2dn7O
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDrnX6KN6
lD6iDAO+
=DGBs
-----END PGP SIGNATURE-----
--YToU2i3Vx8H2d
In Debian Bug tracker #339419, Cai Qian (caiqian-debian) wrote : | #49 |
Hi,
Stangely, last time I checked it with my LFS machine, and there is no such
problem. However, today I checked with Redhat (glib 2.4.7, gtk 2.4.13),
Ubuntu and Debian (both 2.8.x), and it 100% reproduces. I have enclosed a
detailed backtrace log.
Cai Qian
Debian Bug Importer (debzilla) wrote : | #50 |
Message-Id: <email address hidden>
Date: Sat, 31 Dec 2005 20:01:03 +0000 (GMT)
From: Cai Qian <email address hidden>
To: <email address hidden>
CC: Max <email address hidden>, Steve Langasek <email address hidden>, Sebastien Bacher
<email address hidden>, =?iso-8859-
Subject: Re: d4x crashes in strlen () from /lib64/libc.so.6
----Next_
Content-Type: Text/Plain; charset=us-ascii
Content-
Hi,
Stangely, last time I checked it with my LFS machine, and there is no such
problem. However, today I checked with Redhat (glib 2.4.7, gtk 2.4.13),
Ubuntu and Debian (both 2.8.x), and it 100% reproduces. I have enclosed a
detailed backtrace log.
Cai Qian
----Next_
Content-Type: Text/Plain; charset=us-ascii
Content-
Content-
Starting program: /home/caiqian/
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 2333)]
[New Thread 32769 (LWP 2336)]
[New Thread 16386 (LWP 2337)]
- 19:40:47 31 12 2005 -------
? 19:40:47 31 12 2005 WebDownloader for X 2.5.6
[New Thread 32771 (LWP 2338)]
[New Thread 49156 (LWP 2339)]
? 19:40:47 31 12 2005 Loading FTP-Search engines
? 19:40:47 31 12 2005 Normally started
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 32771 (LWP 2338)]
0x407e0413 in strlen () from /usr/lib/
Current language: auto; currently c
(gdb) bt
#0 0x407e0413 in strlen () from /usr/lib/
#1 0x406f5a2f in std::string:
#2 0x080577a0 in std::operator=
at basic_string.h:2158
#3 0x080a8f09 in tFtpDownload:
#4 0x080850d3 in tDownload:
#5 0x0808a412 in download_last (nothing=0x819e640) at main.cc:1867
#6 0x4001df4c in pthread_
#7 0x4001dfda in pthread_
#8 0x4083298a in clone () from /usr/lib/
(gdb) thread apply all bt full
Thread 5 (Thread 49156 (LWP 2339)):
#0 0x4082bc81 in select () from /usr/lib/
No locals.
#1 0x40027ff4 in ?? () from /usr/lib/
No symbol table info available.
#2 0x081639f0 in ?? ()
No symbol table info available.
#3 0xbf3ff800 in ?? ()
No symbol table info available.
#4 0x00000000 in ?? ()
No symbol table info available.
Thread 4 (Thread 32771 (LWP 2338)):
#0 0x407e0413 in strlen () from /usr/lib/
malloc_
mallstream = (FILE *) 0x0
lock = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0,
__spinlock = 0}}
tr_old_free_hook = (void (*)(void *, const void *)) 0
tr_old_
mallenv = "M...
In Debian Bug tracker #339419, Steve Langasek (vorlon) wrote : | #51 |
On Sat, Dec 31, 2005 at 08:01:03PM +0000, Cai Qian wrote:
> Stangely, last time I checked it with my LFS machine, and there is no such
> problem. However, today I checked with Redhat (glib 2.4.7, gtk 2.4.13),
> Ubuntu and Debian (both 2.8.x), and it 100% reproduces. I have enclosed a
> detailed backtrace log.
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 32771 (LWP 2338)]
> 0x407e0413 in strlen () from /usr/lib/
> Current language: auto; currently c
> (gdb) bt
> #0 0x407e0413 in strlen () from /usr/lib/
> #1 0x406f5a2f in std::string:
> #2 0x080577a0 in std::operator=
> at basic_string.h:2158
> #3 0x080a8f09 in tFtpDownload:
> #4 0x080850d3 in tDownload:
> #5 0x0808a412 in download_last (nothing=0x819e640) at main.cc:1867
> #6 0x4001df4c in pthread_
> #7 0x4001dfda in pthread_
> #8 0x4083298a in clone () from /usr/lib/
> (gdb) thread apply all bt full
Right, well, with this backtrace pretty solidly confirms that it's a d4x
bug, not a gtk bug; line 487 of tFtpDownload:
ADDR.file to D_FILE.name.get(), and the latter returns NULL -- I don't see
how it can be gtk's fault that an internal struct believes a remote ftp
filename is NULL. (The culprit function seems to be
TFtpDownload:
to figure out where this NULL value is actually coming from -- I just see
that this seems to be the only function that could be setting it.)
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
Debian Bug Importer (debzilla) wrote : | #52 |
Message-ID: <email address hidden>
Date: Sat, 31 Dec 2005 17:42:24 -0800
From: Steve Langasek <email address hidden>
To: Cai Qian <email address hidden>, <email address hidden>
Cc: <email address hidden>, Max <email address hidden>, Sebastien Bacher <email address hidden>,
=?iso-
Subject: Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
--U+BazGySraz5kW0T
Content-Type: text/plain; charset=us-ascii
Content-
Content-
On Sat, Dec 31, 2005 at 08:01:03PM +0000, Cai Qian wrote:
> Stangely, last time I checked it with my LFS machine, and there is no such
> problem. However, today I checked with Redhat (glib 2.4.7, gtk 2.4.13),
> Ubuntu and Debian (both 2.8.x), and it 100% reproduces. I have enclosed a
> detailed backtrace log.
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 32771 (LWP 2338)]
> 0x407e0413 in strlen () from /usr/lib/
> Current language: auto; currently c
> (gdb) bt
> #0 0x407e0413 in strlen () from /usr/lib/
> #1 0x406f5a2f in std::string:
> #2 0x080577a0 in std::operator=
allocator<char> > (__lhs=
> at basic_string.h:2158
> #3 0x080a8f09 in tFtpDownload:
> #4 0x080850d3 in tDownload:
1630
> #5 0x0808a412 in download_last (nothing=
> #6 0x4001df4c in pthread_
> #7 0x4001dfda in pthread_
r.c:334
> #8 0x4083298a in clone () from /usr/lib/
> (gdb) thread apply all bt full
Right, well, with this backtrace pretty solidly confirms that it's a d4x
bug, not a gtk bug; line 487 of tFtpDownload:
ADDR.file to D_FILE.name.get(), and the latter returns NULL -- I don't see
how it can be gtk's fault that an internal struct believes a remote ftp
filename is NULL. (The culprit function seems to be
TFtpDownload:
to figure out where this NULL value is actually coming from -- I just see
that this seems to be the only function that could be setting it.)
Cheers,
--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
--U+BazGySraz5kW0T
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDtzOAKN6
sglV2IlXIJtSmGy
=fB1k
-----END PGP SIGNATURE-----
--U+BazGySraz5k
In Debian Bug tracker #339419, Loïc Minier (lool) wrote : reassign 339419 to d4x | #53 |
# Automatically generated email from bts, devscripts version 2.9.10
reassign 339419 d4x
Debian Bug Importer (debzilla) wrote : | #54 |
Message-Id: <email address hidden>
Date: Sun, 1 Jan 2006 10:22:43 +0100
From: Loic Minier <email address hidden>
To: <email address hidden>
Subject: reassign 339419 to d4x
# Automatically generated email from bts, devscripts version 2.9.10
reassign 339419 d4x
In Debian Bug tracker #339419, Cai Qian (caiqian-debian) wrote : | #55 |
tags 339419 fixed-upstream
In Debian Bug tracker #339419, Cai Qian (caiqian-debian) wrote : Bug#339419: fixed in d4x 2.5.7.1-1 | #56 |
Source: d4x
Source-Version: 2.5.7.1-1
We believe that the bug you reported is fixed in the latest version of
d4x, which is due to be installed in the Debian FTP archive:
d4x-common_
to pool/main/
d4x_2.5.
to pool/main/
d4x_2.5.7.1-1.dsc
to pool/main/
d4x_2.5.
to pool/main/
d4x_2.5.
to pool/main/
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Cai Qian <email address hidden> (supplier of updated d4x package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Sun, 7 May 2006 21:40:38 +0100
Source: d4x
Binary: d4x-common d4x
Architecture: source i386 all
Version: 2.5.7.1-1
Distribution: unstable
Urgency: low
Maintainer: Cai Qian <email address hidden>
Changed-By: Cai Qian <email address hidden>
Description:
d4x - graphical download manager
d4x-common - graphical download manager - common files
Closes: 314115 339419 339566 346654 348216 358921
Changes:
d4x (2.5.7.1-1) unstable; urgency=low
.
* New upstream release (Closes: #358921, #339419, #339566, #346654, #348216)
* Depended on libboost-dev
* Added patch for German translation (Closes: #314115)
Files:
f4801b8b923947
070f2f6c2182f2
1e8dd01f40299f
74820e9041cb2b
cd015bf1ac83a4
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
iQEVAwUBRF5scMS
nz/cFfoH1hOuUtM
hvA6P3enKxkGxg/
rXVCVtGCqrRcLQG
0TNwNhwm8qawzzK
SBlx0KT1RsCyVY6
=QxJZ
-----END PGP SIGNATURE-----
Hi,
From: Max <email address hidden>
Subject: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
Date: Tue, 15 Nov 2005 22:15:11 -0800
> Package: d4x /e/edbf5d055412 df097e9ab4a16a8 86361/AB_ 091__E_ .part05. rar www.filefactory .com/get/ f.php?f= 26f737dbc373854 c4a38ac77 in a browser,
> Version: 2.5.6-2
> Severity: grave
> Justification: renders package unusable
>
> d4x on attempt to process a link like
> ftp://a5:<email address hidden>
>
> Please note that this particular link is already expired (i.e., login is incorrect and d4x survives).
> To get a fresh one, open http://
> wait 15 sec, click "Click here to continue to the download page.", wait another 15 sec and
> find the link under "FileFactory FTP -- Click here to download".
>
I can't reproduce it, as it is said "No such file or directory." Can you check
the link?
Cai Qian