Opened 3 years ago

Closed 3 months 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
Has a Patch: no Platform: All

Description

This is on ShowImage hrev39431 under a hrev39402 system.

After quickly browsing through many (70+) images with ShowImage, it crashes. Attached are 4 backtraces of hrev39431.

Attachments (6)

showimage.bt-1.r39431 (7.2 KB) - added by humdinger 3 years ago.
backtrace 1
showimage.bt-2.r39431 (6.4 KB) - added by humdinger 3 years ago.
backtrace 2
showimage.bt-3.r39431 (5.9 KB) - added by humdinger 3 years ago.
backtrace 3
showimage.bt-4.r39431 (6.4 KB) - added by humdinger 3 years ago.
backtrace 4
showimage.bt-5.r39493 (6.4 KB) - added by humdinger 3 years ago.
backtrace nr. 5
PC-memory.png (41.6 KB) - added by humdinger 3 years ago.
Memory situation after crash

Download all attachments as: .zip

Change History (41)

Changed 3 years ago by humdinger

backtrace 1

Changed 3 years ago by humdinger

backtrace 2

Changed 3 years ago by humdinger

backtrace 3

Changed 3 years ago by humdinger

backtrace 4

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 3 years ago by humdinger

With hrev39490 I still get backtrace nr. 2 after browsing thru about 50 6-megapixel photos.

comment:4 Changed 3 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 3 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...

Changed 3 years ago by humdinger

backtrace nr. 5

Changed 3 years ago by humdinger

Memory situation after crash

comment:6 Changed 3 years ago by axeld

Thanks! Is this a GCC4 or GCC2 build?

comment:7 Changed 3 years ago by humdinger

It's a gcc4hybrid.

comment:8 Changed 3 years ago by Ka

Can't comfirm this any more, just browsed through 150 images with about 7 megapixels.

comment:9 Changed 3 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 3 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...

Version 0, edited 3 years ago by humdinger (next)

comment:11 follow-up: Changed 3 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 3 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: Changed 3 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: Changed 3 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 3 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 3 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: Changed 3 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 3 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 3 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 3 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 3 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 3 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 3 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 2 years ago by halilpk

(GCI-2011 Participant)

Haiku revision: hrev42211 still a bug. If you open small files there is no problem but when you open big files like jpeg photos there was an error message and the system is freezing . System: Haiku hrev1-alpha3 on VMware workstation 8 on windows 7 32 bit

comment:25 Changed 2 years ago by axeld

  • Blocking 8490 added

(In #8490) I guess both are pretty much the same; it's just another outcome.

comment:26 Changed 2 years ago by axeld

Might be fixed with hrev44081.

comment:27 Changed 2 years ago by anevilyak

  • Blocking 8538 added

(In #8538) Thanks for the update!

comment:28 Changed 2 years ago by humdinger

I can still reproduce backtrace no. 3 with hrev44137 with those same photos of this ticket . Schade.

comment:29 Changed 23 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 20 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 17 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 17 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 13 months 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.

Last edited 13 months ago by Premislaus (previous) (diff)

comment:34 Changed 3 months ago by humdinger

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 Changed 3 months ago by humdinger

  • Resolution set to fixed
  • Status changed from assigned to closed

Closing ticket as apparently fixed. Re-open, if it's not...

Note: See TracTickets for help on using tickets.