Bug 1040223 - Eclipse backtrace is unusable due to an unavailable debug info
Eclipse backtrace is unusable due to an unavailable debug info
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: gnome-abrt (Show other bugs)
20
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jakub Filak
Fedora Extras Quality Assurance
abrt_hash:a08ffe5f8e58a6ca3643dfbb9ad...
: CommonBugs
: 1052379 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-12-10 20:06 EST by Matthew Javelet
Modified: 2014-01-14 14:04 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-12 03:52:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
dso_list (27.82 KB, text/plain)
2013-12-11 11:45 EST, Matthew Javelet
no flags Details

  None (edit)
Description Matthew Javelet 2013-12-10 20:06:44 EST
Description of problem:
abrt log files are being created in my ~/$USER directory.

abrt stops and says it cannot report my bug because of it not being able to find a specific log file in its normal directory rather than my userdir.

this is preventing me from submitting my issue on java-1.7.0-openjdk-1.7.0.60-2.4.3.0.f20

Version-Release number of selected component:
gnome-abrt-0.3.3

Additional info:
reporter:       libreport-2.1.9
kernel:         3.11.10-300.fc20.x86_64
type:           libreport
Comment 1 Matthew Javelet 2013-12-10 20:10:06 EST
Nevermind, _log_ files are not being created, they are abrt_checker files.

Trying to reproduce abrt log error that i previously mentioned with reporting the java bug, it takes some time as it uploads ~60MB
Comment 2 Matthew Javelet 2013-12-10 20:22:55 EST
Can't generate a backtrace, I recieve this error:

Removing /var/tmp/abrt-tmp-debuginfo-2013-12-10-19:13:21.7205
Missing debuginfo file: /usr/lib/debug/.build-id/ee/5b1a5bcaa0178c5fe974ba6f0f75f0b4529c5e.debug
Missing debuginfo file: /usr/lib/debug/.build-id/ca/a9bc15764efb3bd6666e0116494d54eb206522.debug
Missing debuginfo file: /usr/lib/debug/.build-id/89/8e5bb0e3cd8e0c91c9ce327e1653b36469f298.debug
Missing debuginfo file: /usr/lib/debug/.build-id/63/191e755f8fc304a693586f7c3ee698179f929f.debug
Generating backtrace
Backtrace is generated and saved, 150955 bytes
Looking for similar problems in bugzilla


Then an alert pops up and says backtrace is unusable
Comment 3 Matthew Javelet 2013-12-10 20:46:48 EST
I'm sorry for so many comments but the more relevant information I have may lead to resolving the issue.

Since my last attempt to report the bug through ABRT installed so many packages to generate the stack trace locally the amount of text to go through was insane. 

--- Running report_uReport ---
('report_uReport' completed successfully)

--- 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). 'YES'
Querying server settings
Preparing an archive to upload
Retrace server can not be used, because the crash is too large. Try local retracing.
The size of your archive is 79527008 bytes, but the retrace server only accepts archives smaller or equal 52428800 bytes.
Do you want to generate a stack trace locally? (It may download a huge amount of data but reporting can't continue without stack trace). 'YES'
Analyzing coredump 'coredump'
Missing build id: libCg.so
Missing build id: libCgGL.so
Coredump references 185 debuginfo files, 4 of them are not installed
Setting up yum repositories
Looking for needed packages in repositories
Can't find packages for 4 debuginfo files
Missing debuginfo file: /usr/lib/debug/.build-id/ee/5b1a5bcaa0178c5fe974ba6f0f75f0b4529c5e.debug
Missing debuginfo file: /usr/lib/debug/.build-id/ca/a9bc15764efb3bd6666e0116494d54eb206522.debug
Missing debuginfo file: /usr/lib/debug/.build-id/89/8e5bb0e3cd8e0c91c9ce327e1653b36469f298.debug
Missing debuginfo file: /usr/lib/debug/.build-id/63/191e755f8fc304a693586f7c3ee698179f929f.debug
Generating backtrace
Backtrace is generated and saved, 150955 bytes
Looking for similar problems in bugzilla

Error returned verbatim says, "Reporting disabled because the backtrace is unusable."
Comment 4 Jakub Filak 2013-12-11 04:42:32 EST
Thanks for the report. If possible, please provide 'dso_list' file of the java-1.7.0-openjdk crash (available in /var/tmp/abrt/<crash_dir>/) so we can investigate why the libCg.so and libCgGL.so build ids cannot be installed.
Comment 5 Matthew Javelet 2013-12-11 11:45:45 EST
Created attachment 835373 [details]
dso_list

Dso_list as requested. Sorry for the long wait for my response.
Comment 6 Jakub Filak 2013-12-11 12:41:04 EST
(In reply to Matthew Javelet from comment #5)
> Created attachment 835373 [details]
> dso_list
> 
> Dso_list as requested. Sorry for the long wait for my response.

/opt/google/talkplugin/lib/libCg.so

It looks like that you are using some non-Fedora library and thus abrt cannot find a debuginfo package for this library. In this case I assume, that the generated backtrace contains to many lines having unresolved symbol names and it makes the backtrace unusable. However, we should verify that I am not wrong in my assumption and the unresolved symbols are caused by the missing debug info. Could you please also provide 'backtrace' file?
Comment 7 Matthew Javelet 2013-12-11 15:24:21 EST
Before I received this message I had reinstalled beta tc5 in an attempt to _only_ install my development environment(httpd, mariadb, php), eclipse and their required dependencies. I no longer have that backtrace log, the backtrace and core_dump files exceeded over 1GB as well.

I am no longer able to reproduce this bug, the issue does seem to come a package not included in the official fedora repositories. 

Also, installing Eclipse and all my plugins with extensive testing and trying to stress the program resulted in a few hang ups, but they were shortly resolved by "waiting" instead of "force closing" the application opposed to the program crashing java-1.7.0-openjdk and closing regardless of "waiting". I have yet to reproduce the bug with about an hour of testing on this new installation.

Sorry for the inconvenience.
Comment 8 Adam Williamson 2013-12-12 01:14:40 EST
I think I might've read something about Google Talk interfering with Eclipse, in fact.

Hey! Yeah I did.

http://eclipseandlinux.blogspot.ca/2013/10/google-talk-plugin-presence-breaks.html

that may be what you had...
Comment 9 Jakub Filak 2013-12-12 03:52:53 EST
Thank you Adam! I consider your comment as the proof of my assumption and thus closing this bug as NOTABUG.

Matthew, I'm very sorry we cannot help you more. Please feel free to report any further bugs you find.
Comment 10 Adam Williamson 2013-12-19 21:54:07 EST
changing resolution to CANTFIX - this is clearly a bug, it's just not *our* bug. We'd need Google's help at the least to be able to do anything about it.
Comment 11 Adam Williamson 2013-12-20 18:26:04 EST
rgrunberg has suggested a possible workaround at http://rgrunber.wordpress.com/2013/12/20/f20-eclipse-google-talk-plugin-a-bad-time/ .
Comment 12 Alexander Kurtakov 2014-01-14 01:23:09 EST
*** Bug 1052379 has been marked as a duplicate of this bug. ***
Comment 13 Michael 2014-01-14 14:04:42 EST
(In reply to Adam Williamson from comment #11)
> rgrunberg has suggested a possible workaround at
> http://rgrunber.wordpress.com/2013/12/20/f20-eclipse-google-talk-plugin-a-
> bad-time/ .

a different workaround seems to be to modify the /etc/eclipse.ini
and adding "-Dorg.eclipse.swt.browser.DefaultType=mozilla"

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