Browsing back to a rotated image crashes ShowImage

[humdinger]

This is hrev42282.

• Put a few images in a folder
• Open the first image and rotate it (ALT+R)
• Browse through the next image (CursorDown)
• Browse back (CursorUp).
• Crash

You may have to browse back and forth a few times. Also, when doing that bigger images (5 megapixel photos), the rotated image gets very distorted. Here's the backtrace:

GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-pc-haiku"...(no debugging symbols found)

[tcsetpgrp failed in terminal_inferior: Invalid Argument]
Thread 1668 called debugger(): getNumAvailable() < getNumBlocks()
Reading symbols from /boot/system/runtime_loader...done.
[...]
[Switching to team /boot/system/apps/ShowImage (1658) thread w>/boot/home/Desktop/Neuer Ordn (1668)]
0xffff0114 in ?? ()
(gdb) bt
#0  0xffff0114 in ?? ()
#1  0x0079ba66 in debugger () from /boot/system/lib/libroot.so
#2  0x007a78c5 in __assert_fail () from /boot/system/lib/libroot.so
#3  0x0081e1fb in BPrivate::hoardHeap::freeBlock ()
   from /boot/system/lib/libroot.so
#4  0x0081f179 in BPrivate::processHeap::free ()
   from /boot/system/lib/libroot.so
#5  0x00820708 in free () from /boot/system/lib/libroot.so
#6  0x00799b5c in __builtin_delete () from /boot/system/lib/libroot.so
#7  0x00448f7c in BArchivable::~BArchivable () from /boot/system/lib/libbe.so
#8  0x00228712 in ShowImageView::_DeleteBitmap ()
#9  0x0022d392 in ShowImageView::_DoImageOperation ()
#10 0x00228a9d in ShowImageView::SetImage ()
#11 0x002287fe in ShowImageView::SetImage ()
#12 0x0023133e in ShowImageWindow::MessageReceived ()
#13 0x0031963f in BLooper::DispatchMessage () from /boot/system/lib/libbe.so
#14 0x003e9bb8 in BWindow::DispatchMessage () from /boot/system/lib/libbe.so
#15 0x003ede38 in BWindow::task_looper () from /boot/system/lib/libbe.so
#16 0x0031ab5b in BLooper::_task0_ () from /boot/system/lib/libbe.so
#17 0x007a0327 in thread_entry () from /boot/system/lib/libroot.so
#18 0x78102fec in ?? ()
(gdb)

[leavengood]

This is very easy to reproduce.

To make matters worse when using libroot_debug.so (as described in ​mmlr's blog post) the crash doesn't happen at all. In fact the rotated image just becomes a 1x1 black image. Also I see no debug output in the syslog.

Axel, mmlr?

[halilpk]

(GCI-2011 Participant)

Haiku revision: hrev42211 it is a bug too. When you rotate an image you can see next image but after next image it crashes . System: Haiku hrev1-alpha3 on VMware workstation 8 on windows 7 32 bit

[ctbeiser]

I've reproduced this on hrev 43524. With a handful of screenshots, I got distortion on a 768x1024 image, and then a crash the next time I went back to it. After quitting and reloading the images, going back to the first image I had (screenshot 1) it loads a rotated picture of the window that I had when I was taking screenshot 3.

[hometue]

(GCI-2012 Participant) Haiku revision: hrev44702. Still valid. Depending on the filesize, if the image is small, it will distort, showing features of another image in the same folder, until it crashes. If it is big enough ShowImage will just crash. System: Haiku R1-alpha4 on Virtualbox 4.1.20 on windows 7 64 bit

[Janus]

The patch can fix a lot of crashes reported in other tickets.

[siarzhuk]

I can confirm that this patch fixes some issues with moving between images and rotating them sporadically. I'm not upstreaming it ATM because I'm not so flyent with ShowImage code and it is looking so tricky... May be someone more familiar with this stuff approve it? Thanks.

[Janus]

A simple explanation...

If fBitmapOwner isn't set, the invocation of _DeleteBitmap deletes fBitmap instead of releasing the reference (fBitmapOwner).

void
ShowImageView::_DeleteBitmap()
{
	_DeleteSelectionBitmap();

	if (fDisplayBitmap != fBitmap)
		delete fDisplayBitmap;
	fDisplayBitmap = NULL;

	if (fBitmapOwner != NULL)
		fBitmapOwner->ReleaseReference();
	else{
		delete fBitmap;
	}
	fBitmapOwner = NULL;
	fBitmap = NULL;
}

After that you have an invalid pointer stored in ImageCache.

[axeld]

Thanks for the patch, and the explanation! Applied in hrev45236, sorry for the delay!