Bug 976513 - abrt: local backtrace of Eclipse/java-1.7.0-openjdk-1.7.0.25 unusable
abrt: local backtrace of Eclipse/java-1.7.0-openjdk-1.7.0.25 unusable
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: abrt (Show other bugs)
19
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Michal Toman
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-20 13:40 EDT by Alan Schmidt
Modified: 2016-02-01 17:34 EST (History)
12 users (show)

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


Attachments (Terms of Use)
Full text of abrt log (24.69 KB, text/plain)
2013-06-20 13:40 EDT, Alan Schmidt
no flags Details
abrt directory minus coredump (toobig) for Phpstorm abrt on version 2.3.10 (30.00 KB, application/gzip)
2013-06-23 03:01 EDT, Tim Hawkins
no flags Details
ccpp directory minus 758M coredump (48.55 KB, application/x-bzip)
2013-07-08 12:16 EDT, Alan Schmidt
no flags Details

  None (edit)
Description Alan Schmidt 2013-06-20 13:40:45 EDT
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
Generating backtrace
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):
abrt-2.1.4-3.fc18.x86_64

How reproducible:
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:
java-1.7.0-openjdk-1.7.0.25-2.3.10.3.fc18.x86_64

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.
Comment 1 Jiri Moskovcak 2013-06-21 02:45:48 EDT
Can you please post the whole problem directory containing the backtrace? It should be in /var/tmp/abrt/ccpp-<some numbers>.
Comment 2 Alan Schmidt 2013-06-21 10:43:09 EDT
Crud.

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.
Comment 3 Tim Hawkins 2013-06-23 02:51:35 EDT
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.
Comment 4 Tim Hawkins 2013-06-23 03:01:53 EDT
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.
Comment 5 Tim Hawkins 2013-07-02 02:19:32 EDT
2.3.10.4 was resently pushed to updates, which seems to fix the problem with phpStorm 6.0.
Comment 6 Alan Schmidt 2013-07-08 12:16:59 EDT
Created attachment 770559 [details]
ccpp directory minus 758M coredump
Comment 7 Alan Schmidt 2013-07-08 12:19:07 EDT
Please note:

Although the error profile is the same, the version of java is now:

java-1.7.0-openjdk-1.7.0.25-2.3.10.4.fc19.x86_64
Comment 8 Alan Schmidt 2013-07-08 12:32:26 EDT
I suppose I should bump the Fedora version up, too.
Comment 9 Michal Toman 2013-08-09 06:30:11 EDT
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.
Comment 10 Christian Stadelmann 2014-10-17 04:33:12 EDT
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
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-1.8.0.25-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.
Comment 11 Jakub Filak 2014-10-18 17:04:28 EDT
(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:
> /usr/lib/debug/.build-id/8a/bb59b1843ed7302d340abca001923c0c872d0f.debug
> 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-1.8.0.25-0.b18.fc21" and try
> again.
> 
> 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 [1])

1: https://github.com/abrt/abrt/blob/master/tests/runtests/ccpp-plugin-java/runtest.sh
Comment 12 Fedora End Of Life 2015-01-09 13:29:19 EST
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.
Comment 13 Christian Stadelmann 2015-01-26 08:04:36 EST
This bug is not fixed and still present with Fedora 21. Please reopen.
Comment 14 Christian Stadelmann 2016-02-01 17:34:07 EST
It looks like this issue is gone.

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