abrt 1.0.4 detected a crash. architecture: x86_64 Attached file: backtrace cmdline: hugin component: hugin executable: /usr/bin/hugin kernel: 2.6.31.12-174.2.3.fc12.x86_64 package: hugin-2009.4.0-0.fc12 rating: 4 reason: Process was terminated by signal 11 (Segmentation fault) release: Fedora release 12 (Constantine) How to reproduce ----- 1. Open hugin 2. Close Tip of the day 3. Crash!
Created attachment 389135 [details] File: backtrace
Hi, I'll have to close this because f12 has hugin-2009.2.0, so this isn't a fedora bug. However it looks like you are using an RPM from my 'panorama' testing repository, so I'd like to know the answer to these questions: Signal 11 is often an intermittent problem, do you get this crash every time you launch Hugin? If the crash is reproducible, does renaming or moving the ~/.hugin preferences file fix Hugin? (Don't delete it, because I would like a copy if this is the problem).
Yes, I am using your RPM, because I have exactly the same problem with hugin-2009.2.0 of the Fedora repository, so I tryed it to see if something change. It crash every time I start hugin with the same error. With or without /.hugin This is the content of my ~/.hugin HuginRevision=4742 [AutoPano] AutoPanoCount=4 Default=0 [AutoPano/AutoPano_0] Type=1 Description=Autopano-SIFT-C Program=autopano-noop.sh Arguments=--maxmatches %p --projection %f,%v %o %i [AutoPano/AutoPano_1] Type=1 Description=Panomatic Program=panomatic Arguments=-o %o %i [AutoPano/AutoPano_2] Type=1 Description=Match-n-shift Program=match-n-shift Arguments=-b -a -f %f -v %v -c -p %p -o %o %i [AutoPano/AutoPano_3] Type=1 Description=Align image stack Program=align_image_stack Arguments=-f %v -p %o %i I hope it may help.
I've just tested on a clean install of F12, the default hugin-2009.2.0 works for me. On F11 I had problems with the ATI graphics drivers, I see that you are running the nvidia drivers: /usr/lib64/nvidia/libGLcore.so.1 I would like to exclude this as the problem, can you switch to the default xorg-x11-drv-nouveau driver and see if this fixes it?
You are right, with the nouveau driver it works fine. Thanks
I have the same problem here. Also using the nvidia accelerated driver. It broke sometime after Feb 04th (I used Hugin that day and it worked fine) I looked at my yum.log, there's been lots of packages updated since that date ...
So ... Is this bug to be sorted out here ? Or should it be submitted to Hugin ? to NVidia ?
By the way, here's some info, for what it's worth ... On my machine, Hugin was working fine on Feb 4th and on Feb 14th wasn't working anymore ... When I grep in my yum.log, I see that between those dates, I've had no Hugin update no xorg update no nvidia driver update no kernel update So ... Could this new failure be tied to another package being updated during this period ? (gtk2, libXi, xorg-evdev, glib2, libstdc++)
Hi Vincent, I'd really like you to confirm the bug with the nouveau driver, it should be easy enough to switch back if you are using the rpmfusion nvidia driver. Unfortunately if it really is the closed-source nvidia driver there is not much we can do, I'm not capable of debugging it, and I know that this isn't the sort of problem other developers are interested-in. Yes it could be that the trigger was some other library update such as xorg, in which case a rebuild might help, you could also try fetching the hugin src.rpm and rebuilding it.
Hi Bruno, Ok, I have some news ... I recompiled hugin from the src.rpm and it crashed all the same. I switched to using the nouveau driver and to my surprise it kept crashing ! I launched hugin using gdb and am attaching the backtrace. What I see is the frame #4 mentioning GLPreviewFrame. I have to explain that when my hugin worked, I used to have that Panorama GL preview window displayed on my second monitor ... And now that I've switched to using the nouveau driver, my second monitor isn't configured and I'm guessing Hugin is trying to re-open that window at some coordinates that are not available ... Do you know where this information could be saved ? it's not in the .hugin since I've deleted it ...
Created attachment 395705 [details] GDB stacktrace
well, in fact running hugin as another user (who never used hugin and therefore didn't have the GL Preview window placed anywhere particular) it also crashes ...
Thanks for trying all this. I see three possibilities: 1. Hugin is just broken for multiple-monitors on Linux, I can't see this as there would be more reports of problems. 2. Your graphics hardware is only supporting OpenGL on one monitor and this is triggering a crash. 3. Some window manager problem, are you using desktop effects (wobbly windows)? This only works with Intel hardware AFAIK. The window position is stored in the ~/.hugin file, there is usually no problem deleting this to reset the Hugin preferences. You can create a ~/.hugin file that contains just these lines and the 'Fast preview' will never be opened unless you click on the button to launch it: [GLPreviewFrame] isShown=0 [Assistant] PreviewWindow=0 Does this workaround let you use Hugin?
Hi Bruno, 1. It was working fine on dual-monitor earlier this month and switching to the nouveau driver and single monitor didn't fix the problem. 2. I have a Geforce 8400GS and have used OpenGL applications on both monitors without any problem ... That includes Hugin since I've used the GL Preview window on either monitor ... 3. I use KDE and have tried launching hugin with and without the Desktop Effects and compositing enabled (it does work with NVidia). And just to be sure, I also tried launching hugin from Gnome. I even tried launching hugin through SSH from a separate computer ... I tried to create a blank .hugin file with your suggested config but the problem remains :-( Is there anything I should trace to help the problem resolution ? I'm not familiar enough with gdb ...
Ok, I've finally figured it out ! Here's what was causing the failure. It seems that at some point, the NVidia driver from rpmfusion changed the location where it deployed the libraries ... in 190.42, they were in /usr/lib64 whereas in 190.53 they have moved to /usr/lib64/nvidia Apparently when the packages were updated from 190.42 to 190.53, the old ones were not removed ... The same applies for the Xorg extension modules ! and because I didn't have the following in my xorg.conf, it was using the 190.42 xorg module with the 190.53 libraries and GLX failed to load ... Section "Files" ModulePath "/usr/lib64/xorg/modules/extensions/nvidia" ModulePath "/usr/lib64/xorg/modules" EndSection Working like a charm now.
Great, hopefully this info will be useful for others.
*** Bug 575113 has been marked as a duplicate of this bug. ***
*** Bug 585415 has been marked as a duplicate of this bug. ***