Red Hat Bugzilla – Bug 976513
abrt: local backtrace of Eclipse/java-1.7.0-openjdk-126.96.36.199 unusable
Last modified: 2016-02-01 17:34:07 EST
Created attachment 763542 [details]
Full text of abrt log
Description of problem:
When Eclipse crashes, the core dump is too big to process remotely ("The size of your crash is 1980059782 bytes, but the retrace server only accepts crashes smaller or equal to 1342177280 bytes."), so abrt asks if I want to generate the backtrace myself.
I say "yes."
After a fair amount of activity, abrt responds:
"Reporting disabled because the backtrace is unusable.
Checking the log, the last few lines say:
All debuginfo files are available
Backtrace is generated and saved, 126127 bytes
Looking for similar problems in bugzilla
Searching for updates
No updates for this package found
Version-Release number of selected component (if applicable):
Eclipse typically dies several times a week, but this is the first time I recall abrt volunteering to report it.
There was a new Java this morning:
Steps to Reproduce:
1. Edit some PHP
2. Eclipse will eventually up and die
This may be related to Bug 813670, but that bug is closed worksforme.
Can you please post the whole problem directory containing the backtrace? It should be in /var/tmp/abrt/ccpp-<some numbers>.
It looks like there aren't any abrt/ccpp directories before noon yesterday in /var/tmp (the cmdline file says they're both Xorg dumps--weird--noon and end of day--must be a logout thing).
The yum-abrt-* one is still there from 10am when I tried to do the local backtrace.
It occurs to me, belatedly, that I'm using an Eclipse downloaded from www.eclipse.org--not the packaged one (I tried switching to maybe avoid the bombs, but it didn't help)--so there's every possibility that it's inevitable that the backtrace WOULD be unusable.
I apologize if I ended up doing an invalid report.
Phpstorm 6.0 (IDEAJ based application) is also affected, with 2.3.10 the IDE dies on startup, restoring the 2.3.3 version with
sudo yum downgrade java-1.7.0*
restores the system , and Phpstorm is able to startup again.
Created attachment 764239 [details]
abrt directory minus coredump (toobig) for Phpstorm abrt on version 2.3.10
This is an abrt directory for the startup of Phpstorm 6.0, i have removed the coredump file as it makes the archive to big for me to upload.
188.8.131.52 was resently pushed to updates, which seems to fix the problem with phpStorm 6.0.
Created attachment 770559 [details]
ccpp directory minus 758M coredump
Although the error profile is the same, the version of java is now:
I suppose I should bump the Fedora version up, too.
GDB can only debug JVM. The executed Java application is most probably not in elf format and does not have any debugging information (similar to wine running win32 applications). Maybe there are some logs from JVM that could help if collected by ABRT, but I'm not a Java guy.
This also affects java (the executable itself). Since eclipse uses libjvm those are the same bugs.
I see this with java on F21 Alpha too. When trying to report a crash in the java executable I get this output from abrt-cli:
$ LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 abrt-cli report /var/tmp/abrt/ccpp-2014-10-16-23\:58\:57-6667/
('report_uReport' completed successfully)
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). [y/N/f]
Analyzing coredump 'coredump'
Missing build id: jna1771353467026685740.tmp
Coredump references 94 debuginfo files, 1 of them are not installed
Setting up yum repositories
Looking for needed packages in repositories
Can't find packages for 1 debuginfo files
Missing debuginfo file: /usr/lib/debug/.build-id/8a/bb59b1843ed7302d340abca001923c0c872d0f.debug
Backtrace is generated and saved, 204094 bytes
Looking for similar problems in bugzilla
Reporting disabled because the backtrace is unusable.
Please try to install debuginfo manually using the command: "debuginfo-install java-1.8.0-openjdk-headless-184.108.40.206-0.b18.fc21" and try again.
Running debuginfo-install on java packages does not fix the problem.
Besides: on every JVM crash a hs_err_pid<PID>.log file should be created in the current working directory of the JVM. Maybe this would be useful for abrt too.
(In reply to Christian Stadelmann from comment #10)
> This also affects java (the executable itself). Since eclipse uses libjvm
> those are the same bugs.
> I see this with java on F21 Alpha too. When trying to report a crash in the
> java executable I get this output from abrt-cli:
> $ LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 abrt-cli
> report /var/tmp/abrt/ccpp-2014-10-16-23\:58\:57-6667/
> ('report_uReport' completed successfully)
> 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). [y/N/f]
> Analyzing coredump 'coredump'
> Missing build id: jna1771353467026685740.tmp
> Coredump references 94 debuginfo files, 1 of them are not installed
> Setting up yum repositories
> Looking for needed packages in repositories
> Can't find packages for 1 debuginfo files
> Missing debuginfo file:
> Generating backtrace
> Backtrace is generated and saved, 204094 bytes
> Looking for similar problems in bugzilla
> Reporting disabled because the backtrace is unusable.
> Please try to install debuginfo manually using the command:
> "debuginfo-install java-1.8.0-openjdk-headless-220.127.116.11-0.b18.fc21" and try
> Running debuginfo-install on java packages does not fix the problem.
Jiri, could you please take a look into this?
Isn't this build id strange : jna1771353467026685740.tmp?
> Besides: on every JVM crash a hs_err_pid<PID>.log file should be created in
> the current working directory of the JVM. Maybe this would be useful for
> abrt too.
Thanks! ABRT makes a copy of hs_err_pid<PID>.log file in the dump directory (it should work because our test case for this passes on F21 )
This message is a notice that Fedora 19 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 19. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.
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.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 19 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 this bug is closed as described in the policy above.
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.
This bug is not fixed and still present with Fedora 21. Please reopen.
It looks like this issue is gone.