I also have the CPU spike problem. No error ever gets reported because
of this.
** Attachment added: Screenshot from 2013-01-17 22:27:21.png
https://bugs.launchpad.net/apport/+bug/71560/+attachment/3486671/+files/Screenshot%20from%202013-01-17%2022%3A27%3A21.png
--
You received this bug
Oh god, sorry, I have not seen the date of this bug. I will file a new
one.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/71560
Title:
Crash information collection depletes resources, clogs up and
I'm using Gutsy as well, I only noticed it was apport because I had the
system monitor applet up for unrelated reasons.
The crash today seemed to be nearly identical to the other crashes I've
been getting every day or so since upgrading to Gutsy. Firefox becomes
unresponsive, the cpu maxes out,
This is still a big problem in Gutsy. I have never, repeat _NEVER_, let
apport finished running.
When an application crashes the cpu spikes to 100% and the whole system
becomes unresponsive. After a few seconds I usually manage to do a
killall apport and everything is peachy again. It never
I'm using Edgy and it happens to me too. When an application crashes and
I click on the systray icon, apport-gtk process starts to reserve
memory topping all available memory (1GB) and Swap. I have to be quick
enough to killall apport-gtk before swap gets full because my system
becomes
Hi,
FiNaLBeTa [2007-03-30 9:44 -]:
* bin/apport: Limit core dump size to 75% of usable RAM
(MemFree+Cached-Writeback). This should avoid trashing people's boxes hard
on huge core dumps. Bump dependencies on python-problem-report. Create an
expensive, but realistic check for
I've just had a gigantic crash on my 256 meg laptop, which caused the
system to be 99% unresponsive.
I couldn't even login from a console to see if it was apport working,
but I suspect it was.
I waited for about 20 minutes and made a hard shutdown.
--
Crash information collection depletes
On Fri, 30 Mar 2007, Martin Pitt wrote:
Asheesh, that would be possible, but the mere process of grabbing,
compressing, and writing a huge core dump on a machine with little
memory and/or slow CPU is a pain.
Maybe don't compress it, but write it raw to disk, and compress it at send
time,
* bin/apport: Limit core dump size to 75% of usable RAM
(MemFree+Cached-Writeback). This should avoid trashing people's boxes hard
on huge core dumps. Bump dependencies on python-problem-report. Create an
expensive, but realistic check for this in test-apport.
(LP: #71560)
This should help a fair bit. I can tweak the limit a bit further if
necessary, so please let me know how it goes.
--
Crash information collection depletes resources, clogs up and crashes system
https://launchpad.net/bugs/71560
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
apport (0.73) feisty; urgency=low
.
* problem_report.py, write(): Allow a third optional argument in tuple
values, which specify a maximum file size. Above it, the entire key gets
removed. Add testsuite checks for all boundary cases.
* bin/apport: Limit core dump size to 75% of
Can the core dump get stored on disk instead of just not saved?
--
Crash information collection depletes resources, clogs up and crashes system
https://launchpad.net/bugs/71560
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Asheesh, that would be possible, but the mere process of grabbing,
compressing, and writing a huge core dump on a machine with little
memory and/or slow CPU is a pain.
It is not fully decided yet whether we retain automatic crash
detection/reporting in the final release, but if we do, then we
Closing upstream task, no need to have two tasks for the same thing.
** Changed in: apport (upstream)
Status: Unconfirmed = Rejected
--
Crash information collection depletes resources, clogs up and crashes system
https://launchpad.net/bugs/71560
--
ubuntu-bugs mailing list
After a short discussion in #ubuntu-devel, this was the consensus:
- apport caps the core dump size to the available free memory; if it's bigger,
remove the core dump and instead set a field which describes the reason
(CoreDumpTooBig: memory size)
- UI checks for this field and informs the
Same here, and it takes a ridiculously huge amount of time to gather
info.
Most recently:
1:10 - Thunderbird crashes; system becomes sluggish.
1:13 - apport reports that thunderbird crashed, offers to report problem.
Accepted; apport begins gathering data and system becomes nearly unresponsive.
Unacceptable indeed, I worry about this effect this has on the average
user. Sorry to randomly rant, but it really irritates me when
misfeatures like this get into a supported release, both because it
hampers my ability to recommend Ubuntu to others, and because it's so
preventable, it just
** Also affects: apport (upstream)
Importance: Undecided
Status: Unconfirmed
--
Crash information collection depletes resources, clogs up and crashes system
https://launchpad.net/bugs/71560
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Just happened to me as well. I have no idea why it started (how do I
find out?), but I had reams of apport processes, all running at a nice
of -5 (!).
The only way I had to get my system back was repeatedly issuing sudo
killall apport (and since the processes kept re-starting) mv'ing the
I agree. However, in order to be useful, apport-gtk just has to do some
expensive operations. I see no way to avoid that.
I keep this open since it indeed is a problem, but at least until we get
https://wiki.ubuntu.com/CrashReporting implemented, it has to stay as it
is.
** Changed in: apport
My system doesn't crash, but boy apport-gtk brings it to its knees.
I've uninstalled it, because whenever I do encounter a crash, it takes
me basically a minute to get back to where I was rather than the 10
seconds or so it would have done if apport-gtk wasn't doing stuff (e.g.,
bringing Firefox
For this reason the current maximum core dump size is 200 MB, and when
the crash happens, apport does not process the core dump in any way (and
does not load it into memory). Do you mean it already crashes your
system at the time when the crash happens?
apport does load the core dump when you
22 matches
Mail list logo
