Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
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
Starting program: /home/caiqian/packages/d4x-2.5.6/main/nt -w ftp://a7:[EMAIL
PROTECTED]/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_traitschar,
std::allocatorchar ([EMAIL PROTECTED], __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 0x 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 = MALLOC_TRACE
tr_old_realloc_hook = (void *(*)(void *, size_t, const void *)) 0
tr_old_malloc_hook = (void *(*)(size_t, const void *)) 0
mallwatch = (void *) 0x0
#1 0x406f5a2f in std::string::compare () from /usr/lib/libstdc++.so.6
No symbol table info available.
#2 0x080577a0 in std::operator==char, std::char_traitschar,
std::allocatorchar ([EMAIL PROTECTED], __rhs=0x0)
at basic_string.h:2158
No locals.
#3 0x080a8f09 in tFtpDownload::get_size (this=0x819ef38) at ftpd.cc:487
sz = 0
a = 0
#4 0x080850d3 in tDownload::download_ftp (this=0x819e640) at dlist.cc:1630
size = 578426686599592584
s = (class tSocket *) 0x0
CurentSize = 4612389654329556992
SIZE_FOR_DOWNLOAD = 135915072
#5 0x0808a412 in download_last (nothing=0x819e640) at main.cc:1867
addr = (d4x::URL *) 0x819e688
what = (class tDownload *) 0x819e640
#6 0x4001df4c in pthread_start_thread (arg=0xbf5ffbe0) at manager.c:310
request = {req_thread = 0x0, req_kind = REQ_CREATE, req_args = {create
= {attr = 0x0, fn = 0, arg = 0x0, mask = {
__val = {0 repeats 27 times, 1073884766, 1073885054, 0, 0, 0}}}, free
= {thread_id = 0}, exit = {code = 0},
post = 0x0, for_each = {fn = 0, arg = 0x0}}}
outcome = value optimized out
#7 0x4001dfda in pthread_start_thread_event (arg=0xbf5ffbe0) at manager.c:334
No locals.
#8 0x4083298a in clone () from /usr/lib/debug/libc.so.6
fstab_state = {fs_fp = 0x0, fs_buffer = 0x0, fs_mntres = {mnt_fsname =
0x0, mnt_dir = 0x0, mnt_type = 0x0,
mnt_opts = 0x0, mnt_freq = 0, mnt_passno = 0}, fs_ret = {fs_spec = 0x0,
fs_file = 0x0, fs_vfstype = 0x0,
fs_mntops = 0x0, fs_type = 0x0, fs_freq = 0, fs_passno = 0}}
__elf_set___libc_subfreeres_element_fstab_free__ = (const void *)
0x4086aa10
Thread 3 (Thread 16386 (LWP 2337)):
#0 0x40021184 in __pthread_sigsuspend (set=0x40027ff4) at
../linuxthreads/sysdeps/unix/sysv/linux/pt-sigsuspend.c:54
resultvar = 4294967292
#1 0x4001ff59 in __pthread_wait_for_restart_signal (self=0xbf7ffbe0) at
pthread.c:1216
mask = {__val = {18946, 0, 0, 0, 0, 0, 895, 18350080, 1081883292, 115,
135569684, 123, 8064, 65535, 0,
1073884350, 0, 0, 0, 1073844060, 1073905652, 135674016, 135674096,
3212835124, 1073871588, 135674032, 1073884766,
1083541168, 1073871278, 1, 0, 7}}
#2 0x4001d57c in __pthread_cond_wait (cond=0x81638f0, mutex=0x81638a0)
Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
On Sat, Dec 31, 2005 at 08:01:03PM +, 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_traitschar, std::allocatorchar ([EMAIL PROTECTED], __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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
Bug#339419: 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) 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 PROTECTED] Current Earth status: NOT DESTROYED
Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
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)] 0x2c900e60 in strlen () from /lib64/libc.so.6 (gdb) info threads * 4 Thread 1098918240 (LWP 23033) 0x2c900e60 in strlen () from /lib64/libc.so.6 3 Thread 1090525536 (LWP 23016) 0x2c9527b6 in select () from /lib64/libc.so.6 2 Thread 1082132832 (LWP 23015) 0x2abcbb6a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 1 Thread 46912547122192 (LWP 23012) 0x2c950870 in poll () from /lib64/libc.so.6 (gdb) bt #0 0x2c900e60 in strlen () from /lib64/libc.so.6 #1 0x2c49670a in std::string::compare () from /usr/lib/libstdc++.so.6 #2 0x00455f2d in std::operator+char, std::char_traitschar, std::allocatorchar () #3 0x00438e84 in std::operator+char, std::char_traitschar, std::allocatorchar () #4 0x0043af15 in std::operator+char, std::char_traitschar, std::allocatorchar () #5 0x2abc9b1c in start_thread () from /lib64/libpthread.so.0 #6 0x2c959c22 in clone () from /lib64/libc.so.6 #7 0x in ?? () (gdb) thread 3 [Switching to thread 3 (Thread 1090525536 (LWP 23016))]#0 0x2c9527b6 in select () from /lib64/libc.so.6 (gdb) bt #0 0x2c9527b6 in select () from /lib64/libc.so.6 #1 0x0044df42 in std::operator+char, std::char_traitschar, std::allocatorchar () #2 0x0044e12a in std::operator+char, std::char_traitschar, std::allocatorchar () #3 0x2abc9b1c in start_thread () from /lib64/libpthread.so.0 #4 0x2c959c22 in clone () from /lib64/libc.so.6 #5 0x in ?? () (gdb) thread 2 [Switching to thread 2 (Thread 1082132832 (LWP 23015))]#0 0x2abcbb6a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 (gdb) bt #0 0x2abcbb6a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00430afb in std::operator+char, std::char_traitschar, std::allocatorchar () #2 0x00430c93 in std::operator+char, std::char_traitschar, std::allocatorchar () #3 0x2abc9b1c in start_thread () from /lib64/libpthread.so.0 #4 0x2c959c22 in clone () from /lib64/libc.so.6 #5 0x in ?? () (gdb) thread 1 [Switching to thread 1 (Thread 46912547122192 (LWP 23012))]#0 0x2c950870 in poll () from /lib64/libc.so.6 (gdb) bt #0 0x2c950870 in poll () from /lib64/libc.so.6 #1 0x2ad024c0 in g_main_context_iterate (context=0x6729f0, block=1, dispatch=1, self=value optimized out) at gmain.c:2867 #2 0x2ad0294a in IA__g_main_loop_run (loop=0x7dd930) at gmain.c:2769 #3 0x2af96ca2 in IA__gtk_main () at gtkmain.c:991 #4 0x00452f39 in std::operator+char, std::char_traitschar, std::allocatorchar () #5 0x2c8aa4ca in __libc_start_main () from /lib64/libc.so.6 #6 0x0041037a in ?? () #7 0x7fd86b88 in ?? () #8 0x2abc29c0 in ?? () from /lib64/ld-linux-x86-64.so.2 #9 0x0001 in ?? () #10 0x7fd88a74 in ?? () #11 0x in ?? () Max
Bug#339419: 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)] 0x2c900e60 in strlen () from /lib64/libc.so.6 The segfault happens in Thread 1098918240... (gdb) info threads * 4 Thread 1098918240 (LWP 23033) 0x2c900e60 in strlen () from /lib64/libc.so.6 ... which is thread 4. 3 Thread 1090525536 (LWP 23016) 0x2c9527b6 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) 0x2abcbb6a 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) 0x2c950870 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 0x2c900e60 in strlen () from /lib64/libc.so.6 The actual crash happens here, probably because a borken address was passed to strlen(). #1 0x2c49670a in std::string::compare () from /usr/lib/libstdc++.so.6 This function probably only relayed the string to strlen(). #2 0x00455f2d in std::operator+char, std::char_traitschar, std::allocatorchar () #3 0x00438e84 in std::operator+char, std::char_traitschar, std::allocatorchar () #4 0x0043af15 in std::operator+char, std::char_traitschar, std::allocatorchar () #5 0x2abc9b1c in start_thread () from /lib64/libpthread.so.0 #6 0x2c959c22 in clone () from /lib64/libc.so.6 #7 0x 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 PROTECTED]
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 0x2c900e60 in strlen () from /lib64/libc.so.6 The actual crash happens here, probably because a borken address was passed to strlen(). #1 0x2c49670a in std::string::compare () from /usr/lib/libstdc++.so.6 This function probably only relayed the string to strlen(). #2 0x00455f2d in std::operator+char, std::char_traitschar, std::allocatorchar () #3 0x00438e84 in std::operator+char, std::char_traitschar, std::allocatorchar () #4 0x0043af15 in std::operator+char, std::char_traitschar, std::allocatorchar () #5 0x2abc9b1c in start_thread () from /lib64/libpthread.so.0 #6 0x2c959c22 in clone () from /lib64/libc.so.6 #7 0x 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
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 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 PROTECTED] Current Earth status: NOT DESTROYED
Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
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 PROTECTED] http://www.debian.org/
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=low
+
+ * Non-maintainer upload.
+ * *GTKTYPE* *IS* *NOT* *AN* *INTEGER* *STOP* *BLOODY* *CASTING* *IT* *AS*
+*ONE*
+
+ -- Steve Langasek [EMAIL PROTECTED] Wed, 21 Dec 2005 16:06:21 -0800
+
d4x (2.5.6-2) unstable; urgency=low
* 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 @@
GtkWidget *my_gtk_aeditor_new(d4xSchedAction *action=(d4xSchedAction *)NULL);
-guint my_gtk_aeditor_get_type();
+GtkType my_gtk_aeditor_get_type();
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 @@
};
-guint my_gtk_aeditor_get_type(){
- static guint my_aeditor_type=0;
+GtkType my_gtk_aeditor_get_type(){
+ static GtkType my_aeditor_type=0;
if (!my_aeditor_type){
GTypeInfo my_aeditor_info={
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 @@
gtk_box_pack_start(GTK_BOX(filesel),button,FALSE,FALSE,0);
};
-guint my_gtk_filesel_get_type(){
- static guint my_filesel_type=0;
+GtkType my_gtk_filesel_get_type(){
+ static GtkType my_filesel_type=0;
if (!my_filesel_type){
GTypeInfo my_filesel_info={
sizeof(MyGtkFileselClass),
@@ -255,8 +255,8 @@
gtk_box_pack_start(GTK_BOX(colsel),button,FALSE,FALSE,0);
};
-guint my_gtk_colorsel_get_type(){
- static guint my_filesel_type=0;
+GtkType my_gtk_colorsel_get_type(){
+ static GtkType my_filesel_type=0;
if (!my_filesel_type){
GTypeInfo my_filesel_info={
sizeof(MyGtkColorselClass),
@@ -503,8 +503,8 @@
};
-guint d4x_rule_edit_get_type(){
- static guint d4x_rule_edit_type=0;
+GtkType d4x_rule_edit_get_type(){
+ static GtkType d4x_rule_edit_type=0;
if (!d4x_rule_edit_type){
GTypeInfo info={
sizeof(d4xRuleEditClass),
@@ -856,8 +856,8 @@
filter_parent_class=(GtkWidgetClass
*)gtk_type_class(gtk_window_get_type());
};
-guint d4x_filter_edit_get_type(){
- static guint d4x_filter_edit_type=0;
+GtkType d4x_filter_edit_get_type(){
+ static GtkType d4x_filter_edit_type=0;
if (!d4x_filter_edit_type){
GTypeInfo info={
sizeof(d4xFilterEditClass),
@@ -948,8 +948,8 @@
filtersel_parent_class=(GtkWidgetClass
*)gtk_type_class(gtk_window_get_type());
};
-guint d4x_filter_sel_get_type(){
- static guint d4x_filter_sel_type=0;
+GtkType d4x_filter_sel_get_type(){
+ static GtkType d4x_filter_sel_type=0;
if (!d4x_filter_sel_type){
GTypeInfo info={
sizeof(d4xFilterSelClass),
@@ -1125,8 +1125,8 @@
linkssel_parent_class=(GtkWidgetClass
*)gtk_type_class(gtk_window_get_type());
};
-guint d4x_links_sel_get_type(){
- static guint d4x_links_sel_type=0;
+GtkType d4x_links_sel_get_type(){
+ static GtkType d4x_links_sel_type=0;
if (!d4x_links_sel_type){
GTypeInfo info={
sizeof(d4xLinksSelClass),
@@ -1267,8 +1267,8 @@
gtk_window_set_default(GTK_WINDOW(sel),sel-cancel);
};
-guint d4x_string_edit_get_type(){
- static guint d4x_string_edit_type=0;
+GtkType d4x_string_edit_get_type(){
+ static GtkType d4x_string_edit_type=0;
if (!d4x_string_edit_type){
GTypeInfo info={
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#339419: 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
From: Max Alekseyev [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339419: 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339419: 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
Hi, From: Max [EMAIL PROTECTED] 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 PROTECTED]/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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 PROTECTED]/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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6
Hi, From: Max Alekseyev [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339419: 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
PROTECTED]/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 0x2c8e4a20 in strlen () from /lib64/libc.so.6
#1 0x2c47af6a in std::string::compare () from /usr/lib/libstdc++.so.6
#2 0x00455f2d in std::operator+char, std::char_traitschar,
std::allocatorchar ()
#3 0x00438e84 in std::operator+char, std::char_traitschar,
std::allocatorchar ()
#4 0x0043af15 in std::operator+char, std::char_traitschar,
std::allocatorchar ()
#5 0x2abc9b1c in start_thread () from /lib64/libpthread.so.0
#6 0x2c93d3e2 in clone () from /lib64/libc.so.6
#7 0x 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-1The ATK accessibility toolkit
ii libc62.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-1The GTK+ graphical user interface
ii libpango1.0-01.8.2-3 Layout and rendering of internatio
ii libssl0.9.8 0.9.8a-4SSL shared libraries
ii libstdc++6 4.0.2-3 The GNU Standard C++ Library v3
ii libx11-6 6.8.2.dfsg.1-10 X Window System protocol client li
ii xlibs6.8.2.dfsg.1-10 X Window System client libraries m
ii zlib1g 1:1.2.3-6 compression library - runtime
d4x recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
