Description of problem: In order to release a new version of FMSLogo, I upload the manual via FTP to web.sourceforge.net. This involves uploading many small files in two directories with FTP. While waiting for one directory to finish uploading, I want to change to the next directory to queue the second batch of files to upload. However, if I try to change the directory on the remote machine while the files are uploading, gftp crashes. Version-Release number of selected component (if applicable): According to "rpm -q gftp": gftp-2.0.19-27.fc35.x86_64 How reproducible: Every Time Steps to Reproduce: 1. Start gftp 2. Connect to a remote server. In my case, it's web.sourceforge.net. 3. Select several files on the local machine 4. Click the button with the right arrow to upload them. 5. Select "Overwrite" in the "Transfer Files" dialog that appears. 6. Click "OK". This starts the upload of many files. The FTP log at the bottom shows progress. 7. While the files are uploading, change the directory on the right side (the remote machine) Note: I have only tried this on web.sourceforge.net because that's the only FTP server which I can upload to. Actual results: gftp crashes Expected results: Either the directory navigation control is disabled, I get a message saying that I cannot change remote directories while uploading, or it changes directory on the remote machine. What ever the behavior is, I expect the files that I had queued for upload continue to upload and that gftp does not crash. Additional info: I am not familiar with the source code, but from gdb it looks like the request object is still nulled out in `list_doaction`, which causes `gftp_build_path` to return a NULL directory, causing a deference of NULL directory name in `gftp_expand_path`. Here's the stack trace of the crash: (gdb) bt #0 0x000055555557d2c7 in gftp_expand_path (request=0x555555793550, src=<optimized out>) at ../../lib/misc.c:149 #1 0x000055555556c099 in gftpui_run_chdir (uidata=0x5555555ab0a0 <window2>, directory=<optimized out>) at /usr/src/debug/gftp-2.0.19-27.fc35.x86_64/src/gtk/gtkui.c:421 #2 0x000055555556c21a in list_doaction (wdata=0x5555555ab0a0 <window2>) at /usr/src/debug/gftp-2.0.19-27.fc35.x86_64/src/gtk/gftp-gtk.c:685 Python Exception <class 'gdb.error'>: value has been optimized out I think that "str" is NULL in `gftp_expand_path` because the instruction pointer is set to dereference %rax, which is 0. (gdb) f 0 #0 0x000055555557d2c7 in gftp_expand_path (request=0x555555793550, src=<optimized out>) at ../../lib/misc.c:149 149 if (*str == '~') gdb) info registers rax 0x0 0 rbx 0x5555555ab0a0 93824992587936 rcx 0x7fffd4000048 140736750157896 rdx 0x7fffd40020d0 140736750166224 rsi 0x0 0 rdi 0x0 0 rbp 0x5555555ab0a0 0x5555555ab0a0 <window2> rsp 0x7fffffffcb40 0x7fffffffcb40 r8 0x7fffd401e7f0 140736750282736 r9 0x7ffff78254e0 140737345901792 r10 0x7ffff78253e0 140737345901536 r11 0xd65f06c28cdbc9ff -2999671394148824577 r12 0x0 0 r13 0x0 0 r14 0x7fffffffcd20 140737488342304 r15 0x55555579ba50 93824994622032 rip 0x55555557d2c7 0x55555557d2c7 <gftp_expand_path+39> eflags 0x10246 [ PF ZF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 Disassemble the location of %rip (gdb) disassemble 0x55555557d2c7 Dump of assembler code for function gftp_expand_path: 0x000055555557d2a0 <+0>: endbr64 0x000055555557d2a4 <+4>: push %r15 0x000055555557d2a6 <+6>: push %r14 0x000055555557d2a8 <+8>: push %r13 0x000055555557d2aa <+10>: push %r12 0x000055555557d2ac <+12>: push %rbp 0x000055555557d2ad <+13>: push %rbx 0x000055555557d2ae <+14>: sub $0x18,%rsp 0x000055555557d2b2 <+18>: mov %rdi,0x8(%rsp) 0x000055555557d2b7 <+23>: mov %rsi,%rdi 0x000055555557d2ba <+26>: call 0x555555562060 <g_strdup@plt> 0x000055555557d2bf <+31>: movq $0x0,(%rsp) => 0x000055555557d2c7 <+39>: cmpb $0x7e,(%rax) 0x000055555557d2ca <+42>: mov %rax,%r13 0x000055555557d2cd <+45>: je 0x55555557d4cb <gftp_expand_path+555> 0x000055555557d2d3 <+51>: mov %r13,%r12 0x000055555557d2d6 <+54>: xor %ebp,%ebp 0x000055555557d2d8 <+56>: nopl 0x0(%rax,%rax,1) 0x000055555557d2e0 <+64>: mov $0x2f,%esi 0x000055555557d2e5 <+69>: mov %r12,%rdi 0x000055555557d2e8 <+72>: call 0x555555561c00 <strchr@plt> 0x000055555557d2ed <+77>: mov %rax,%r15 0x000055555557d2f0 <+80>: test %rax,%rax 0x000055555557d2f3 <+83>: je 0x55555557d47c <gftp_expand_path+476> 0x000055555557d2f9 <+89>: lea 0x1(%r15),%r12 0x000055555557d2fd <+93>: cmpb $0x2f,0x1(%r15) 0x000055555557d302 <+98>: mov %r12,%rbx 0x000055555557d305 <+101>: jne 0x55555557d319 <gftp_expand_path+121> 0x000055555557d307 <+103>: nopw 0x0(%rax,%rax,1) 0x000055555557d310 <+112>: add $0x1,%rbx 0x000055555557d314 <+116>: cmpb $0x2f,(%rbx) 0x000055555557d317 <+119>: je 0x55555557d310 <gftp_expand_path+112> 0x000055555557d319 <+121>: mov $0x2f,%esi 0x000055555557d31e <+126>: mov %rbx,%rdi 0x000055555557d321 <+129>: call 0x555555561c00 <strchr@plt> 0x000055555557d326 <+134>: mov %rax,%r14 Also, a little up the call stack, directory is NULL: (gdb) f 2 #2 0x000055555556c21a in list_doaction (wdata=0x5555555ab0a0 <window2>) at /usr/src/debug/gftp-2.0.19-27.fc35.x86_64/src/gtk/gftp-gtk.c:685 685 success = gftpui_run_chdir (wdata, directory); (gdb) p directory $9 = 0x0 And where did "directory" come from? From what gftp_build_path returns when wdata->request->directory. (gdb) l 680 681 if (S_ISLNK (tempfle->st_mode) || S_ISDIR (tempfle->st_mode)) 682 { 683 directory = gftp_build_path (wdata->request, wdata->request->directory, 684 tempfle->file, NULL); 685 success = gftpui_run_chdir (wdata, directory); 686 g_free (directory); 687 } 688 else 689 success = 0; (gdb) p wdata->request->directory $10 = 0x0 Here's the rest of the request. (gdb) p *wdata->request $14 = { protonum = 0, hostname = 0x0, username = 0x0, password = 0x0, account = 0x0, directory = 0x0, url_prefix = 0x0, last_ftp_response = 0x0, last_dir_entry = 0x0, last_dir_entry_len = 0, port = 0, datafd = -1, cachefd = -1, wakeup_main_thread = {0, 0}, remote_addr = 0x0, remote_addr_len = 0, ai_family = 0, server_type = 7, use_proxy = 0, always_connected = 0, need_hostport = 0, need_username = 0, need_password = 0, use_cache = 0, cached = 0, cancel = 0, stopable = 0, refreshing = 0, use_local_encoding = 0, gotbytes = 0, protocol_data = 0x0, logging_function = 0x555555577240 <ftp_log>, user_data = 0x0, init = 0x0, copy_param_options = 0x0, read_function = 0x0, --Type <RET> for more, q to quit, c to continue without paging-- write_function = 0x0, destroy = 0x0, connect = 0x0, post_connect = 0x0, disconnect = 0x0, get_file = 0x0, put_file = 0x0, transfer_file = 0x0, get_next_file_chunk = 0x0, put_next_file_chunk = 0x0, end_transfer = 0x0, abort_transfer = 0x0, stat_filename = 0x0, list_files = 0x0, get_next_file = 0x0, get_next_dirlist_line = 0x0, get_file_size = 0x0, chdir = 0x0, rmdir = 0x0, rmfile = 0x0, mkdir = 0x0, rename = 0x0, chmod = 0x0, set_file_time = 0x0, site = 0x0, parse_url = 0x0, set_config_options = 0x0, swap_socks = 0x0, local_options_vars = 0x0, num_local_options_vars = 0, local_options_hash = 0x0, iconv_to = 0x0, iconv_from = 0x0, iconv_from_initialized = 0, iconv_to_initialized = 0, iconv_charset = 0x0 }
The new version fixes this, update coming.
FEDORA-2022-e0c4dcb919 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-e0c4dcb919
FEDORA-2022-e0c4dcb919 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-e0c4dcb919` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e0c4dcb919 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-bce3206004 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-bce3206004` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-bce3206004 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-bce3206004 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-e0c4dcb919 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.