Re: [Crash-catcher] java reports by crash catcher
by Michal Nowak
----- "Mark Wielaard" <mjw(a)redhat.com> wrote:
> Hi,
>
> It would be nice if crash-catcher could be thought about the
> hs_pid*.log
> files that a crashed java process creates. That file contains much
> more
> information that is relevant to the crash than the gdb backtrace that
> is
> currently collected. If it can see if there is a hs_pid###.log file
> (where ### is the process id of the java process that crashed) and
> attached that to the bug report it files that would be appreciated.
>
I am afraid Java exceptions are not supported at the moment (just the
python ones) and thus ABRT is not being run in such cases.
Do you have some example crash, where ABRT stepped in?
Since Java apps exception handling is completely missing, perhaps
some of you guys can help?
> Thanks,
>
> Mark
Michal
>
> _______________________________________________
> Crash-catcher mailing list
> Crash-catcher(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/crash-catcher
13 years, 6 months
[Crash-catcher] Proposed change in plugin configure GUI machinery
by Denys Vlasenko
An idea I want to discuss
With recent reorganization of "Enabled" directive, there is
one bug left: it is impossible to configure settings
for non-loaded plugin - [Configure plugin] button is grayed out
for them.
Here is why:
we determine whether a plugin has configure dialog by looking
at plugin_info["GTKBuilder"], if it is != "", then we load that file
and we have a GUI dialog.
Problem is, a non-loaded plugin always has plugin_info["GTKBuilder"] == ""
Proposed solution:
(1) move lib/Plugins/*.GTKBuilder to src/GUI/
(2) do not check plugin_info["GTKBuilder"] (in fact, we can nuke it altogether)
(3) instead, just check whether <plugin_name>.GTKBuilder file exists
Step (3) works even for non-loaded plugins.
Any thoughts why it might be a bad idea?
--
vda
14 years, 3 months
Re: [Crash-catcher] [PATCH] Proper /var/cache/abrt permissions
by Karel Klic
On 01/11/2010 07:14 PM, Jiri Moskovcak wrote:
> On 01/11/2010 06:48 PM, Karel Klic wrote:
>> The only problem with this patch is that it assumes that "private
>> groups" are used on the system. That is, a user "karel" belongs to group
>> "karel", and not to a common group "users". I do not know whether this
>> is true for all desktop and server deployments.
>> (If all users share the same group, they will also be able to read other
>> user's crashes, and we do not want that.)
>
> We can't rely on this, I think group per user is not default on many
> systems.
I agree, this must be solved.
>>
>> An alternative to this patch is setting the option MakeCompatCore
>> default and make everything in /var/cache/abrt/ readable only by ABRT,
>> as it was proposed by Jiri
>>
> This seems better as we restore the original coredumping behaviour, but
> this was an idea from the top of my head and I didn't think about it
> much, so it might have some side effects.
I decided to commit it, as it does not add new code, but fixes the
currently broken code at least for systems with private groups.
14 years, 3 months
[Crash-catcher] [PATCH] Proper /var/cache/abrt permissions
by Karel Klic
Hi,
here is a patch that fixes /var/cache/abrt/* permissions by allowing
users to read, but not to change their crash data. It adds abrt user,
changes abrt-hook-python to use suid instead of sgid bit (uid=abrt),
sets /var/cache/abrt and every dump subdirectory to be owned by abrt
user. Read access for users and their own crashes is provided by group
(/var/cache/abrt/ccpp-xxxx-xx has user's group).
Current git version is broken. We create a debug dump directory without
write access for user, and applications run by that user
(abrt-python-hook) cannot create files in that directory, even when they
run with the right group (=abrt group, which has the write access)
Furthermore, user can chmod directories he owns, so he can add write
access himself. So abrt group is useless in this case.
The only problem with this patch is that it assumes that "private
groups" are used on the system. That is, a user "karel" belongs to group
"karel", and not to a common group "users". I do not know whether this
is true for all desktop and server deployments.
(If all users share the same group, they will also be able to read other
user's crashes, and we do not want that.)
An alternative to this patch is setting the option MakeCompatCore
default and make everything in /var/cache/abrt/ readable only by ABRT,
as it was proposed by Jiri
Jiri, Denys, Nikola, what do you think about it?
Karel
14 years, 3 months
[Crash-catcher] ABRT Meeting Summary 2010-01-06
by Denys Vlasenko
Things to do, ordered roughly in the order of importance.
* Prepare slides for 27 Jan presentation
This can be combined with performing further work on
deployment doc and design doc:
* Deployment doc: prepare unsuspecting vict^W^W user/admin
who installs and uses abrt for the first time what to expect.
It needs to answer user-centric information about "How Do I Do X?
How Do I Do Y?". Example doc for yum:
http://dsilas.fedorapeople.org/deployment-guide/latest/Yum.html
Douglas Silas <dhensley(a)redhat.com> may help with review
* Design doc needs updating/consolidating:
doc/DESIGN and https://fedorahosted.org/abrt/wiki/AbrtArchitecture
(some of the above is already done)
* Make it possible to disable backtrace production for binary crashes:
- add an option to ccpp analyzer to not download debuginfos
and not run gdb
- move gdb dependency from ccpp plugin to abrt-desktop package
* Jirka: teach other members of the team how to do releases,
to reduce his own workload
* Further improve dup detection - have two hashes computed:
one for "good" backtraces, one for "bad", and check for match
of either one against reports already stored in BZ.
If either has a match, then it's a dup.
This makes most "bad" backtraces be grouped into one dup per
package.
* Fix more bugs before RHEL branch is cut (15 Jan).
We have plenty of work for us in the BZ...
* Retrace server:
- see how it is done by other projects (Ubuntu/Ffox/etc):
- start implementing one
- when, and *if*, it looks like it is a step forward,
not an additional burden, then consider officially
adding it to abrt.
--
vda
14 years, 3 months