Digikam crashes when stitching 2 images i
Steps to Reproduce:
1. select 2 images in digikam
2. choose stitch images into panorama
3. press next on "welcome to panorama tool"
3. press next on list of selected images
4. press next to start preprocessing ("detect moving skies" is checked)
5. press next on image preprocessing is done ("level horizon" and "automatic projection ist checked"
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff81ffb700 (LWP 3310)]
__memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:2821
#0 __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:2821
#1 0x00007ffff26cb9bb in length (this=0x7fff9803abf0)
#2 replaceArgEscapes (s=..., d=..., field_width=0, arg=..., larg=...,
fillChar=...) at tools/qstring.cpp:6525
#3 0x00007ffff26cbb5d in QString::arg (this=0x7fff81ffa6b0, a=...,
fieldWidth=0, fillChar=...) at tools/qstring.cpp:6585
#4 0x00007ffff2cbd84b in KLocalizedString::subs (this=<optimized out>, a=...,
#5 0x00007fff77d4cfb5 in i18n<QString> (a1=...,
text=0x7fff77d5e9c0 "Unknown input file in the project file: %1")
#6 KIPIPanoramaPlugin::CreatePreviewTask::run (this=0xfbfb20)
#7 0x00007ffff49f105b in ThreadWeaver::JobRunHelper::runTheJob (
this=0x7fff81ffab00, th=0x63a8750, job=0xfbfb20)
#8 0x00007ffff49f11cc in ThreadWeaver::Job::execute (this=0xfbfb20,
th=0x63a8750) at ../../../threadweaver/Weaver/Job.cpp:135
#9 0x00007ffff49f21d3 in ThreadWeaver::JobCollectionJobRunner::execute (
#10 0x00007ffff49f081f in ThreadWeaver::ThreadRunHelper::run (
this=0x7fff81ffaba0, parent=0x649d8a0, th=0x63a8750)
#11 0x00007ffff49f08db in ThreadWeaver::Thread::run (this=0x63a8750)
#12 0x00007ffff268107b in QThreadPrivate::start (arg=0x63a8750)
#13 0x00007fffeca45e9a in start_thread (arg=0x7fff81ffb700)
#14 0x00007ffff18a8cbd in clone ()
#15 0x0000000000000000 in ?? ()
show preview window
does not happen when using panoramagui with the same images
The error happens at a very strange place, and I'm not sure if it is a problem with the panorama code. Can you provide the debug output also? Thanks.
Created attachment 77100 [details]
Created attachment 77101 [details]
Panorama temporary files
I cannot reproduce this bug with two images of a random panorama. Could you send me the original (by private email if you prefer) so that I can pinpoint the problem?
After investigation with your files, it appears that the segfault comes from non-ascii characters (accented characters for example) in the file paths. I confirmed this on my computer. This is a bug with the panorama plugin (maybe with the new parser) that will need to be fixed for a future version.
For now, the only way to use the plugin is to avoid non-ascii characters in file paths.
Typically, with Qt, to pass const char* string to C ANSI code and respect encoding, use QFile::encodeName() as here :
With KUrl, don't forget to use KUrl::toLocalFile() to prevent problem under Windows as here :
(In reply to comment #6)
> Typically, with Qt, to pass const char* string to C ANSI code and respect
> encoding, use QFile::encodeName() as here :
Thanks for the tip, this might be the problem (I'll look into it this week-end).
> With KUrl, don't forget to use KUrl::toLocalFile() to prevent problem under
> Windows as here :
I always use this function to get the file path, so for this part, it should be fine.
I confirm that there are no problems with the panorama plugin if I use an album path without german umlaute
Git commit b84ddbef6f43ec764fa975ba5c7b33d466ef720a by Benjamin Girault.
Committed on 02/03/2013 at 22:21.
Pushed by girault into branch 'master'.
Fixes char* filename conversion from and to QString
M +2 -3 panorama/ptoparser/ptofile.cpp
M +1 -1 panorama/ptoparser/tparser.c
M +1 -1 panorama/ptoparser/tparser.h
M +1 -1 panorama/ptoparser/tparserprivate.c
M +1 -1 panorama/ptoparser/tparserprivate.h
(In reply to comment #7)
> (In reply to comment #6)
> > Typically, with Qt, to pass const char* string to C ANSI code and respect
> > encoding, use QFile::encodeName() as here :
> Thanks for the tip, this might be the problem (I'll look into it this
For information, this was half of the problem. The other half was that a char* string of a filename needs to be converted into a QString with QString::fromLocal8Bit.