Description of problem: Followed a thread on users list and simply tried to extract an arbitrary src.rpm file. Version-Release number of selected component: deco-1.6.2-4.fc18 Additional info: backtrace_rating: 4 cmdline: deco samefile-2.14-1.fc18.src.rpm crash_function: handle_contents executable: /usr/bin/deco kernel: 3.7.2-204.fc18.x86_64 remote_result: NOTFOUND uid: 1000 Truncated backtrace: Thread no. 1 (2 frames) #5 handle_contents at arch.c:199 #6 extract at arch.c:240
Created attachment 701159 [details] File: backtrace
Created attachment 701160 [details] File: build_ids
Created attachment 701161 [details] File: cgroup
Created attachment 701163 [details] File: core_backtrace
Created attachment 701165 [details] File: dso_list
Created attachment 701167 [details] File: environ
Created attachment 701169 [details] File: limits
Created attachment 701171 [details] File: maps
Created attachment 701172 [details] File: open_fds
Created attachment 701174 [details] File: proc_pid_status
Created attachment 701176 [details] File: var_log_messages
Hi Michael, thanks for the report. I tried a bunch of SRPM files (including samefile-2.13-2.fc18.src.rpm as I don't have the samefile-2.14-1.fc18.src.rpm) as well as other archive types but I cannot reproduce the crash. How reproducible is it for you? I looked at the code. I suspect that the boolean variable a->extr->subdir is set to true in the first pass of the while loop, which breaks the while loop, and the first.p does not get allocated as a result, and then freeing the not-allocated pointer first.p later causes the crash. But this is just my conjecture, and the backtrace is not very helpful. If you are able to reproduce, could you run this under gdb and see what is the source of the problem? Thanks.
Created attachment 701609 [details] proposed fix It's uninitialized ptrs in "struct path first" on the stack.
Yes but setting them to NULL will not allocate memory for these pointers. The line 199: free(first.p); would still crash. No? Do we need a protection if (first.p) before this line? Again thanks for your time!
free(NULL) is a no-op.
Oh nevermind. I will take your solution.
man 3 free: | | [...] If ptr is NULL, no operation is performed. Btw, if you submit this upstream, it could also become struct path first = { NULL, NULL, NULL }; of course, since "struct path" contains just those three pointers currently: # fs.h 8 struct path 9 { 10 char *p, *e, *z; 11 }; 12
Of course. I already submitted the patch, together with a link to this page.
deco-1.6.2-6.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/deco-1.6.2-6.fc17
deco-1.6.2-6.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/deco-1.6.2-6.fc18
Package deco-1.6.2-6.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing deco-1.6.2-6.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-2932/deco-1.6.2-6.fc17 then log in and leave karma (feedback).
deco-1.6.3-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
deco-1.6.3-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.