Bug 972339 - [abrt] PackageKit-command-not-found-0.8.9-1.fc19: pk_results_get_error_code: Process /usr/libexec/pk-command-not-found was killed by signal 11 (SIGSEGV)
Summary: [abrt] PackageKit-command-not-found-0.8.9-1.fc19: pk_results_get_error_code: ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: 19
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:34478e0d0a96e73dfe41f5e3b26...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-08 16:56 UTC by Scott Tsai
Modified: 2013-12-11 09:12 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-11 09:12:33 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: backtrace (12.79 KB, text/plain)
2013-06-08 16:56 UTC, Scott Tsai
no flags Details
File: cgroup (140 bytes, text/plain)
2013-06-08 16:56 UTC, Scott Tsai
no flags Details
File: core_backtrace (206 bytes, text/plain)
2013-06-08 16:56 UTC, Scott Tsai
no flags Details
File: dso_list (2.20 KB, text/plain)
2013-06-08 16:56 UTC, Scott Tsai
no flags Details
File: environ (3.89 KB, text/plain)
2013-06-08 16:56 UTC, Scott Tsai
no flags Details
File: limits (1.29 KB, text/plain)
2013-06-08 16:57 UTC, Scott Tsai
no flags Details
File: maps (11.51 KB, text/plain)
2013-06-08 16:57 UTC, Scott Tsai
no flags Details
File: open_fds (390 bytes, text/plain)
2013-06-08 16:57 UTC, Scott Tsai
no flags Details
File: proc_pid_status (946 bytes, text/plain)
2013-06-08 16:57 UTC, Scott Tsai
no flags Details

Description Scott Tsai 2013-06-08 16:56:43 UTC
Description of problem:
I pasted "$ curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo" into a bash prompt.
Note the "$" at the start of the command.

Version-Release number of selected component:
PackageKit-command-not-found-0.8.9-1.fc19

Additional info:
reporter:       libreport-2.1.4
backtrace_rating: 4
cmdline:        /usr/libexec/pk-command-not-found $ curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo
crash_function: pk_results_get_error_code
executable:     /usr/libexec/pk-command-not-found
kernel:         3.9.4-300.fc19.x86_64
runlevel:       N 5
uid:            1000
var_log_messages: Jun  9 00:53:31 5220m abrt[6239]: Saved core dump of pid 6234 (/usr/libexec/pk-command-not-found) to /var/tmp/abrt/ccpp-2013-06-09-00:53:31-6234 (26718208 bytes)

Truncated backtrace:
Thread no. 1 (2 frames)
 #0 pk_results_get_error_code at pk-results.c:564
 #1 pk_cnf_find_available at pk-command-not-found.c:526

Comment 1 Scott Tsai 2013-06-08 16:56:47 UTC
Created attachment 758588 [details]
File: backtrace

Comment 2 Scott Tsai 2013-06-08 16:56:50 UTC
Created attachment 758589 [details]
File: cgroup

Comment 3 Scott Tsai 2013-06-08 16:56:53 UTC
Created attachment 758590 [details]
File: core_backtrace

Comment 4 Scott Tsai 2013-06-08 16:56:56 UTC
Created attachment 758591 [details]
File: dso_list

Comment 5 Scott Tsai 2013-06-08 16:56:59 UTC
Created attachment 758592 [details]
File: environ

Comment 6 Scott Tsai 2013-06-08 16:57:03 UTC
Created attachment 758593 [details]
File: limits

Comment 7 Scott Tsai 2013-06-08 16:57:06 UTC
Created attachment 758594 [details]
File: maps

Comment 8 Scott Tsai 2013-06-08 16:57:09 UTC
Created attachment 758595 [details]
File: open_fds

Comment 9 Scott Tsai 2013-06-08 16:57:13 UTC
Created attachment 758596 [details]
File: proc_pid_status

Comment 10 Scott Tsai 2013-06-08 17:32:42 UTC
Valgrind output:

$ valgrind --tool=memcheck /usr/libexec/pk-command-not-found $ curl https://dl-ssl.google.com/dl/googlesou
==9438== Memcheck, a memory error detector
==9438== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==9438== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==9438== Command: /usr/libexec/pk-command-not-found $ curl https://dl-ssl.google.com/dl/googlesou
==9438== 
bash: $: command not found...
==9438== Conditional jump or move depends on uninitialised value(s)
==9438==    at 0x10B5AE: main (pk-command-not-found.c:516)
==9438== 
==9438== Conditional jump or move depends on uninitialised value(s)
==9438==    at 0x4C7E1DC: pk_results_get_error_code (pk-results.c:564)
==9438==    by 0x10B5C0: main (pk-command-not-found.c:526)
==9438== 
==9438== Use of uninitialised value of size 8
==9438==    at 0x4C7E1DE: pk_results_get_error_code (pk-results.c:564)
==9438==    by 0x10B5C0: main (pk-command-not-found.c:526)
==9438== 
==9438== Invalid read of size 8
==9438==    at 0x4C7E1E6: pk_results_get_error_code (pk-results.c:564)
==9438==    by 0x10B5C0: main (pk-command-not-found.c:526)
==9438==  Address 0x30244c8b4cc38949 is not stack'd, malloc'd or (recently) free'd
==9438== 
==9438== 
==9438== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==9438==  General Protection Fault
==9438==    at 0x4C7E1E6: pk_results_get_error_code (pk-results.c:564)
==9438==    by 0x10B5C0: main (pk-command-not-found.c:526)
==9438== 
==9438== HEAP SUMMARY:
==9438==     in use at exit: 190,591 bytes in 1,266 blocks
==9438==   total heap usage: 4,903 allocs, 3,637 frees, 323,740 bytes allocated
==9438== 
==9438== LEAK SUMMARY:
==9438==    definitely lost: 4 bytes in 1 blocks
==9438==    indirectly lost: 0 bytes in 0 blocks
==9438==      possibly lost: 63,750 bytes in 300 blocks
==9438==    still reachable: 126,837 bytes in 965 blocks
==9438==         suppressed: 0 bytes in 0 blocks
==9438== Rerun with --leak-check=full to see details of leaked memory
==9438== 
==9438== For counts of detected and suppressed errors, rerun with: -v
==9438== Use --track-origins=yes to see where uninitialised values come from
==9438== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 2 from 2)
Killed

Comment 11 Scott Tsai 2013-06-08 17:48:37 UTC
From the backtrace and Valgrind output, I think the problem is in the way `pk_client_search_files()` uses `pk_client_generic_finish()`.

`helper.results` can remain uninitialized in the former because `pk_client_generic_finish_sync()` only sets `helper->results` if `results != NULL`, which seems like bad API design.

Comment 12 Richard Hughes 2013-12-11 09:12:33 UTC
Yup, we've been doing memset (&helper, 0, sizeof (PkClientHelper)); for a long time now, F19 and F20 should work fine.


Note You need to log in before you can comment on or make changes to this bug.