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> > ([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
