---- Reported by shotwell-maint@gnome.bugs 2011-11-07 13:17:00 -0800 ----

Original Redmine bug id: 4354
Original URL: http://redmine.yorba.org/issues/4354
Searchable id: yorba-bug-4354
Original author: Adam Williamson
Original description:

I just built current shotwell git for Fedora 16. It ran at first and showed
the overview okay, then I tried double-clicking on a photo and it crashed
with:

  * ERROR **: Orientation.vala:243: rotate_dimensions: 0  
Trace/breakpoint trap (core dumped)

subsequent attempts to launch Shotwell fail immediately with that error. I
can't actually remember what image file I tried to open, unfortunately, and I
don't know where to look in Shotwell's config to figure it out.

I'm assuming current git is 0.12, with the gtk+3 conversion landing.

attaching the abrt-created backtrace.



---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----

### History

####

#1

Updated by Jeff Long about 2 years ago

Happens when selecting a picture (view full screen), or when selecting
developer=camera among other things. Orientation in DB is set to 0. Have to
run (AT YOUR OWN RISK!):

delete from PhotoTable where orientation=0;

to get so I could see existing photos. This happened after some recent Fedora
16 update ... was working until recently, and backing out recent Shotwell
commits did not help.

####

#2

Updated by Clinton Rogers about 2 years ago

Question for users who encounter this:

When building Shotwell, what version of valac are you using?

####

#3

Updated by Adam Williamson about 2 years ago

DEBUG util.py:257: vala-devel.x86_64 0:0.14.0-1.fc16

DEBUG util.py:257: vala.x86_64 0:0.14.0-1.fc16

in my build. That should be pretty straightforward upstream 0.14.0.

####

#4

Updated by Jeff Long about 2 years ago

vala-0.14.0-1.fc16.x86_64

####

#5

Updated by Lucas Beeler about 2 years ago

  * **Category** set to _4_
  * **Assignee** set to _Clinton Rogers_

####

#6

Updated by Jeff Long about 2 years ago

Bisected ... bug starts at the big checkin on 10/18:

Author: Clint Rogers <clinton@yorba.org> 2011-10-18 20:34:03

Committer: Clint Rogers <clinton@yorba.org> 2011-10-18 20:37:05

Parent: 37ccaae291ad457ec617aa10966e196b290a7e5f (Closes #3871 by forcing the
'Publishing x of y' message to be visible.)

Child: 20cbec49c263e16e4c06a06ec0aef6f3bfddd832 (Closes #3874 by setting a
proper CSS style for the frame in question.)

Branches: master, remotes/origin/master

Follows: shotwell-0.10.0

Precedes:

    
    Closes #4201 by changing all structs with reference members to classes  
        to work around a change to the way Vala handles structs passed as arguments;  
        please see https://bugzilla.gnome.org/show_bug.cgi?id=661041 for details.

####

#7

Updated by Adam Dingle about 2 years ago

Thanks a lot for the bisection - this information should help us in our
investigation.

####

#8

Updated by Clinton Rogers about 2 years ago

This is now believed to be a symptom of
https://bugzilla.gnome.org/show_bug.cgi?id=663818.

Under the right circumstances, the class-instance-as-ref-parameter problem
could cause some methods to fail silently and return before doing what we
wanted, and at least one method that tried to set the orientation in the DB
was set up to take the current photo row (which was changed to a class in the
18th October update) as a ref parameter.

####

#9

Updated by Clinton Rogers about 2 years ago

  * **Status** changed from _Open_ to _Review_

I believe this will be addressed by the proposed fix for #4363.

####

#10

Updated by Jeff Long about 2 years ago

Turning off --enable-checking worked for me (at least for my test case). I did
notice that the picture, which is rotated correctly in the gallery view, is
incorrectly rotated in full screen. My solution was to have develop_photo()
write metadata (already available in that function) to the backing file in the
EMBEDDED case. That also solves another problem I was having, where no
metadata at all was being shown.

####

#11

Updated by Clinton Rogers about 2 years ago

  * **Status** changed from _Review_ to _5_
  * **% Done** changed from _0_ to _100_
  * **Resolution** set to _fixed_

163bf4a114acd97734264eea7835137d804b67e1

####

#12

Updated by Clinton Rogers about 2 years ago

On behalf of the team here, I'd like to extend a sincere word of thanks to
Jeff for bisecting this and to everyone who reported variations of this and
responded to our questions; your help was instrumental in helping us squash
not one but three showstoppers with one commit and helping us find a new Vala
bug as well.

Many thanks!

####

#13

Updated by Clinton Rogers almost 2 years ago

  * **Status** changed from _5_ to _Open_

Reopened; please see the mailing list thread
http://lists.yorba.org/pipermail/shotwell/2011-November/003351.html

####

#14

Updated by Adam Dingle almost 2 years ago

  * **Resolution** deleted (<strike>_fixed_</strike>)

####

#15

Updated by Clinton Rogers almost 2 years ago

  * **File** 4354.diff added
  * **Status** changed from _Open_ to _Review_

Patch includes code to fix up an already-affected DB.

####

#16

Updated by Clinton Rogers almost 2 years ago

  * **Status** changed from _Review_ to _5_
  * **Resolution** set to _fixed_

7b2a9d2399a28f87c6754e5b7879a807dadf9d2f

####

#17

Updated by Charles Lindsay 7 months ago

  * **Status** changed from _5_ to _Fixed_



--- Bug imported by chaz@yorba.org 2013-11-25 21:55 UTC  ---

This bug was previously known as _bug_ 4354 at http://redmine.yorba.org/show_bug.cgi?id=4354
Imported an attachment (id=262250)
Imported an attachment (id=262251)

Unknown Component 
   Using default product and component set in Parameters 
Unknown milestone "unknown in product shotwell. 
   Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.