Bug 1040223

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

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

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."

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.

Created attachment 835373 [details]
dso_list

Dso_list as requested. Sorry for the long wait for my response.

(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?

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.

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...

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.

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.

rgrunberg has suggested a possible workaround at http://rgrunber.wordpress.com/2013/12/20/f20-eclipse-google-talk-plugin-a-bad-time/ .

*** Bug 1052379 has been marked as a duplicate of this bug. ***

(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"