Gzip or Bzip still runing after cancel Button is pressed

Bug #107574 reported by MarioGonzalez
12
Affects Status Importance Assigned to Milestone
File Roller
Confirmed
Medium
file-roller (Ubuntu)
Triaged
Low
Unassigned

Bug Description

Binary package hint: file-roller

If you press the Cancel button when file-roller is creating a big file the widget close but the process is still running. It can be checked with top

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here: http://bugzilla.gnome.org/show_bug.cgi?id=432965

Changed in file-roller:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: Unconfirmed → Confirmed
Changed in fileroller:
status: Unknown → Unconfirmed
Revision history for this message
Pedro Villavicencio (pedro) wrote :

Sames applies to extract. will comment upstream.

Changed in file-roller:
status: Confirmed → Triaged
Changed in file-roller:
importance: Unknown → Medium
Revision history for this message
x (dvice-null) wrote :

This is what happened to me:
1. I was trying to create a big tar.gz file from 2 GB source.
2. Progress bar doesn't show any progress show after a while I canceled it
3. I tried again creating a .zip file from the same source
4. Again, no progress, so I cancel it.
5. After a while my computer starts jamming due to out of memory (which I have 4 GB and normally max 1 GB of it is in use)
6. Then my computer starts shutting down my applications due to out of memory errors
7. I finally manage to locate the cause after logging in to command line and kill file-roller, but some data was already lost due to killed applications.

I see that this bug has been soon open for 4 years and that there are several other faults, reported to upstream which are not fixed.

Suggestions:
- Remove that application from Ubuntu.
- Or fix it
- Or rewrite it
- Or build a system which takes down applications that consume huge loads of memory before bad things start to happen. I never figured out why very small applications are killed in out-of-memory situations, instead of the one application that takes 90% of the systems memory and just keeps growing.

Changed in file-roller:
status: New → Invalid
Changed in file-roller (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
Changed in file-roller:
status: Invalid → New
Changed in file-roller:
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.