Fast Preview Hangs or Crashes since 2011.0

[Calvin K McDonald]

EDIT (August 6, 2011): summarized known information

*WORKAROUND FOR USERS*: disable the Overview

1- start Hugin
2- load a project
3- go to the Fast Preview Window. don't touch anything else but described below as this could trigger the bug
4- hit the button Show/Hide to hide the Overview
5- quit Hugin
Now Hugin should perform well.

*AFFECTED SYSTEMS*

- CPU: all systems with more than one thread, that is multi-core CPUs as well as single-core CPUs with hyperthreading.
- Operating Systems: due to the different implementations of threading and OpenGL on different platform, some systems are more prone to error than others. Mac OS X seems to be the least affected. Windows seems to be the most affected.

*AFFECTED VERSIONS*

- All versions of Hugin since the introduction of the Overview in the Fast Preview are affected. That is, all versions after revision 4808:8c577b320714 2011-01-09 12:21:18
- This includes the final releases of 2011.0.0 as well as all beta/candidate releases of 2011.2.0

*SUMMARY FOR DEVELOPERS / BUG HUNTERS*

This is most likely a threading issue. Lukáš' hypothesis: "a race condition in OpenGL calls, when OGL is called by separate threads from both overview and fast preview. The reason is that OpenGL is not thread-safe and it can cause various problems when used within multi-threaded application."

Run 'valgrind --tool=helgrind hugin' and try to reproduce the error to produce a useful backtrace like https://bugs.launchpad.net/hugin/+bug/792896/+attachment/2253077/+files/valgrind-out.txt

*ORIGINAL BUG REPORT BELOW FOR COMPLETION:*

Upgraded from 2010.4 to 2011.0.0 and it has hung 3 times in about 15 sessions. All three hangs happened while doing the same thing..... new session, load images, load a lens profile, set the canvas size (Calculate optimal size), save-as and save profile then click on GL (fast preview) button. Fast preview window comes up, shows anchor image and then hangs.

Is not reproducible. Running 2011.0.0.0fd3e119979c built by Matthew Petroff on 64-bit Win7.

[Yuv (yuv)]

non-reproducible bugs are difficult to narrow down, but you describe a pretty good process to trigger it in about 20% of cases (3/15).

can you try the latest 2011.2 beta from

https://sourceforge.net/projects/hugin/files/hugin/hugin-2011.2_beta/

and post your comments here? please set the status of the report to "new" to attract attention.

might be related to bug #736726

[MNi (mni-tag)]

Can reproduce at will. 1st set of 5 pics, hung 2 out of 3 times, 2nd set of 6 pics, hung 5 out of 5 times.

Running hugin 2011.0.0.0fd3e119979c built by Matthew Petroff on Win XP SP3 32-bit.

[MNi (mni-tag)]

Tried hugin-2011.2_beta (2011.2.0.cf0eaefbe0dd built by Matthew Petroff) as well on same machine, hung 2 out of 2 time on 2nd set of pics.

[Yuv (yuv)]

can you post the set of pics that produce the bug somewhere?

[MNi (mni-tag)]

Download zip from here, please notify when it's ok to delete the link:

www.kolumbus.fi/~tpo04956/hugin-autoalign-busyloop.zip

Included a screenshot what hugin looks like when it's stuck. CPU show 100%, waited ~5 mins before terminating.

Steps to reproduce:

- Fire up hugin
- load images via assistant tab "1. Load images..." button
- align images with "2. Align..." button
- when fast preview window pops up, it may load 0....n scaled pics, before getting stuck. In the example, one pic managed to load.

Ensure you have File->Preferences->Assistant->Show preview->After align open: Fast preview window set.

[Frederic Da Vitoria (davitofrg)]

I had the same issue, but with different sequences: either by running the assistant (always when opening the Fast Preview), or by opening an already aligned project and trying to open the fast preview immediately. The bug was not quite consistent but almost, for example re-opening an already aligned project sometimes worked but usually it did not solve the issue. This happens only with fast preview, the "full/slow" preview never had issues.

Hugin 2011.0.0 / Windows Vista.

[Yuv (yuv)]

Thanks for the images set. I will give it a run on two, maybe three machines and see what it says.

All of you folks adding to this report: it would be helpful if you could report in detail:
1. what video card do you have
2. what driver, including detailed version number, you are using

There is a high probability that the problem you are experiencing is related to the video card driver / support for OpenGL functionality.

[MNi (mni-tag)]

1. Asus AH3650 Silent / 512M (AGP)
2. Ati 9.1.2008 version 8.452.0.0

I've deleted the pics, let me know if you need to re-download.

The Catalyst version is old, I know. Newer driver bundles refuse to recognize the card.

[Frederic Da Vitoria (davitofrg)]

NVIDIA GeForce 9300M GS, driver NVIDIA 7.15.11.7917

[Frederic Da Vitoria (davitofrg)]

I got the issue this evening. I had saved the pto before fast preview. I reloaded the pto and tried fast preview immediately and Hugin hanged. I reloaded the pto, removed a few bad points, re-optimized, and fast preview worked. I exited Hugin, reloaded the new pto and everything was fine. I exited Hugin, then reloaded the old pto and now fast preview worked too.

Conclusion: this bug seems to be influenced by what happened before, so I guess it could be indeed a driver issue. I could try finding and installing a new version, but I guess finding a solution in Hugin is better.

[Yuv (yuv)]

On July 3, 2011 06:04:24 pm Frederic Da Vitoria wrote:
> Conclusion: this bug seems to be influenced by what happened before,

since you exited and restarted Hugin, it is influenced by what happened before
*in the system*. That's something Hugin can't control/influence.

> I guess it could be indeed a driver issue. I could try finding and
> installing a new version, but I guess finding a solution in Hugin is
> better.

If what happened before is in the system and not in Hugin, it is unlikely that
a solution for this problem lies within Hugin since the problem lies outside
Hugin.

You reported driver version "7.15.11.7917". AFAIK this is not an nVidia
driver version number.

The latest nVidia driver for Windows is 275.33 and you can get it at
http://www.nvidia.com/Download/index.aspx

Googling for 7.15.11.7917 returns a more than two years old Dell repackaged
driver. Obsolete.

I strongly advise you to update the driver if you want to use Hugin. Please
report back your experience with the updated driver.

[MNi (mni-tag)]

What do you know, May-June this year AMD released a hotfix driver for HD 2xxx/3xxx/4xxx series, driver version now
8.861.0.0 (dated 24.5.2011).

Still both 2011.0.0 and 2011.2_beta went to busy loop, tried both once. Virtual or resident memory sizes are not growing, hugin sits just context switching, consuming 100% cpu.

[tduell (tduell-iinet)]

There are aspects of this that are similar to what I am seeing with hugin-2011.3.0 (hg02e5d9618f49) Fedora 15 x86_64, running Nvidia 9600GT and nouveau driver.
Sometimes Fast Panorama window opens with Overview pane/window (I'm guessing that is what it is called) blank. If the separator between FPW and Overview is dragged right some of the FPW image is displayed in Overview pane/window as a separate image. Toggling 'Show/Hide' will correct the display.
Attempts to reproduce the problem lead to varying results. Sometimes the FPW opens blank (after creating CPs and optimising, and selecting FPW icon) and cpu runs at 100%. FPW will not respond and it is necessary to force a quit.
Other times, the same steps lead to normal behaviour.

[Yuv (yuv)]

There is definitely at least one bug somewhere in the fast preview, and narrowing it down is the challenge.

I've been able to trigger a crash by playing intensively with the widgets on the fast preview. Not the kind of activity that would happen in the course of normal use, but definitely pointing to a robustness problem, maybe a memory leak. I simply switched randomly between projections and moved the FOV sliders. Over time the grid texture deteriorated visually. Then it crashed. Tried within gdb but got no stack trace.

Probably other textures are affected as well. I only saw the grid texture because I modified it to display a specific simplified pattern without transparency to exclude the grid generation as source of the error. The grid anyway does not display properly (see bug 804800 which may be another symptom of the same bug).

I suspect the bug was introduced with the last major work on the fast preview, the introduction of the overview pane in 2011.0.

We need to isolate it from other factors (e.g. drivers/video card) and find a way to (ideally) consistently reproduce it.

[蜥蜴 (f039281310)]

Same situation +1
Using hugin 2011.2.0.cf0eaefbe0dd built by Matthew Petroff Win7 64bit Nvidia GTX460 with driver 275.33 (updated 2011.06.01)
I don't have this problem until this morning. I've tried to re-install graphic driver and hugin but neither of this work.

[蜥蜴 (f039281310)]

I think I found a way that also prevent FPW crash. Originally, it crashes everytime I open it. But if I go to "image" tab and select one image each time until the thumbnail in the selected image area image shows for all image, FPW can now be opened successfully.

[MNi (mni-tag)]

If this helps...

After loading a set of pics, both automatic preview via Align button on assistant tab or using Images->Create Control Points + Optimizer->Optimize Now! + Fast preview button very likely (but not 100%, more like 90%) busyloop the preview window.

However, when creating control points manually, but before hitting Fast Preview button, save the project, exit Hugin, re-load project and after that Fast Preview works most of the time (again, not 100%).

[AB. (artem-bzr)]

I got the same problem. Windows XP sp3 pro + hugin 2011.0 + Ati Radeon 9600

[蜥蜴 (f039281310)]

I've found another way to avoid crash.
I'm trying to align three photo with different expusure setting and wish to make an exposure fused picure.But it crashes everytime I hit align just after loading images.
1. Using the method MNi provide at #17, I can now open the FPW (You still can do that and succeed with no alignment or CPs ).
2. With re-opened project and FPW window, hit align, let it generate CPs and auto align.
3. After all the work done, close hugin project without closing the FPW (e.g. that the FPW kill automatically)
4. The next time you start hugin, no matter from a shortcut, start manu, even any saved project, FPW will opened automatically. If you're starting a new project, it shows a black background. But things will get normal.

BTW, there's something interesting. Everytime it get stuck, the CPU usage will also stuck at 25%. And the calculation will evenly distribute to (in my case) all 4 CPU cores. I can't tell why but it might help? The simular situation occured at clean control points, please check Bug #813423.

[MNi (mni-tag)]

AB, developers probably would like to see:

1. exact version of hugin (Help->About) e.g. 2011.0.0.0fd3e119979c built by Matthew Petroff
2. exact version of video driver you're using for the Radeon 9600

[Yuv (yuv)]

What would help development is if you find a way to reproduce the bug as consistently as possible (it's a pesky one, but chances are that the same sequence of events will trigger the bug on the same machine) and then try that very same sequence of events with 2010.4.0. If the bug does not occur with 2010.4.0, you have helped narrowing down where the problem is.

[蜥蜴 (f039281310)]

Hugin works well until this sunday(July 17), after that everything is smashed including FPW,auto align, and clean control point. I even experienced a blue screen crash yesterday. So I decided to looking for changes in the system. I found that Adobe Shockwave Player(11.6.0.626) is the only change since July 16. So I uninstall it and the FPW seems can be open without crash. Can anybody help test that?

[Yuv (yuv)]

On July 21, 2011 12:36:30 AM 蜥蜴 wrote:
> Hugin works well until this sunday(July 17), after that everything is
> smashed including FPW,auto align, and clean control point. I even
> experienced a blue screen crash yesterday. So I decided to looking for
> changes in the system. I found that Adobe Shockwave Player(11.6.0.626)
> is the only change since July 16. So I uninstall it and the FPW seems
> can be open without crash. Can anybody help test that?

actually you could. Can you please re-install Adobe Shockwave Player, verify
that Hugin crashes properly, and then try different versions of Hugin on that
same system?

I assume you are currently using Hugin 2011.0.0 from
https://sourceforge.net/projects/hugin/files/hugin/

Please try 2010.4.0. If that one crashes as well, go back to earlier
versions. At each step, reset the Hugin preferences.

You may want to back up your current preferences, it is all in a Windows
registry key called Hugin. Sorry, I have been away from Windows for too long
to recall the exact key. Search for Hugin with Regedit and export it. Maybe
a Windows user reading this ticket can help you with more specific
instructions.

After testing in the past, please test in the future as well. There is a
2011.2.0-beta1 at the above mentioned location too.

Last but not least, repeat the tests without Shockwave Player.

I am relatively confident that Shockwave Player is not the culprit, but it
only brings this bug to manifest itself on your specific configuration.

Another variable you could test: hide the Overview pane in the FPW, restart
Hugin, and test. The status of the Overview pane is recorded in the
preferences for the next startup, and the Overview pane is the major new
feature introduced between 2010.4 and 2011.0. Both the FPW and Shockwave make
use of the video card and might clash on its memory handling which would
confirm some sort of memory leak.

You might have to uninstall Shockwave Player, hide the Overview, close Hugin,
reinstall Shockwave Player and test.

This is a lot of tedious work, sorry, but it is very important information to
collect and can help us identify the exact location in the Hugin codebase and
its timeline of the change that introduced the bug.

Once we zero in on that change, fixing it becomes easier.

Thanks
Yuv

>
> ** Attachment added: "blue screen crash file"
>
> https://bugs.launchpad.net/hugin/+bug/792896/+attachment/2222541/+files/cr
> ash.txt

[AB. (artem-bzr)]

I've tested Hugin 2011.0 official windows build (but now i went back to 2010.4.0.854952d82c8f which is working fine for me), drivers - catalyst 9.3 (Radeon 9600 xt).

[Yuv (yuv)]

Here is a video documenting what is likely another manifestation of this bug:
https://bugs.launchpad.net/hugin/+bug/803080/+attachment/2183861/+files/SDC15688.MP4

It is from bug 803080 which I marked as a duplicate of this bug.

[Yuv (yuv)]

This is a repeat of information that I posted to hugin-ptx. Here on the tracker is the right place to contribute/discuss this bug.

This bug is most likely caused by a memory leak and the most difficult part of fixing a memory leak is to identify where it happens.

Here is a strategy and a plan. We will need to pull this together if we want to succeed.

1) Strategy

In a nutshell: identify the range of revisions that are likely to contain the error and narrow it down with a binary tree search. Split the revision range in two, build and test the version in the middle. If the error is present, we know it is in the earlier revisions range. Else in the later. Take the identified narrower revision range and repeat the process. There is a high likelyhood that after about eight repetitions the source of the error is identified.

In detail:

Today, we are at revision 5435. It is most likely that the bug was introduced after 2010.4 was released. Revision 4780 is 2010.4 final.

So the error is most likely between 4780 and 5435. That would be 656 different versions of Hugin, but it is much less than that: many of these changesets are not on the default branch.

2) The plan

List the relevant changesets on the default branch:

hg log -b default -r4780:tip --template 'r: {rev}\n' > revlist.txt

That's 448 changesets to examine.

Start from the middle, i.e. the 224th changeset in that list. build that version and try to trigger the error. If the bug is there, it is likely to be in the newer half of the list. If not, in the older half. Rebuild the list, now 224 entries long, and cut it in half again. Repeat.

With such a binary strategy, we should zero in on the bug in a maximum of eight iterations.

224, 112, 56, 28, 14, 7, 4, 2, 1

I can produce eight such tarball releases in about 16 hours (takes about two hours per tarball). However I can not move forward until I get feedback on a tarball to tell me whether the subsequent tarball to build is in the earlier or later half.

I need your help.

Help from builders to turn the tarballs into binaries for their respective platforms so that tester, especially those who have been particularly "lucky" at triggering the bug, can take those binaries on a test drive and provide feedback as to whether they can trigger the bug or not.

Please build binaries and make them available. Instructions at [1].

I am available to the project for another six weeks, after wich I won't have time. That's less than one tarball per week. The process of releasing a tarball is not that difficult and well documented [2]. So are the processes to build binaries for the different platforms [1]. This means that others, (*you*?) could step in. We can only move as fast on this process as the feedback that we get.

I have produced the first tarball [3]. I will produce the next one (from the earlier half or the later half) as soon as there are enough test results to make a reasonable guess regarding the bug's presence. If we oil this mechanism fast enough, we can get it done in a few weeks.

These are the steps I did, in case somebody wants to step in my shoes. This would be helpful for the continuation of the proc...

[tduell (tduell-iinet)]

rev 5057 exhibits the bug in Fedora 15 x86_64

[Yuv (yuv)]

thanks, Terry.

next cut in the middle of the earlier half, then:

 hg log -b default -r4780:5057 --template 'r: {rev}\n'

that's rev 4921

tarball at https://sourceforge.net/projects/hugin/files/hugin/pesky-bug/hugin-2010.5.0.4921.tar.bz2/download

[tduell (tduell-iinet)]

Just built and ran 4921 on Fedora 15 x86_64 with the same project as previously.
Following alignment the FPW opens, the pano is displayed (a bit different to the way it normally fails here), but the FPW is non-responsive and very quickly disappears.
I think we can say this one has the bug.

Cheers,

[tduell (tduell-iinet)]

I have just built and tested rev 4847 and the FPW exhibits the same behaviour as 4921, so we need to look even earlier.
Note that if you are now using gcc-4.6.0, attempting to build 4847 (and probably also earlier revs) will require Bruno's patch that was added in changeset 4893 (added stddef.h to src/foreign/vigra/vigra/multi_iterator.hxx).
I will now try rev 4814.

Cheers,

[tduell (tduell-iinet)]

I have just built and tested 4814 and I get the same bad FPW behaviour.
I will now go back to 4798.

Cheers,

[Yuv (yuv)]

to apply Bruno's patch I do
  hg export --git 4893 | hg import -

just after
  hg up -r <REV>

for revision < 4893.

not many revisions left before 4798:

  hg log -b default -r 4780:4798 --template '{rev}, '

4781, 4782, 4783, 4784, 4785, 4786, 4787, 4788, 4789, 4790, 4791, 4796, 4797, 4798

Terry, have you tried patching and building 2010.4?

Also, has anything changed recently to the PC on which you are experiencing the bug?

[tduell (tduell-iinet)]

Well, I think we are getting close.
I have just built and tested 4798 and it appears to be OK.
In all my previous builds in this exercise, the FPW has been broken at the outset...either it opens blank and unresponsive then system asks if I want to force a quit, or it opens with pano displayed and unresponsive and then crashes.
With this build the FPW does everything I have asked it do.
The problem may still be there but now harder to invoke, but I think the best approach is for me to move forward now to (say) 4805 or thereabouts (I will look at the change comments and select on the basis of what has been changed) and see how it behaves. If it immediately shows the problem then I think we can be sure that 4798 really is OK.

Cheers,

[tduell (tduell-iinet)]

Hullo Yuv,
No I haven't tried 2010.4 yet, that did cross my mind.
Having just seen 4798 work OK, may answer your questions.
Let me try 4805 of thereabouts and see how I go. It doesn't take me too long.

Cheers,

[tduell (tduell-iinet)]

Just built and tested 4810, and FPW fails immediately I try to select anything.
Looks to me like the problem has been introduced with the overview mode.

Cheers,

[tduell (tduell-iinet)]

Just built and tested 4805 (just prior to overview branch being merged), and it behaves quite respectably.
One can't be 100% sure, but the way hugin has been behaving on my system when it does fail, and the way versions prior to the overview (4805, 4798) behave, it does look like 'something' in the overview mode code is the culprit.

How to do we best go about narrowing that down?

Cheers,

[tduell (tduell-iinet)]

Hullo Yuv,
Just for the record, when I used your suggested method of applying Bruno's patch to rev prior to 4893...

to apply Bruno's patch I do
   hg export --git 4893 | hg import -

just after
   hg up -r <REV>

I ended with rev 5437 as the tip, ie my hg repo now believes Bruno's patch has been the last revision.
Not sure if really matters much, but leaves me a bit confused about the right way to do it and if my result is expected behaviour.

Cheers,

[Yuv (yuv)]

Lukáš has an hypothesis on the hugin-ptx mailing list. This could be a threading issue.

Can those of you experiencing the bug please report how many cores and threads your CPU have?

The only machine that could trigger an error here is my netbook. Intel Core i3 380UM, dual core and hyperthreading = four threads.

Never seen the error on my two other machines. Both have two threads. My aging workstation has an AMD X2 and my HTPC has an Intel Atom with hyperthreading.

So, folks, how many threads does your CPU have?

[Yuv (yuv)]

bug 792717 may be another manifestation of a threading conflict that confirms Lukáš hypothesis . Images are loaded in cache in a separate thread since revision 4524. Might be conflicting with other threads?

[Yuv (yuv)]

We are using at least two threading libraries:
* The ImageCache introduced a dependency on boost threads at rev 4524
* cpfind uses zthreads introduced with the gsoc2010_patent_free_cpm development branch

could it be a conflict between the two?

[Yuv (yuv)]

Any Mac OS X user also affected? bug 814301 reports that Hugin 2010.2.0 works well at detecting CPs while 2011.0.1 does not.

History of CP detectors:

2010.2.0: technically speaking, Hugin did not detect CP. A third party tool did. Most user used Autopano-SIFT-C. Some users used a lesser known and faster tool, Panomatic. Both tools are encumbered by patents, it is the user's responsibility to make sure that they are allowed to use them in their jurisdiction.

2010.4.0: first release of Hugin's own CP detector, cpfind.

2011.0.0: cpfind improved and AFAIK it is superior to any tool previously used with Hugin.

And looking at it from a threading perspective:
* Autopano-SIFT-C does not use multi-threading
* Panomatic uses zthreads for multi-threading
* cpfind uses zthreads for multi-threading

could this be another manifestation of this pesky bug? could it be a bug in zthreads?

[tduell (tduell-iinet)]

Re the ques: how many cores and threads?
I am running an AMD Phenom 955, 4 core, which I think runs one thread per core.

[tduell (tduell-iinet)]

Not sure if this throws any more light on the problem.
Running a build of the default:tip, the FPW problem almost always occurs using CPfind.
If I use Autopano-Sift-C as my default CPD, whilst it makes a bit of a hash of the CPs on my test project, the FPW opens without any problems...or perhaps I should say, I haven't been able to get any to show themselves.

[tduell (tduell-iinet)]

I have been doing a bit of checking on zthread.
The version bundled with hugin is 2.3.1 which was released in 08-2003. The current version is 2.3.2, released in 03-2005.
Not sure what changes were introduced in 2.3.2.
If there is a suspicion that zthread may be involved in this bug, is it worth attempting to use ver. 2.3.2 to see if it makes any difference?
Probably useful to see the changes in this version before trying this.
Does anyone know if the zthread source is simply used 'as-is' in hugin?

[Andrew Happ (andyh77777)]

I have just started trying to use Hugin (and to play with panoramas), so I am still attempting to differentiate between bug experiences and my naïve understanding of how things should work.

I have found though, that if I switch off the default preference “Remove outlying control points by statistical method” then the FPW is more likely not to hang. (found at Preferences\Assistant).

Windows XP Pro SP3 – GeForce 9600GT – Drv Nvidia 275.33
Hugin 2011.0.0.0fd3e119979c

[Henk Tijdink (h-tijdink)]

I'm running on windows XP sp3 32 bits. Unfortunately I can't build Hugin. After a lot of tries had given it up.
But I tested it. On my system Hugin crashes only when using the assistant opening the preview.
When using generate controlpoints, optimising the FPW gives no crash and I can use it normal.

[Arto Huotari (roskapostiaminulle)]

About #803080 which is marked as duplicate of this bug.

https://bugs.launchpad.net/hugin/+bug/803080

I have been a bit slow but I finally got around thinking that the behavior looked like that the GUI does not know which to draw, preview or window. So I turned of the 3D effects from the

system-> preferences -> appearance -> visual effects -> none (was previously extra).

After this the preview window draws correctly.

In short to layman it seems that the OpenGL window drawing is colliding with the drawing of the preview or the window is drawn on top of preview i.e Hugin draws the preview but the system refreshes the window on top of the preview. This would explain why the preview is shown only when user interacts with it.

If this works in Ubuntu 11.04 then it may be a problem also in Ubuntu's GUI libraries, not Hugin. Visually behavior reminds me of the Adobe Flash flickering which is also present (again) in my 64 bit 10.04 system.

Sorry it took so long for me to think about this.

Arto Huotari

[Julian King (jking-phys)]

I can confirm this is a problem at 30th July 2011, with ATI latest drivers (Catalyst 11.7), on a Radeon 5850.

The problem occurs every time - I am unable to get the fast preview window to load, even after just loading a single JPG or TIFF image (i.e. open hugin, add one image through the assistant OR manually add the image, click fast preview) almost every time. The fast preview window does not fully draw and Hugin locks up.

This occurs with both the release version of 2011.0 and "2011.2.0.ca00bb7b3e88 built by Matthew Petroff"

However, once I got the fast preview open, I disabled (hid) the overview, and it now seems to work fine.

As suggested above, this makes it look like the problem is with the overview.

[Arto Huotari (roskapostiaminulle)]

Here is a screen shot (Ubuntu 10.04) where the GUI element of the Panosphere is hidden. Some of the menus and slider bars are still drawn though even though I have hidden the Overview window. Similarly after returning the visibility of the over view there are extra elements now in the window.

[Arto Huotari (roskapostiaminulle)]

Still about possible duplicate #803080
bugs.launchpad.net/hugin/+bug/803080

When the quick preview window is open under the main window and the preview is refreshed for some reason (e.g. in this case Calculate field of view) the preview window update flashes through the main window even though the preview window does not pop up to top. See attached screen shot. So even though this is a quick flicker only it is possible to get a screen shot of the action.

[Arto Huotari (roskapostiaminulle)]

Sorry, forgot the screen shot attachment for previous post.

[蜥蜴 (f039281310)]

On my computer, cpclean also stuck, too.(But the cpfind did use full power of CPU ) I think its related to thread handling.
vedio:
http://www.youtube.com/watch?v=Pa88mZNAGyk
Using pre-built version 2011.2.0.ca00bb7b3e88 built by Matthew Petroff on WIN7 64bit, AMD 965, GTX460 with latest driver.
I don't have the capability to fix that, hope this will help.

[tduell (tduell-iinet)]

Running 'valgrind --tool=helgrind hugin' on Fedora 15 x86_64, with hugin-2011.3.0.076c3e64f1dc and with the debuginfo rpm installed, the FPW opened blank and when I tried to resize hugin crashed.
The output of the valgrind command is attached as file valgrind-out.txt.
I am not experienced in interpreting valgrind output, but there does seem to be a lot of references to 'GLPreviewFrame::panoramaImagesChanged(...' in relation to possible data race during write.
Hope this helps track down the little Bugger.

Cheers,
Terry

[Bruno Postle (brunopostle)]

Just adding my experience:

I don't see this bug at all on fedora, though I run Hugin on a single core laptop and a single CPU VM so I wouldn't encounter the bug if it was a threading/multicore issue.

I had a chance a couple of days ago to try a recent Windows snapshot on a two-core macbook runnning windows:

cpfind crashed randomly, matching two photos was ok, but four photos crashed about 50% of the time.

The fast preview crashed Hugin repeatedly. I got it working by launching Hugin with an empty project, and disabling the overview in the fast preview using the Show/Hide button, after this the preview was fine. Note that the overview had to be disabled immediately, just resizing or moving the fast preview window caused a crash.

After this it was even possible to create a project then enable and use the overview in the fast preview, however if I closed Hugin with the overview enabled then Hugin was broken again after restarting.

[Yuv (yuv)]

I updated the bug description [0] with a:
* Workaround
* Affected Systems
* Affected Version
* Summary for Developers/Bug Hunters

to those experiencing the bug: can you please try the workaround and report back attempts to trigger the bug?

thanks

[tduell (tduell-iinet)]

Running 2011.3.0.076c3e64f1dc on Fedora 15 x86_64.
I can load a project and open FPW, and the overview is hidden, i.e. I haven't had to change the setting, and it is all OK. Then quit hugin and restart, load project and open FPW and it is frozen, quit hugin, restart, load project, open FPW window and all is OK.
If the workaround is to prevent the FPW opening with overview shown in the expectation that this will prevent the problem, then that isn't my experience.

[蜥蜴 (f039281310)]

With 2011.2.0.ca00bb7b3e88 built by Matthew Petroff, win7_x64, AMD 965. The workaround didn't work for me.
I start hugin, load a project with two photos and some CPs, no alignment. Then open FPW, uncheck grid box and hide the overview ,close FPW ,close project. Start hugin and load the same project again, hit alignment ,the FPW opened and hugin crashes immediately.

[Yuv (yuv)]

On August 7, 2011 03:15:48 am 蜥蜴 wrote:
> With 2011.2.0.ca00bb7b3e88 built by Matthew Petroff, win7_x64, AMD 965. The
> workaround didn't work for me.

2011.2.0.ca00bb7b3e88 aka 2011.2 RC2 is fraught with other errors - Matthew
experimented with a new Windows SDK. Can you please try with an earlier
release candidate or beta of 2011.2 ?

Also, given your comment on bug 813423 I am inclined to think that you are
experiencing two different bugs and that actually the workaround worked for
you (second project).

[MNi (mni-tag)]

Sorry, been awol for some time.

> to those experiencing the bug: can you please try the workaround and
> report back attempts to trigger the bug?

Tried quickly 3 sets of 5-6 pics each, the workaround did work for me on 2011.0.0.0fd3e119979c built by Matthew Petroff.

Though I'm running on a AMD Athlon 3200+, which is a single-core, single-thread issue, so the bug is not confined to multi-threaded processors.

[Yuv (yuv)]

On August 7, 2011 04:13:29 pm MNi wrote:
> Tried quickly 3 sets of 5-6 pics each, the workaround did work for me on
> 2011.0.0.0fd3e119979c built by Matthew Petroff.

thanks for testing.

> Though I'm running on a AMD Athlon 3200+, which is a single-core,
> single-thread issue, so the bug is not confined to multi-threaded
> processors.

You are experiencing the bug on the AMD Athlon 3200+ when the overview is
enabled? what video card is on your system? and what driver?

[MNi (mni-tag)]

The same as previously, see <a href="https://bugs.launchpad.net/hugin/+bug/792896/comments/8">#8</a> and <a href="https://bugs.launchpad.net/hugin/+bug/792896/comments/12">#12</a>

[蜥蜴 (f039281310)]

>Yuv (yuv) wrote on 2011-08-07:
>2011.2.0.ca00bb7b3e88 aka 2011.2 RC2 is fraught with other errors - Matthew
>experimented with a new Windows SDK. Can you please try with an earlier
>elease candidate or beta of 2011.2 ?

Thanks for your hint. I've back to 2011.2.0.cf0eaefbe0dd built by Matthew Petroff (that's prebuilt beta1) and the workflow works !
Can't trigger FPW carsh so far. I'm on Win7_x64/ 14GB RAM/ AMD 965(4 core)/ NVidia 460/ tested with 120 photoes.

[Arto Huotari (roskapostiaminulle)]

Still about possible duplicate #803080
bugs.launchpad.net/hugin/+bug/803080

Suggested workaround does not fix this issue. Behaviour of the preview is maybe slightly improved but remains largely unusable.

Ubuntu 10.04 Proprietary ATI drivers.

[Arto Huotari (roskapostiaminulle)]

Still about possible duplicate #803080
https://bugs.launchpad.net/hugin/+bug/803080

I checked the Synaptic and there was

2011.3.0.e99d26a82214

Behavior is the same.

[Daniel (78luphr0rnk2nuqimstywepo-launchpad)]

Just wanted to add that setting the CPU affinity worked around the problem for me.
Hope that helps some people out.

Program Version: 2011.0.0.0fd3e119979c built by Matthew Petroff
Card: nVidia GT 240
Driver version 275.33
OS: Windows 7
CPU: P4 w/HT

[Yuv (yuv)]

On August 12, 2011 01:48:57 am Daniel wrote:
> Just wanted to add that setting the CPU affinity worked around the problem
> for me. Hope that helps some people out.

Thank you! Yes this helps a lot. It confirms that the issue is one of
threading, probably expiring cache. And there are ways for the program itself
to request affinity.

I suspect that somebody at Apple though about this and affinity is ON by
default - would explain why Apple is so unaffected. I did not research links
to substantiate my hypothesis. Windows systems tend to have more threads
running around (antivirus!) which would explain why the cache expires/corrupts
more often.

On Linux we can use something like
* http://www.ibm.com/developerworks/linux/library/l-affinity/index.html
* http://www.linuxjournal.com/article/6799

And on Windows something like
* http://msdn.microsoft.com/en-us/library/ms686223%28v=vs.85%29.aspx

For the short term:
* Linux http://www.linuxcommand.org/man_pages/taskset1.html
* Windows http://www.addictivetips.com/windows-tips/how-to-set-processor-
affinity-to-an-application-in-windows/

Performance trade-off:
* https://lanvu.wordpress.com/tag/setprocessaffinitymask/

Now it is a matter of time to implement and test...

[Lukas Jirkovsky (l-jirkovsky)]

I was able to identify two bugs plaguing the fast preview.

A first one is a hang in libpano math.c, line 297:
        while( *x_src > var0 )
                *x_src -= 2 * var0;
because *x_src = 2.17213129256892e+98 and var0 = 13652.608695652176. If my computations are correct, *x_src never changes because of the underflow. I'm able to reproduce this problem with one panorama in approximately one quarter of tests.

The other one is the same crash for which Terry already provided backtrace using hellgrind. I was able to reproduce it twice, but after adding some debug statements I was not able to reproduce it so far.

Atached is the gdb backtrace for both issues.

[Bogdan Marinov (daggerstab)]

The workaround described in the current description of the bug doesn't work for me (Windows XP SP3, netbook with dual Atom processors/cores). I was able to switch off the overview window by editing the Registry.

Workaround for Windows users:
1. Open the Registry Editor
2. Open HKEY_CURRENT_USER\Software\hugin\GLPreviewFrame
3. Change the value of the "overview_hidden" key to 1
4. Change the value of the "showPreviewGrid" key to 0 (you don't need the grid and you can't turn it off when the overview window is hidden)

By the way, there are three different naming schemes used in that settings ("showPreviewGrid" but "ShowProjectionPoints" and "overview_hidden"). Consistency is usually a nice thing. :)

[Bruno Postle (brunopostle)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat 20-Aug-2011 at 09:43 -0000, Lukas Jirkovsky wrote:
>
> A first one is a hang in libpano math.c, line 297:
> while( *x_src > var0 )
> *x_src -= 2 * var0;
> because *x_src = 2.17213129256892e+98 and var0 =
> 13652.608695652176. If my computations are correct, *x_src never
> changes because of the underflow. I'm able to reproduce this
> problem with one panorama in approximately one quarter of tests.

I don't see this bug in action even though it is clearly asking for
trouble. Could it only appear on a particular architecture? or
maybe there is something in the default fedora gcc flags that
prevents the underflow.

Can you provide a patch for libpano13?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFOZoJ0FqOhwCjyCLoRAh1RAKCbgqX76YW/qjAS6C7LsjMaLJl0SQCguDf1
8d/0Ku+qbc+FCAkD9EtWTKU=
=76/c
-----END PGP SIGNATURE-----

[Lukas Jirkovsky (l-jirkovsky)]

Bruno, I think it just another manifestation of this bug. Normally the x_src has a much lower value and the optimization works. However sometimes it seems to be uninitialized which can result in the hang I mentioned.

However it might be a good idea to use a variable size step. It would also result in faster convergence in cases when there's a big difference between x_src and var0

[tmodes (tmodes)]

Please test changeset b9bbb678382d: initialize some variables. I hope, that this prevents the calling of the transformation with such big values.

[tduell (tduell-iinet)]

No sign of it thus far, with 2011.0.3-5578:9e51e7ef8fc7, which is a good sign.
My system had been quite sensitive to it, and this version has not shown any problems.

[Felix Hagemann (flixh)]

Trying with 5584:9d07d4165d4 improves the situation dramatically. On a
machine where hugin was freezing immediately when opening the FPW, it
seems to be very stable now.
I have been able to crash it only ones by clicking the FPW icon
quickly after startup when it segfaulted. Have not been able to
reproduce.

There is one strange behaviour which I have not noticed yet: The
overview only shows a black sphere when photometric correction is
enabled. Disabling this AND clicking and dragging in the overview
window updates the display and the panorama is visible again. Should I
file as a new bug?

[tmodes (tmodes)]

Hi Felix,

thanks for report. That sound promising.

For the other issue, please open new ticket. I observed also a similar behaviour, but had not yet the time to track it down.

[Othmar Marti (othmar-marti)]

I downloaded 2011.2.0.3d9649aa241a built by Matthew Petroff and have not experienced a crash so far. The fast preview seems to much more stable.

Thanks to all!

Othmar

[Heiko (hbcs)]

No more problems with 2011.2.0.3d9649aa241a built by Matthew Petroff.
Great work, thank you!

[IanJ (ian-jeffray)]

With 2011.2.0.3d9649aa241a built by Matthew Petroff, this still happens on my Win7/x64 Core i7 system.

This did *NOT* happen until a recent upgrade to my NVidia GT240 drivers (Driver version 296.10)

The workaround half works. It stops the hang, but the preview display is corrupt until the overview panel is displayed.

[IanJ (ian-jeffray)]

Damn. CnP error.
The version I'm using and seeing the fault with is the latest release... 2011.4.0.cf9be9344356 built by Matthew Petroff

[Bernd Kreuss (prof7bit)]

Out of desperation I am trying to run the nightly ppa in Xubuntu 12.04,
hugin version 2012.0.0.3ba19f267f7a (came from that nightly repository this morning)

It will not crash when the overview is not visible but unfortunately the workaround works only once after deleting the .hugin file, disabling the overview while the window is only 200 pixels high allows me to maximize it and use it without a crash but on the next restart of hugin it will always crash. The only way to repeat the workaround is to start again after deleting the config file ~/.hugin

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) backtrace
#0 0x00000000 in ?? ()
#1 0x081e90ec in OverviewOutlinesTool::draw() ()
#2 0x081e33cb in PanosphereOverviewToolHelper::AfterDrawImagesBack() ()
#3 0x08187629 in GLPanosphereOverviewRenderer::Redraw() ()
#4 0x08185caf in GLViewer::Redraw() ()
#5 0x08185ede in GLViewer::RedrawE(wxPaintEvent&) ()
[..]

someone narrowed it down here: https://bugs.launchpad.net/ubuntu/+source/hugin/+bug/901755
to a call to glBlendEquation() (see posts 7 and 8 in that other bug report)

If it really can't be fixed, maybe change it so that this overview window wont be visible by default.

My hardware is an IBM Thinkpad T40 with onboard ATI graphics and the open ource radeon driver, opengl is working flawlessly with all other applications (maybe one of the devs knows someone who still has one of these laptops around for testing, they were quite popular once and many people are still using them today)

[Bernd Kreuss (prof7bit)]

btw: how is this bug status "fix released" when it is not fixed yet, not even in nightly builds?

[Bernd Kreuss (prof7bit)]

Ok, here is some more information.

I removed the nightly and instead added the official hugin/next repository from launchpad. Everything that I write now refers to this version. To retrieve the backtrace I did the following:

$ sudo apt-get build-dep hugin
$ apt-get source hugin

$ cd hugin-2012.0.0~beta1+dfsg
$ geany debian/rules
and comment the line dh_strip around line 162 to build it with debugging symbols

$ dpkg-buildpackage -us -uc -nc
Build it and create .deb packages

$ sudo dpkg -i ../hugin*.deb
Install them

$ gdb hugin
(gdb) run

provole the crash (just open the fast preview and if it does not yert crash on its own then enable the Overview, this will surely crash it)

(gdb) backtrace
Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) backtrace
#0 0x00000000 in ?? ()
#1 0x081e91ac in OverviewOutlinesTool::draw (this=0x8c198a8)
    at /home/bernd/hugin-2012.0.0~beta1+dfsg/src/hugin1/hugin/OverviewOutlinesTool.cpp:194
#2 0x081e348b in PanosphereOverviewToolHelper::AfterDrawImagesBack (this=0x91d6e10)
    at /home/bernd/hugin-2012.0.0~beta1+dfsg/src/hugin1/hugin/ToolHelper.cpp:706
#3 0x081876e9 in GLPanosphereOverviewRenderer::Redraw (this=0x8ffe7c0)
    at /home/bernd/hugin-2012.0.0~beta1+dfsg/src/hugin1/hugin/GLRenderer.cpp:312

OverviewOutlinesTool.cpp:194 looks like this:

    glBlendEquation(GL_FUNC_ADD);

comment it (because GL_FUNC_ADD is the default anyways)

    // glBlendEquation(GL_FUNC_ADD);

now I built the package with this modification (I have no idea how to convince dpkg-buildpackage to just recompile what was modified, I can either clean everything with -Tclean and rebuild from scratch or it won't compile anything at all, probably just a file I would need to touch but I don't know which one)

The patched version works like a charm, it will not crash and I can even *use* the Overview globe (which I have seen for the first time today and which is a very nice feature), everything is working perfectly well!

Developers: I can reproduce the crash everytime and I have now set up the environment to build from source (based on this launchpad source package) and If you want me to insert debugging code to catch this exception and log various stuff of interest on my system to investigate what exactly is going on then please tell me, send me a patch (post it here) and I will apply and test and report back.