Opened 14 years ago
Closed 11 years ago
#6824 closed bug (fixed)
ShowImage crashes after browsing thru many photos
| Reported by: | humdinger | Owned by: | axeld |
|---|---|---|---|
| Priority: | high | Milestone: | R1/beta1 |
| Component: | Applications/ShowImage | Version: | R1/Development |
| Keywords: | Cc: | mdisreali@… | |
| Blocked By: | Blocking: | #8490, #8538 | |
| Platform: | All |
Attachments (6)
Change History (41)
by , 14 years ago
| Attachment: | showimage.bt-1.r39431 added |
|---|
comment:2 by , 14 years ago
| Owner: | changed from to |
|---|---|
| Priority: | normal → high |
| Status: | new → in-progress |
comment:3 by , 14 years ago
With hrev39490 I still get backtrace nr. 2 after browsing thru about 50 6-megapixel photos.
comment:4 by , 14 years ago
Thanks for the update! How much RAM do you have, and what is ProcessController saying about the current memory consumption (especially from ShowImage)?
comment:5 by , 14 years ago
I have a core2duo with 2GB RAM and 2GB swap.
I guess you mean memory consumption when the crash happens. Showimage: 335432KB, app_server: 409256KB jumping back to 77376KB when closing ShowImage after it crashed).
BTW, when doing it for the second time to confirm the numbers, it crashed with backtrace nr. 1 again (after only 25 images). And then with new backtrace nr. 5, which is only slightly different than nr. 4...
comment:8 by , 14 years ago
Can't comfirm this any more, just browsed through 150 images with about 7 megapixels.
comment:9 by , 14 years ago
If no one objects, I will close this tomorrow. It seems Axel's work paid off. ;) Ka, thanks for checking.
comment:10 by , 14 years ago
Not so fast. :) I still have crash nr.4 after about 30 big pics on first try, 40 on second try, 10 on third, 65 on fourth...
Interesting. I copied the folder with those photos from one BFS partition to another: still crashing (checkfs: no errors). Then I copied the folder onto a ext3 partition: no crash so far.
I have a very slow hard disk (wait 'til Xmas...), so image loading times are felt when quickly browsing. Reading from ext3 is even a bit slower than from a BFS partition. In case that helps somehow...
This is hrev39660.
follow-up: 12 comment:11 by , 14 years ago
| Milestone: | R1 → R1/alpha3 |
|---|---|
| Priority: | high → blocker |
| Status: | in-progress → assigned |
comment:12 by , 14 years ago
A release blocker? Seriously? The bug is apparently only reproducible in some situations and no data are lost.
follow-up: 14 comment:13 by , 14 years ago
It makes ShowImage pretty much useless. An operating system that doesn't even manage to show pictures?
follow-up: 16 comment:14 by , 14 years ago
Replying to axeld:
It makes ShowImage pretty much useless. An operating system that doesn't even manage to show pictures?
You're exaggerating. The bug is apparently only encountered with certain setups and only after showing dozens of pictures. We have a lot of bugs that are far more serious (crashing the system) with non-blocker priority. E.g. #4157 or the port heap issue(s) (#5317, #5474, #5937).
Anyway, that doesn't mean that you should fix this bug. :-) I just don't think it should be a blocker.
comment:15 by , 14 years ago
The bug happens pretty randomly, and can also happen while loading the very first image. I would consider this as a blocker, as something like that just shows the lack of polishing I'm used from several Linux distributions, and I would really like to see us doing better.
It's just a matter of one's POV :-)
comment:16 by , 14 years ago
Replying to bonefish:
Anyway, that doesn't mean that you should fix this bug. :-) I just don't think it should be a blocker.
I'm sure you meant "that doesn't mean that you shouldn't fix this bug".
follow-up: 19 comment:17 by , 14 years ago
Have the recent changes to ShowImage had any affect on this issue? In other word does this still happen with the latest builds? Is it really a showstopper for Alpha3 or can this one slide to the next release?
comment:18 by , 14 years ago
| Owner: | changed from to |
|---|
Could possibly be the same underlying cause as #6842.
comment:19 by , 14 years ago
| Cc: | added |
|---|
Replying to scottmc:
Have the recent changes to ShowImage had any affect on this issue? In other word does this still happen with the latest builds? Is it really a showstopper for Alpha3 or can this one slide to the next release?
Having this issue marked as a blocker is a little extreme IMHO. I have not been able to reproduced it. Listing it as a "known issue" in the release notes seem reasonable.
comment:20 by , 14 years ago
This bug is completely unrelated to #6842, unfortunately.
Disreali: are you testing on a single or multi core CPU? It would be interesting to see if the bug doesn't occur on a single CPU system.
comment:21 by , 14 years ago
My system has a Core2 Quad Q6660 CPU. The only time that I have experienced ShowImage crash, is when I attempt to view a particular HDR jpeg. See ticket 6975 for for the actual file, backtrace, and syslog. It may the two tickets are related.
comment:22 by , 14 years ago
| Milestone: | R1/alpha3 → R1/beta1 |
|---|
sliding this one to R1/beta, as it hasn't seen much reported progress, and only a few have experienced it. If it can be fixed in time to make Alpha3 then great, but I don't see it as a blocker for blocker, perhaps still a blocker for Beta1 though.
comment:23 by , 14 years ago
| Priority: | blocker → high |
|---|
It still happens quite frequently here. I suspect the JPEG translator in the mean time, since I've seen other JPEG heavy applications crash as well from time to time.
comment:24 by , 13 years ago
comment:25 by , 13 years ago
| Blocking: | 8490 added |
|---|
(In #8490) I guess both are pretty much the same; it's just another outcome.
comment:28 by , 13 years ago
I can still reproduce backtrace no. 3 with hrev44137 with those same photos of this ticket . Schade.
comment:29 by , 12 years ago
| Owner: | changed from to |
|---|
Dunno why this ticket is still assigned to me. Let's give someone else the opportunity to find someone to pass assignement on ;-)
comment:30 by , 12 years ago
It seems that the attachment:showimage.bt-3.r39431 is somewhat similar as I've seen in #8902, except it occurs upon closing ShowImage while images are still being processed.
comment:31 by , 12 years ago
If you have at least one image with the attribute "ShowImage:orientation", the problem is related to #7736.
comment:32 by , 12 years ago
(GCI-2012 Participant)
Haiku revision: hrev44702. Still a bug. Present in bigger images, the ShowImage will freeze, then crash. After the crashing ShowImage will refuse to open any of the images of the same file format, and the way to solve this is to reboot Haiku. System: Haiku R1-alpha 4 on Virtualbox 4.1.20 on Windows 7 64 bit.
comment:33 by , 12 years ago
I just watched 576 images with 3.45 GiB size. I have these files on NTFS partition. Nothing happened. This bug is present? This is hrev45427 gcc2h.
comment:34 by , 11 years ago
I've now browsed several times through the same images that lead to the crashes described in this ticket. No crashes whatsoever. If nobody objects, I'll close this tickets in a few days.
comment:35 by , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Closing ticket as apparently fixed. Re-open, if it's not...
backtrace 1