d4x crashes in strlen () from /lib64/libc.so.6

Bug #25941 reported by Debian Bug Importer
8
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://bugs.debian.org/339419

Revision history for this message
In , Cai Qian (caiqian-debian) wrote : 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>/e/edbf5d055412df097e9ab4a16a886361/AB_091__E_.part05.rar
>
> Please note that this particular link is already expired (i.e., login is incorrect and d4x survives).
> To get a fresh one, open http://www.filefactory.com/get/f.php?f=26f737dbc373854c4a38ac77 in a browser,
> 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

Revision history for this message
In , Relf (relf) wrote :

Cai Qian wrote:

>> d4x on attempt to process a link like
>> ftp://a5:<email address hidden>/e/edbf5d055412df097e9ab4a16a886361/AB_091__E_.part05.rar
>>
>> Please note that this particular link is already expired (i.e., login is incorrect and d4x survives).
>> To get a fresh one, open http://www.filefactory.com/get/f.php?f=26f737dbc373854c4a38ac77 in a browser,
>> 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://www.filefactory.com/get/f.php?f=26f737dbc373854c4a38ac77 in a browser
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

Revision history for this message
In , Cai Qian (caiqian-debian) wrote :

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://www.filefactory.com/get/f.php?f=26f737dbc373854c4a38ac77 in a browser
> 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/edbf5d055412df097e9ab4a16a886361/AB_091__E_.part05.rar: No such file or
directory

Cai Qian

Revision history for this message
In , Relf (relf) wrote :

Cai Qian wrote:
>> To reproduce:
>> 1) open http://www.filefactory.com/get/f.php?f=26f737dbc373854c4a38ac77 in a browser
>> 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/edbf5d055412df097e9ab4a16a886361/AB_091__E_.part05.rar: No such file or
> directory

Please try to start with any of the following links at step 1:
http://www.filefactory.com/get/f.php?f=13ae545bc91cef4450ba91f2
http://www.filefactory.com/get/f.php?f=f23250cb8433a7c926f77f60
http://www.filefactory.com/get/f.php?f=999bcdfcfe535630094778a2

Max

Revision history for this message
In , Cai Qian (caiqian-debian) wrote : d4x

forworded 339419 Maxim Koshelev
tags 339419 confirmed

Revision history for this message
In , Cai Qian (caiqian-debian) wrote :

forwarded 339419 Maxim Koshelev

Revision history for this message
In , Cai Qian (caiqian-debian) wrote :

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Automatically imported from Debian bug report #339419 http://bugs.debian.org/339419

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (3.6 KiB)

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>/e/edbf5d055412df097e9ab4a16a886361/AB_091__E_.part05.rar

Please note that this particular link is already expired (i.e., login is incorrect and d4x survives).
To get a fresh one, open http://www.filefactory.com/get/f.php?f=26f737dbc373854c4a38ac77 in a browser,
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::compare () from /usr/lib/libstdc++.so.6
#2 0x0000000000455f2d in std::operator+<char, std::char_traits<char>, std::allocator<char> > ()
#3 0x0000000000438e84 in std::operator+<char, std::char_traits<char>, std::allocator<char> > ()
#4 0x000000000043af15 in std::operator+<char, std::char_traits<char>, std::allocator<char> > ()
#5 0x00002aaaaabc9b1c in start_thread () from /lib64/libpthread.so.0
#6 0x00002aaaac93d3e2 in clone () from /lib64/libc.so.6
#7 0x0000000000000000 in ?? ()
....

At the end of strace log I see

[pid 4293] rt_sigprocmask(SIG_BLOCK, [USR1], [INT USR2 TERM], 8) = 0
[pid 4293] rt_sigprocmask(SIG_UNBLOCK, [USR1], [INT USR1 USR2 TERM], 8) = 0
[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(SIG_BLOCK, [USR1], [INT USR2 TERM], 8) = 0
[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-unsupported')
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=ru_RU.KOI8-R (charmap=KOI8-R)

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

Read more...

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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>/e/edbf5d055412df097e9ab4a16a886361/AB_091__E_.part05.rar
>
> Please note that this particular link is already expired (i.e., login is incorrect and d4x survives).
> To get a fresh one, open http://www.filefactory.com/get/f.php?f=26f737dbc373854c4a38ac77 in a browser,
> 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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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>/e/edbf5d055412df097e9ab4a16a886361/AB_091__E_.part05.rar
>>
>> Please note that this particular link is already expired (i.e., login is incorrect and d4x survives).
>> To get a fresh one, open http://www.filefactory.com/get/f.php?f=26f737dbc373854c4a38ac77 in a browser,
>> 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://www.filefactory.com/get/f.php?f=26f737dbc373854c4a38ac77 in a browser
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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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://www.filefactory.com/get/f.php?f=26f737dbc373854c4a38ac77 in a browser
> 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/edbf5d055412df097e9ab4a16a886361/AB_091__E_.part05.rar: No such file or
directory

Cai Qian

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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://www.filefactory.com/get/f.php?f=26f737dbc373854c4a38ac77 in a browser
>> 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/edbf5d055412df097e9ab4a16a886361/AB_091__E_.part05.rar: No such file or
> directory

Please try to start with any of the following links at step 1:
http://www.filefactory.com/get/f.php?f=13ae545bc91cef4450ba91f2
http://www.filefactory.com/get/f.php?f=f23250cb8433a7c926f77f60
http://www.filefactory.com/get/f.php?f=999bcdfcfe535630094778a2

Max

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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

Revision history for this message
In , Relf (relf) wrote :

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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

Revision history for this message
In , Cai Qian (caiqian-debian) wrote :

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://packages.debian.org/experimental/libs/libgtk2.0-0

Cai Qian

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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://packages.debian.org/experimental/libs/libgtk2.0-0

Cai Qian

Revision history for this message
Sebastien Bacher (seb128) wrote :

not a GTK bug

Revision history for this message
In , Steve Langasek (vorlon) wrote : Re: d4x crashes in strlen() from lib64/libc.so.6

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://www.debian.org/

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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://www.debian.org/

--3siQDZowHQqNOShm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFDqPEbKN6ufymYLloRAu6qAKC/hH8oixpGOafH1mrn9U1V/7M4RgCfb+Tv
Nt3ln+qtYWffKfLWUe4cdCQ=
=5XHw
-----END PGP SIGNATURE-----

--3siQDZowHQqNOShm--

Revision history for this message
In , Sebastien Bacher (seb128) wrote : Re: Bug#339419: d4x crashes in strlen() from lib64/libc.so.6

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <1135157503.8620.2.camel@localhost>
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

Revision history for this message
In , Loïc Minier (lool) wrote :

        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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 21 Dec 2005 11:35:13 +0100
From: =?iso-8859-1?Q?Lo=EFc?= Minier <email address hidden>
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

Revision history for this message
In , Relf (relf) wrote :
Download full text (3.7 KiB)

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_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
   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::compare () from /usr/lib/libstdc++.so.6
#2 0x0000000000455f2d in std::operator+<char, std::char_traits<char>, std::allocator<char> > ()
#3 0x0000000000438e84 in std::operator+<char, std::char_traits<char>, std::allocator<char> > ()
#4 0x000000000043af15 in std::operator+<char, std::char_traits<char>, std::allocator<char> > ()
#5 0x00002aaaaabc9b1c in start_thread () from /lib64/libpthread.so.0
#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+<char, std::char_traits<char>, std::allocator<char> > ()
#2 0x000000000044e12a in std::operator+<char, std::char_traits<char>, std::allocator<char> > ()
#3 0x00002aaaaabc9b1c in start_thread () from /lib64/libpthread.so.0
#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_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
(gdb) bt
#0 0x00002aaaaabcbb6a in pthread_cond_wait@@GLIBC_2.3.2 ()
    from /lib64/libpthread.so.0
#1 0x0000000000430afb in std::operator+<char, std::char_traits<char>, std::allocator<char> > ()
#2 0x0000000000430c93 in std::operator+<char, std::char_traits<char>, std::allocator<char> > ()
#3 0x00002aaaaabc9b1c in start_thread () from /lib64/libpthread.so.0
#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_context_iterate (context=0x6729f0, block=1,
     dispatch=1, self=<v...

Read more...

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (4.0 KiB)

Message-ID: <email address hidden>
Date: Wed, 21 Dec 2005 03:37:04 -0800
From: Max Alekseyev <email address hidden>
To: =?ISO-8859-1?Q?Lo=EFc_Minier?= <email address hidden>
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/libpthread.so.0
   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::compare () from /usr/lib/libstdc++=
.so.6
#2 0x0000000000455f2d in std::operator+<char, std::char_traits<char>, st=
d::allocator<char> > ()
#3 0x0000000000438e84 in std::operator+<char, std::char_traits<char>, st=
d::allocator<char> > ()
#4 0x000000000043af15 in std::operator+<char, std::char_traits<char>, st=
d::allocator<char> > ()
#5 0x00002aaaaabc9b1c in start_thread () from /lib64/libpthread.so.0
#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+<char, std::char_traits<char>, st=
d::allocator<char> > ()
#2 0x000000000044e12a in std::operator+<char, std::char_traits<char>, st=
d::allocator<char> > ()
#3 0x00002aaaaabc9b1c in start_thread () from /lib64/libpthread.so.0
#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_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
(gdb) bt
#0 0x00002aaaaabcbb6a in pthread_cond_wait@@GLIBC_2.3.2 ()
    from /lib64/libpthread.so.0
#1 0x0000000000430afb in std::operator+<char, std::char_traits<char>, st=
d::allocator<char> > ()
#2 0x0000000000430c93 in std::operator+<char, std::char_traits<char>, st=
d::allocator<char> > ()
#3 0x00002aaaaabc9b1c in start_thread () from /lib64/libpthread.so.0
#4 0x00002aaaac959c22 in clone () from /lib64/libc.so.6
#5 0x0000000000000000 in...

Read more...

Revision history for this message
In , Loïc Minier (lool) wrote :

        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_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0

 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::compare () from
> /usr/lib/libstdc++.so.6

 This function probably only relayed the string to strlen().

> #2 0x0000000000455f2d in std::operator+<char, std::char_traits<char>,
> std::allocator<char> > ()
> #3 0x0000000000438e84 in std::operator+<char, std::char_traits<char>,
> std::allocator<char> > ()
> #4 0x000000000043af15 in std::operator+<char, std::char_traits<char>,
> std::allocator<char> > ()
> #5 0x00002aaaaabc9b1c in start_thread () from /lib64/libpthread.so.0
> #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://wiki.debian.org/HowToGetABacktrace>, that would confuse gdb
 less I suppose.

   Thanks,
--
Loïc Minier <email address hidden>

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 21 Dec 2005 13:58:13 +0100
From: =?iso-8859-1?Q?Lo=EFc?= Minier <email address hidden>
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_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0

 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::compare () from=20
> /usr/lib/libstdc++.so.6

 This function probably only relayed the string to strlen().

> #2 0x0000000000455f2d in std::operator+<char, std::char_traits<char>,=20
> std::allocator<char> > ()
> #3 0x0000000000438e84 in std::operator+<char, std::char_traits<char>,=20
> std::allocator<char> > ()
> #4 0x000000000043af15 in std::operator+<char, std::char_traits<char>,=20
> std::allocator<char> > ()
> #5 0x00002aaaaabc9b1c in start_thread () from /lib64/libpthread.so.0
> #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://wiki.debian.org/HowToGetABacktrace>, that would confuse gdb
 less I suppose.

   Thanks,
--=20
Lo=EFc Minier <email address hidden>

Revision history for this message
In , Steve Langasek (vorlon) wrote : Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6

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::compare () from
> > /usr/lib/libstdc++.so.6

> This function probably only relayed the string to strlen().

> > #2 0x0000000000455f2d in std::operator+<char, std::char_traits<char>,
> > std::allocator<char> > ()
> > #3 0x0000000000438e84 in std::operator+<char, std::char_traits<char>,
> > std::allocator<char> > ()
> > #4 0x000000000043af15 in std::operator+<char, std::char_traits<char>,
> > std::allocator<char> > ()
> > #5 0x00002aaaaabc9b1c in start_thread () from /lib64/libpthread.so.0
> > #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://wiki.debian.org/HowToGetABacktrace>, that would confuse gdb
> 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://www.debian.org/

Revision history for this message
In , Loïc Minier (lool) 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.

 What do you suggest?

--
Loïc Minier <email address hidden>
Current Earth status: NOT DESTROYED

Revision history for this message
In , Steve Langasek (vorlon) wrote :

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://www.debian.org/

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 21 Dec 2005 10:53:06 -0800
From: Steve Langasek <email address hidden>
To: =?iso-8859-1?Q?Lo=EFc?= Minier <email address hidden>,
 <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-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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::compare () from=20
> > /usr/lib/libstdc++.so.6

> This function probably only relayed the string to strlen().

> > #2 0x0000000000455f2d in std::operator+<char, std::char_traits<char>,=
=20
> > std::allocator<char> > ()
> > #3 0x0000000000438e84 in std::operator+<char, std::char_traits<char>,=
=20
> > std::allocator<char> > ()
> > #4 0x000000000043af15 in std::operator+<char, std::char_traits<char>,=
=20
> > std::allocator<char> > ()
> > #5 0x00002aaaaabc9b1c in start_thread () from /lib64/libpthread.so.0
> > #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://wiki.debian.org/HowToGetABacktrace>, that would confuse gdb
> 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://www.debian.org/

--Qz2CZ664xQdCRdPu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFDqaSSKN6ufymYLloRAsQ+AJ44gk/CU92N5cRgKa1ld2HVz87r8wCg0hhq
0BBYaWjGms9EkVk128iCTLA=
=tJ26
-----END PGP SIGNATURE-----

--Qz2CZ664xQdCRdPu--

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 21 Dec 2005 19:59:06 +0100
From: =?iso-8859-1?Q?Lo=EFc?= Minier <email address hidden>
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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 21 Dec 2005 11:14:28 -0800
From: Steve Langasek <email address hidden>
To: =?iso-8859-1?Q?Lo=EFc?= Minier <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

--UTZ8bGhNySVQ9LYl
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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://www.debian.org/

--UTZ8bGhNySVQ9LYl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFDqamUKN6ufymYLloRAtK7AJ9TWLZ+VRQnr7za38xiX6cjQOVeVQCgheM0
3TS9U5XofcAX2SEUpEAk3/o=
=i/hp
-----END PGP SIGNATURE-----

--UTZ8bGhNySVQ9LYl--

Revision history for this message
In , Relf (relf) wrote :
Download full text (60.1 KiB)

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-3.0.1-Debian, a dynamic binary instrumentation framework.
==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_function (nsswitch.c:344)
==31813== by 0x139DAD53: __nss_lookup (nsswitch.c:150)
==31813== by 0x1399148B: getpwuid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:171)
==31813== by 0x11D96F40: (within /usr/lib/libglib-2.0.so.0.800.4)
==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_function (nsswitch.c:344)
==31813== by 0x139DAD53: __nss_lookup (nsswitch.c:150)
==31813== by 0x1399148B: getpwuid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:171)
==31813== by 0x11D96F40: (within /usr/lib/libglib-2.0.so.0.800.4)
==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_function (nsswitch.c:344)
==31813== by 0x139DAD53: __nss_lookup (nsswitch.c:150)
==31813== by 0x1399148B: getpwuid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:171)
==31813== by 0x11D96F40: (within /usr/lib/libglib-2.0.so.0.800.4)
==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: (...

Revision history for this message
In , Steve Langasek (vorlon) wrote :

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://www.debian.org/

Revision history for this message
In , Relf (relf) 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.

> 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

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (6.0 KiB)

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-1?Q?Lo=EFc?= 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

--/WwmFnJnmDyWGHa4
Content-Type: multipart/mixed; boundary="J2SCkAp4GZ/dPZZf"
Content-Disposition: inline

--J2SCkAp4GZ/dPZZf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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

--=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://www.debian.org/

--J2SCkAp4GZ/dPZZf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="d4x-339419.diff"
Content-Transfer-Encoding: quoted-printable

diff -u d4x-2.5.6/debian/changelog d4x-2.5.6/debian/changelog
--- d4x-2.5.6/debian/changelog
+++ d4x-2.5.6/debian/changelog
@@ -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.6.orig/main/face/fsched.h
+++ d4x-2.5.6/main/face/fsched.h
@@ -43,7 +43,7 @@
=20
=20
 GtkWidget *my_gtk_aeditor_new(d4xSchedAction *action=3D(d4xSchedAction *)N=
ULL);
-guint my_gtk_aeditor_get_type();
+GtkType my_gtk_aeditor_get_type();
=20
 GtkWidget *d4x_scheduler_init();
 void d4x_scheduler_insert(d4xSchedAction *act,d4xSchedAction *prev);
only in patch2:
unchanged:
--- d4x-2.5.6.orig/main/face/fsched.cc
+++ d4x-2.5.6/main/face/fsched.cc
@@ -813,8 +813,8 @@
=20
 };
=20
-guint my_gtk_aeditor_get_type(){
- static guint my_aeditor_type=3D0;
+GtkType my_gtk_aeditor_get_type(){
+ static GtkType my_aeditor_type=3D0;
  if (!my_aeditor_type){
   GTypeInfo my_aeditor_info=3D{
    sizeof(MyGtkAEditorClass),
only in patch2:
unchanged:
--- d4x-2.5.6.orig/main/face/mywidget.cc
+++ d4x-2.5.6/main/face/mywidget.cc
@@ -117,8 +117,8 @@
  ...

Read more...

Revision history for this message
In , Steve Langasek (vorlon) wrote :

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://www.debian.org/

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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-R?Q?Loi=22c_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

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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-1?Q?Lo=EFc?= 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

--XWOWbaMNXpFDWE00
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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://www.debian.org/

--XWOWbaMNXpFDWE00
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFDqjAzKN6ufymYLloRAj2sAKCmMWQKoBu59sck5c50bjnTy2t+RACfSaWY
PJw2J7Gv1BCIPZzs/i8ZqmM=
=rRBm
-----END PGP SIGNATURE-----

--XWOWbaMNXpFDWE00--

Revision history for this message
In , Relf (relf) 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.

Max

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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-R?Q?Loi=22c_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

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

Revision history for this message
In , Steve Langasek (vorlon) wrote :

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://www.debian.org/

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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>"@murphy.debian.org
Subject: Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6

--YToU2i3Vx8H2dn7O
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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://www.debian.org/

--YToU2i3Vx8H2dn7O
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFDrnX6KN6ufymYLloRAkQZAKCNPW8Y9lGmmi+khWYtv4sXWiBSLwCfXos8
lD6iDAO+Rkdn7stR0hiSx2I=
=DGBs
-----END PGP SIGNATURE-----

--YToU2i3Vx8H2dn7O--

Revision history for this message
In , Cai Qian (caiqian-debian) wrote :

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (9.2 KiB)

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-1?Q?Lo=EFc?= Minier <email address hidden>, <email address hidden>
Subject: Re: d4x crashes in strlen () from /lib64/libc.so.6

----Next_Part(Sat_Dec_31_20_01_03_2005_994)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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_Part(Sat_Dec_31_20_01_03_2005_994)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="339419.bt"

Starting program: /home/caiqian/packages/d4x-2.5.6/main/nt -w ftp://a7:<email address hidden>/b/ba9a70b8155812b821aaf1825d4fb420/AB_091__E_.part09.rar
[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/debug/libc.so.6
Current language: auto; currently c
(gdb) bt
#0 0x407e0413 in strlen () from /usr/lib/debug/libc.so.6
#1 0x406f5a2f in std::string::compare () from /usr/lib/libstdc++.so.6
#2 0x080577a0 in std::operator==<char, std::char_traits<char>, std::allocator<char> > (__lhs=@0x819f00c, __rhs=0x0)
    at basic_string.h:2158
#3 0x080a8f09 in tFtpDownload::get_size (this=0x819ef38) at ftpd.cc:487
#4 0x080850d3 in tDownload::download_ftp (this=0x819e640) at dlist.cc:1630
#5 0x0808a412 in download_last (nothing=0x819e640) at main.cc:1867
#6 0x4001df4c in pthread_start_thread (arg=0xbf5ffbe0) at manager.c:310
#7 0x4001dfda in pthread_start_thread_event (arg=0xbf5ffbe0) at manager.c:334
#8 0x4083298a in clone () from /usr/lib/debug/libc.so.6
(gdb) thread apply all bt full

Thread 5 (Thread 49156 (LWP 2339)):
#0 0x4082bc81 in select () from /usr/lib/debug/libc.so.6
No locals.
#1 0x40027ff4 in ?? () from /usr/lib/debug/libpthread.so.0
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/debug/libc.so.6
 malloc_trace_buffer = 0x0
 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_memalign_hook = (void *(*)(size_t, size_t, const void *)) 0
 mallenv = "M...

Read more...

Revision history for this message
In , Steve Langasek (vorlon) wrote :

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/debug/libc.so.6
> Current language: auto; currently c
> (gdb) bt
> #0 0x407e0413 in strlen () from /usr/lib/debug/libc.so.6
> #1 0x406f5a2f in std::string::compare () from /usr/lib/libstdc++.so.6
> #2 0x080577a0 in std::operator==<char, std::char_traits<char>, std::allocator<char> > (__lhs=@0x819f00c, __rhs=0x0)
> at basic_string.h:2158
> #3 0x080a8f09 in tFtpDownload::get_size (this=0x819ef38) at ftpd.cc:487
> #4 0x080850d3 in tDownload::download_ftp (this=0x819e640) at dlist.cc:1630
> #5 0x0808a412 in download_last (nothing=0x819e640) at main.cc:1867
> #6 0x4001df4c in pthread_start_thread (arg=0xbf5ffbe0) at manager.c:310
> #7 0x4001dfda in pthread_start_thread_event (arg=0xbf5ffbe0) at manager.c:334
> #8 0x4083298a in clone () from /usr/lib/debug/libc.so.6
> (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::get_size is comparing
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::ftp_cut_string_list(), fwiw, but I haven't traced through it
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://www.debian.org/

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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-8859-1?Q?Lo=EFc?= Minier <email address hidden>
Subject: Re: Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6

--U+BazGySraz5kW0T
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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/debug/libc.so.6
> Current language: auto; currently c
> (gdb) bt
> #0 0x407e0413 in strlen () from /usr/lib/debug/libc.so.6
> #1 0x406f5a2f in std::string::compare () from /usr/lib/libstdc++.so.6
> #2 0x080577a0 in std::operator=3D=3D<char, std::char_traits<char>, std::=
allocator<char> > (__lhs=3D@0x819f00c, __rhs=3D0x0)
> at basic_string.h:2158
> #3 0x080a8f09 in tFtpDownload::get_size (this=3D0x819ef38) at ftpd.cc:487
> #4 0x080850d3 in tDownload::download_ftp (this=3D0x819e640) at dlist.cc:=
1630
> #5 0x0808a412 in download_last (nothing=3D0x819e640) at main.cc:1867
> #6 0x4001df4c in pthread_start_thread (arg=3D0xbf5ffbe0) at manager.c:310
> #7 0x4001dfda in pthread_start_thread_event (arg=3D0xbf5ffbe0) at manage=
r.c:334
> #8 0x4083298a in clone () from /usr/lib/debug/libc.so.6
> (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::get_size is comparing
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::ftp_cut_string_list(), fwiw, but I haven't traced through it
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://www.debian.org/

--U+BazGySraz5kW0T
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFDtzOAKN6ufymYLloRAh2qAJ0SLNri746387gBYF3wCHt/BKINtgCbB/nw
sglV2IlXIJtSmGyeo073PMw=
=fB1k
-----END PGP SIGNATURE-----

--U+BazGySraz5kW0T--

Revision history for this message
In , Loïc Minier (lool) wrote : reassign 339419 to d4x

# Automatically generated email from bts, devscripts version 2.9.10
reassign 339419 d4x

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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

Revision history for this message
In , Cai Qian (caiqian-debian) wrote :

tags 339419 fixed-upstream

Revision history for this message
In , Cai Qian (caiqian-debian) wrote : Bug#339419: fixed in d4x 2.5.7.1-1

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_2.5.7.1-1_all.deb
  to pool/main/d/d4x/d4x-common_2.5.7.1-1_all.deb
d4x_2.5.7.1-1.diff.gz
  to pool/main/d/d4x/d4x_2.5.7.1-1.diff.gz
d4x_2.5.7.1-1.dsc
  to pool/main/d/d4x/d4x_2.5.7.1-1.dsc
d4x_2.5.7.1-1_i386.deb
  to pool/main/d/d4x/d4x_2.5.7.1-1_i386.deb
d4x_2.5.7.1.orig.tar.gz
  to pool/main/d/d4x/d4x_2.5.7.1.orig.tar.gz

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:
 f4801b8b923947569793b2669adc1307 988 net optional d4x_2.5.7.1-1.dsc
 070f2f6c2182f25204ea7356c8395ffe 2029713 net optional d4x_2.5.7.1.orig.tar.gz
 1e8dd01f40299f16dd3b0f06a52949e2 42434 net optional d4x_2.5.7.1-1.diff.gz
 74820e9041cb2b184cbf16b9d39328bf 673274 net optional d4x-common_2.5.7.1-1_all.deb
 cd015bf1ac83a418324468294bd46c9f 751442 net optional d4x_2.5.7.1-1_i386.deb

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

iQEVAwUBRF5scMSMJEo6oWZwAQK2uwgAizTHKZJeYCf7KhOZmpdp1JKWAuGKIVjz
nz/cFfoH1hOuUtMLm4YDAtta+YgOwGqJJn+JuzatU6xk7NrA+v9nTRi5JNLIaPk5
hvA6P3enKxkGxg/a/pq8CsskdiXi2vTY7fJfQVvU3M/HwmIb9KdlB4CVCIlHexEr
rXVCVtGCqrRcLQG8Vnz16DGd/jBgSPJw6k5IXvIYNZY5d7AkZKxK6UCnl+rwvz5M
0TNwNhwm8qawzzKN2iX1pMkjAcmzW7NW/gX8+no0cFaHjcOPu/nvv6DHjn2d0Coe
SBlx0KT1RsCyVY6Au9dALRED+J4LSn69/Jk3v7qHii2xW+88E0wkXA==
=QxJZ
-----END PGP SIGNATURE-----

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.