Bug 976513

Can you please post the whole problem directory containing the backtrace? It should be in /var/tmp/abrt/ccpp-<some numbers>.

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.

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.

2.3.10.4 was resently pushed to updates, which seems to fix the problem with phpStorm 6.0.

Created attachment 770559 [details]
ccpp directory minus 758M coredump

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

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

(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

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.