Opened 3 years ago
Last modified 7 weeks ago
#6824 assigned bug
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 | |
| Has a Patch: | no | Platform: | All |
Attachments (6)
Change History (39)
Changed 3 years ago by humdinger
comment:1 Changed 3 years ago by axeld
Should be fixed in hrev39486, please confirm.
comment:2 Changed 3 years ago by axeld
- Owner changed from leavengood to axeld
- Priority changed from normal to high
- Status changed from new to in-progress
comment:3 Changed 2 years ago by humdinger
With hrev39490 I still get backtrace nr. 2 after browsing thru about 50 6-megapixel photos.
comment:4 Changed 2 years ago by axeld
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 Changed 2 years ago by humdinger
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:6 Changed 2 years ago by axeld
Thanks! Is this a GCC4 or GCC2 build?
comment:7 Changed 2 years ago by humdinger
It's a gcc4hybrid.
comment:8 Changed 2 years ago by Ka
Can't comfirm this any more, just browsed through 150 images with about 7 megapixels.
comment:9 Changed 2 years ago by bga
If no one objects, I will close this tomorrow. It seems Axel's work paid off. ;) Ka, thanks for checking.
comment:10 Changed 2 years ago by humdinger
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...
comment:11 follow-up: ↓ 12 Changed 2 years ago by axeld
- Milestone changed from R1 to R1/alpha3
- Priority changed from high to blocker
- Status changed from in-progress to assigned
comment:12 in reply to: ↑ 11 Changed 2 years ago by bonefish
A release blocker? Seriously? The bug is apparently only reproducible in some situations and no data are lost.
comment:13 follow-up: ↓ 14 Changed 2 years ago by axeld
It makes ShowImage pretty much useless. An operating system that doesn't even manage to show pictures?
comment:14 in reply to: ↑ 13 ; follow-up: ↓ 16 Changed 2 years ago by bonefish
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 Changed 2 years ago by axeld
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 in reply to: ↑ 14 Changed 2 years ago by korli
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".
comment:17 follow-up: ↓ 19 Changed 2 years ago by 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?
comment:18 Changed 2 years ago by anevilyak
- Owner changed from axeld to phoudoin
Could possibly be the same underlying cause as #6842.
comment:19 in reply to: ↑ 17 Changed 2 years ago by Disreali
- Cc mdisreali@… 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 Changed 2 years ago by axeld
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 Changed 2 years ago by Disreali
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 Changed 2 years ago by scottmc
- Milestone changed from R1/alpha3 to 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 Changed 2 years ago by axeld
- Priority changed from blocker to 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 Changed 18 months ago by halilpk
comment:25 Changed 13 months ago by axeld
- Blocking 8490 added
(In #8490) I guess both are pretty much the same; it's just another outcome.
comment:26 Changed 13 months ago by axeld
Might be fixed with hrev44081.
comment:28 Changed 12 months ago by humdinger
I can still reproduce backtrace no. 3 with hrev44137 with those same photos of this ticket . Schade.
comment:29 Changed 12 months ago by phoudoin
- Owner changed from phoudoin to axeld
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 Changed 9 months ago by mmadia
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 Changed 6 months ago by Janus
If you have at least one image with the attribute "ShowImage:orientation", the problem is related to #7736.
comment:32 Changed 6 months ago by hometue
(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 Changed 7 weeks ago by Premislaus
I just watched 576 photos with 3.45 GiB size. I have these files on NTFS partition. Nothing happened. This bug is present? This is hrev45427 gcc2h.
backtrace 1