Bug 807065 - abrt analyze_LocalGDB fails with Can't open build_ids: [Errno 13] Permission denied: 'build_ids'
abrt analyze_LocalGDB fails with Can't open build_ids: [Errno 13] Permission ...
Product: Fedora
Classification: Fedora
Component: abrt (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: abrt
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-03-26 18:10 EDT by Paul DeStefano
Modified: 2013-07-31 13:30 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-31 13:30:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
ABRT's Logger Log for crash of 'sleep 1000' (2.80 KB, text/x-log)
2012-03-26 18:10 EDT, Paul DeStefano
no flags Details

  None (edit)
Description Paul DeStefano 2012-03-26 18:10:55 EDT
Created attachment 572884 [details]
ABRT's Logger Log for crash of 'sleep 1000'

Description of problem:
Regardless of which core it is trying to analyze, it fails with the same error:

Can't open build_ids: [Errno 13] Permission denied: 'build_ids'

Version-Release number of selected component (if applicable):

How reproducible:
Seems like all cores, even test coredump generated as directed by bugzilla folks.

Steps to Reproduce:
1. sleep 1000 &
2. kill -6 <pid>
3. start abrt tool and try to report crash
Actual results:
While trying to use the Local GNU Debugger option, this results:

--- Running analyze_LocalGDB ---
Analyzing coredump 'coredump'
Can't open build_ids: [Errno 13] Permission denied: 'build_ids'
(exited with 1)

Expected results:
debuginfos are downloaded and core is analyzed.

Additional info:
Attached is the logger log file abrt produces.  This problem prevents reporting crashes via Bugzilla, directly.  (I assume that's by design, right?)
Comment 1 Paul DeStefano 2012-07-27 13:55:07 EDT
Still a problem in F17.  Identical symptoms.  I don't understand what happened to ABRT.  Local and remote analysis fail.

Current ABRT pkg: abrt-2.0.10-4.fc17.x86_64

Logs from try to trace coredump:
--- Running analyze_RetraceServer ---
Querying server settings
Preparing an archive to upload
Uploading 18068 bytes
Upload successful
Retrace job started
Initializing virtual root
Initializing virtual root
Initializing virtual root
Initializing virtual root
Initializing virtual root
Cleaning up virtual root
Retrace job finished successfully
Backtrace parsing failed for .
1:0: No frame and no thread found.

--- Running analyze_LocalGDB ---
Analyzing coredump 'coredump'
Can't open build_ids: [Errno 13] Permission denied: 'build_ids'
(exited with 1)
Comment 2 Jiri Moskovcak 2012-08-10 02:38:38 EDT
Can you please try it again, when the crash is detected run:

$ abrt-gui -vvv
$ ls -lZ /var/spool/abrt/ccpp-<time>-<pid>/

and attach the output of both to this bz.
Comment 3 Paul DeStefano 2012-08-10 11:51:41 EDT
Thanks Jiri!

abrt-gui -vvv output:

Initializing inotify
Adding inotify watch to glib main loop
adding: /var/spool/abrt/ccpp-2012-08-06-22:17:51-25999
adding: /var/spool/abrt/ccpp-2012-08-08-23:48:28-640
adding: /var/spool/abrt/ccpp-2012-08-10-08:38:46-11281
adding: /var/spool/abrt/ccpp-2012-07-11-17:04:48-20796
added: /var/spool/abrt/ccpp-2012-08-06-22:17:51-25999
added: /var/spool/abrt/ccpp-2012-08-08-23:48:28-640
added: /var/spool/abrt/ccpp-2012-08-10-08:38:46-11281
added: /var/spool/abrt/ccpp-2012-07-11-17:04:48-20796
directory /home/pdestefa/.abrt/spool doesn't contain any problem directories

 > ls -lZ /var/spool/abrt/ccpp-2012-08-10-08\:38\:46-11281/
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 abrt_version
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 analyzer
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 architecture
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 cgroup
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 cmdline
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 component
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 core_backtrace
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 coredump
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 count
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 dso_list
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 environ
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 executable
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 hostname
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 kernel
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 limits
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 maps
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 open_fds
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 os_release
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 package
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 pid
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 pwd
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 reason
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 time
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 uid
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 username
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 uuid
-rw-r-----. abrt pdestefa system_u:object_r:abrt_var_cache_t:s0 var_log_messages
Comment 4 Jiri Moskovcak 2012-08-13 03:59:46 EDT
Can you please also attach the output of the debuginfo install process when running $ abrt-gui -vvv
Comment 5 Paul DeStefano 2012-08-13 14:08:43 EDT
Hmm, this is what I see after it says "running debuginfo...".  But, it doesn't really show that debuginfo-install ran:

--- Running analyze_LocalGDB ---
Analyzing coredump 'coredump'
skipping line '0x7fff175ff000+0x1000 d60966492005f5d377e14c3dac1123a02ecb2b28@0x7fff175ff340 . - linux-vdso.so.1'
Found 3 build_ids
Found 3 libs
Can't open build_ids: [Errno 13] Permission denied: 'build_ids'
(exited with 1)
Comment 6 Paul DeStefano 2012-08-13 14:20:53 EDT
Okay, it works fine as root (sudo -i abrt-gui -vvv).  So, it must be a problem gaining privilege.  But, abrt doesn't always ask me for a password.  What might cause that?

--- Running analyze_LocalGDB ---
Analyzing coredump 'coredump'
skipping line '0x7fffa53ff000+0x1000 d60966492005f5d377e14c3dac1123a02ecb2b28@0x7fffa53ff340 . - linux-vdso.so.1'
Found 3 build_ids
Found 3 libs
cur_size:0 cap_size:4294967296, no (more) trimming
Coredump references 3 debuginfo files, 3 of them are not installed
Setting up yum repositories
Looking for needed packages in repositories
Packages to download: 2

glibc-debuginfo-2.15-51.f 0% [                ]  0.0 B/s |    0 B     --:-- ETA 

glibc-debuginfo-2.15-51.f 0% [                ]  0.0 B/s |  25 kB     --:-- ETA 


glibc-debuginfo-2.15-51.f 0% [===============-] 741 kB/s | 9.0 MB     00:00 ETA 

glibc-debuginfo-2.15-51.fc17.x86_64.rpm                  | 9.0 MB     00:13     
Extracting cpio from /tmp/abrt-tmp-debuginfo-2012-08-13-11:11:46.963/glibc-debuginfo-2.15-51.fc17.x86_64.rpm
Caching files from unpacked.cpio made from glibc-debuginfo-2.15-51.fc17.x86_64.rpm

coreutils-debuginfo-8.15- 0% [                ]  0.0 B/s |    0 B     --:-- ETA 


coreutils-debuginfo-8.15- 0% [===============-] 505 kB/s | 3.3 MB     00:00 ETA 

coreutils-debuginfo-8.15-6.fc17.x86_64.rpm               | 3.4 MB     00:06     
Extracting cpio from /tmp/abrt-tmp-debuginfo-2012-08-13-11:11:46.963/coreutils-debuginfo-8.15-6.fc17.x86_64.rpm
Caching files from unpacked.cpio made from coreutils-debuginfo-8.15-6.fc17.x86_64.rpm
Removing /tmp/abrt-tmp-debuginfo-2012-08-13-11:11:46.963
All debuginfo files are available
Locked './.lock'
Unlocked './.lock'
Generating backtrace
Executing: gdb -batch -ex set debug-file-directory /usr/lib/debug:/var/cache/abrt-di/usr/lib/debug -ex file /usr/bin/sleep -ex core-file ./coredump -ex thread apply all backtrace 2048 full -ex info sharedlib -ex print (char*)__abort_msg -ex print (char*)__glib_assert_msg -ex info registers -ex disassemble
Locked './.lock'
Unlocked './.lock'
Backtrace is generated and saved, 2268 bytes
Locked './.lock'
Generating duphash: coreutilsThread

Unlocked './.lock'
Loading settings from '/etc/libreport/plugins/bugzilla.conf'
Loaded '/etc/libreport/plugins/bugzilla.conf'
Initializing XML-RPC library
found version: '4.2.2-3.3'
found bug_id 696222
Locked './.lock'
Unlocked './.lock'
parse_release: version:'17' product:'Fedora'
Searching for updates
curl: About to connect() to admin.fedoraproject.org port 443 (#0)

curl:   Trying

curl: connected

curl: Connected to admin.fedoraproject.org ( port 443 (#0)

curl: Initializing NSS with certpath: sql:/etc/pki/nssdb

curl:   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none

curl: SSL connection using TLS_RSA_WITH_AES_256_CBC_SHA

curl: Server certificate:

curl: 	subject: CN=*.fedoraproject.org,OU=Corporate Infrastructure Services,O=Red Hat Inc,L=Raleigh,ST=North Carolina,C=US,serialNumber=eFvGaM1boCDIo4Sq/5q3n25qNP78v3Ig

curl: 	start date: Aug 02 10:55:39 2011 GMT

curl: 	expire date: Oct 03 07:25:32 2013 GMT

curl: 	common name: *.fedoraproject.org

curl: 	issuer: CN=GeoTrust SSL CA,O="GeoTrust, Inc.",C=US

curl sent header: 'POST /updates/list HTTP/1.1
Host: admin.fedoraproject.org
Content-Type: application/x-www-form-urlencoded
Accept: application/json
User-Agent: ABRT/2.0.10
Content-Length: 23

curl sent data: 'bugs=696222&release=f17'
curl: upload completely sent off: 23 out of 23 bytes

curl rcvd header: 'HTTP/1.1 200 OK
curl rcvd header: 'Date: Mon, 13 Aug 2012 18:13:06 GMT
curl rcvd header: 'Server: Apache/2.2.15 (Red Hat)
curl rcvd header: 'Content-Length: 76
curl rcvd header: 'AppTime: D=238249
curl rcvd header: 'AppServer: app03.phx2.fedoraproject.org
curl rcvd header: 'Content-Type: application/json
curl rcvd header: 'Set-Cookie: tg-visit=cfe8ff158dde683d04ee448b5c5cce502ac9704a; httponly; Path=/; secure
curl rcvd header: 'ProxyTime: D=266023
curl rcvd header: 'ProxyServer: proxy08.fedoraproject.org
curl rcvd header: '
curl rcvd data: '{"title": "0 updats found", "tg_flash": null, "num_items": 0, "updates": []}'
curl: Connection #0 to host admin.fedoraproject.org left intact

after curl_easy_perform: http code 200 body:'{"title": "0 updats found", "tg_flash": null, "num_items": 0, "updates": []}'
curl: Closing connection #0
Comment 7 Jiri Moskovcak 2012-09-18 06:47:25 EDT
ABRT should ask whether you want to "copy the directory and make it writeable" and to make it work you have to answer "yes". If you don't do that it will result into this error.
Comment 8 Paul DeStefano 2012-10-03 02:20:06 EDT
Hi Jiri,

Hmm, it definitely isn't asking that.  That sounds vaguely familiar from years and years ago, but it hasn't asked me that in the last three years.  Is that a setting I can reset?
Comment 9 Jakub Filak 2012-10-03 02:36:07 EDT
The configuration is stored in the ~/.config/abrt/settings/report-gtk.conf file. The key should be "ask_steal_dir". Just delete a line with that key.
Comment 10 long 2013-01-10 15:31:01 EST
I told abrt that it could move the files to a writeable directory and I still get:

--- Running report_uReport ---
(exited with 0)

--- Running analyze_CCpp ---
Ok to upload core dump? (It may contain sensitive data). If your answer is 'No', a stack trace will be generated locally. (It may download a huge amount of data). 'NO'
Analyzing coredump 'coredump'
Can't open build_ids: [Errno 13] Permission denied: 'build_ids'
(exited with 1)

when doing a local backtrace.
Comment 11 Paul DeStefano 2013-03-04 01:07:19 EST
I recently needed abrt again and was asked do to a local analysis by Fedora devel people.  abrt still gives me 

Can't open build_ids: [Errno 13] Permission denied: 'build_ids'

Even running abrt-gui as root doesn't work.  I'm using ecryptfs for my home directory, though, on this system.  I've seen a few weird things that stem from that in F18 which didn't used to be a problem.
Comment 12 Fedora End Of Life 2013-07-03 15:13:31 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 13 Fedora End Of Life 2013-07-31 13:30:30 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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