From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040510 Description of problem: First couple of runs gftp wouldn't connect. Tried several sites, including one that I opened in Moz via ftp. Third try it connected and allowed me to browse directories and select a file. When I clicked the button to download it threw a segmentation fault. Site being accessed when it segfaulted was updates.redhat.com. Repeated attempts produce reliable segfaults. Assuming it has to be x86_64 specific or it would be reported by now? Version-Release number of selected component (if applicable): gftp-2.0.17-2 How reproducible: Always Steps to Reproduce: 1. Launch gftp, pick updates.redhat.com 2. If it will connect, try to download something. 3. Boom. Additional info:
*** Bug 125629 has been marked as a duplicate of this bug. ***
We cannot possibly do anything without a backtrace. You must install the matching debuginfo RPM, and get a backtrace with gdb.
I'm also having this problem (FC3T1 x86-64 gftp-2.0.17-3), I downloaded the source RPM, compiled, installed and got the backtrace (past 3 all the trace data is unknown so it is left off): Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1084225888 (LWP 9495)] 0x0000000000439203 in gftpui_common_transfer_files (tdata=0x7f) at gftpui.c:1318 1318 tdata->tot_file_trans = gftp_transfer_file (tdata->fromreq, (gdb) bt #0 0x0000000000439203 in gftpui_common_transfer_files (tdata=0x7f) at gftpui.c:1318 #1 0x000000000041dd29 in _gftpui_transfer_files (data=0x786e40) at transfer.c:607 #2 0x0000003df7705d74 in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003df6ac2893 in thread_start () from /lib64/tls/libc.so.6
Created attachment 103472 [details] Changes to gftpui.c to cover over segfault I needed to get gftp working to get some things done so I dug in a little and covered over the problem (please note: this patch does not fix the problem, it covers it up). For some reason the gftp_transfer_file function is corrupting the tdata variable and any long stored with the same pointer value, this covers over the problem by storing the pointer value + 1 and retrieving it after gftp_transfer_file exists (there's also a minimal return check on gftp_transfer_file).
*** Bug 133283 has been marked as a duplicate of this bug. ***
I do not feel comfortable about accepting a patch that admittedly does not solve the actual problem. Please try to find a real solution. Ask for help on fedora-devel-list. It would help if you could have someone from gftp upstream OK the patch.
*** This bug has been marked as a duplicate of 140567 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.