crash opening image files with 'open project'

Bug #749669 reported by Bruno Postle
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Hugin
Fix Released
High
Unassigned
Fedora
Won't Fix
Undecided

Bug Description

This was reported in the fedora bugzilla by Robert Kief: https://bugzilla.redhat.com/show_bug.cgi?id=693111

Steps to reproduce:

Select File -> Open.
Change the pattern match at the bottom to 'All files (*).
Select a TIFF or JPEG file.
Click Open.
crash_function: HuginBase::PanoramaMemento::loadPTScript

Revision history for this message
In , Robert (robert-redhat-bugs-1) wrote :

abrt version: 1.1.17
architecture: x86_64
Attached file: backtrace, 76046 bytes
cmdline: hugin
component: hugin
Attached file: coredump, 156053504 bytes
crash_function: HuginBase::PanoramaMemento::loadPTScript
executable: /usr/bin/hugin
kernel: 2.6.35.11-83.fc14.x86_64
package: hugin-2010.2.0-1.fc14
rating: 4
reason: Process /usr/bin/hugin was killed by signal 6 (SIGABRT)
release: Fedora release 14 (Laughlin)
time: 1301766506
uid: 500

How to reproduce
-----
1. Attempted to open a TIFF file.

Revision history for this message
In , Robert (robert-redhat-bugs-1) wrote :

Created attachment 489605
File: backtrace

Revision history for this message
In , Bruno (bruno-redhat-bugs) wrote :

Thanks, I've transferred this upstream: https://bugs.launchpad.net/fedora/+bug/749669

Of course if you just want to add a TIFF to the project, then you can use the '1. Load Images...' button and it doesn't crash.

Revision history for this message
onomou (onomou) wrote :

Hi, I made a patch that checks the input file for bad (binary file type) characters before letting the program proceed. It keeps it from crashing from image files.

onomou (onomou)
Changed in hugin:
assignee: nobody → onomou (onomou)
status: New → Fix Committed
onomou (onomou)
Changed in hugin:
status: Fix Committed → In Progress
Revision history for this message
tmodes (tmodes) wrote :

Your patch rejects too much characters.
Hugin is capable to work with filenames with nearly all characters. But your patch rejects all advanced characters e.g. äöüß from german, but other language are also affected. On unix Hugin works with filenames with characters from nearly the whole UTF-8 and hugin is multi lingual. This should the code respect.

Revision history for this message
onomou (onomou) wrote :

Sure enough. I was thinking in ASCII and not Unicode. I'll read up on this format and resubmit soon.

Revision history for this message
Yuv (yuv) wrote :

any new on the resubmission?

Revision history for this message
onomou (onomou) wrote :

Not a complete fix I think, but I can't reproduce the errors after this patch. Seems one culprit was the v line parser - very outdated and hammer-ish. Hopefully this is headed in the right direction...

Changed in hugin:
status: In Progress → New
Yuv (yuv)
Changed in hugin:
importance: Low → High
Revision history for this message
tmodes (tmodes) wrote :

The new v line parser does not parse correctly if translation parameters (TrX, TrY, TrZ) are in the v lines. These are skipped with the new v line parser/ they does not appear correctly in the gui and it is not possible to optimize the translation parameters on the command line (autooptimiser).

Revision history for this message
onomou (onomou) wrote :

You are right. But where is the documentation for this? The most complete that I've found is up on CPAN:
http://search.cpan.org/dist/Panotools-Script/lib/Panotools/Script/Line/Variable.pm
and mentions nothing about having those parameters. Translation should be in the i lines (see http://search.cpan.org/dist/Panotools-Script/lib/Panotools/Script/Line/Image.pm). If we should not be going off the standards on CPAN, we need a centralized source for our implementation. Where is it? I couldn't find it on the panotools wiki nor in the built-in documentation of hugin. Maybe it's there, but not easy to find. I'd be happy if you could point me in the right direction.

I'll take a look at the code to make sure it is parsing everything the way I understood it should. Please let me know if you have any suggestions - the old code was buggy and incomplete, and I felt it required a rewrite.

Yuv (yuv)
Changed in hugin:
status: New → In Progress
Revision history for this message
tmodes (tmodes) wrote :

Default branch (changeset d5a36b26e4af) shows now a warning when trying to load an image instead of project file.

Changed in hugin:
assignee: onomou (onomou) → nobody
status: In Progress → Fix Committed
tmodes (tmodes)
Changed in hugin:
milestone: none → 2011.4beta1
status: Fix Committed → Fix Released
Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 14 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Changed in fedora:
importance: Unknown → Undecided
status: Unknown → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.