Summary: | krita crashes when opening or creating file | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | Andries Radu <admiral0> |
Component: | General | Assignee: | Krita Bugs <krita-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | cberger, halla, jacob.benoit.1 |
Priority: | NOR | ||
Version First Reported In: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Andries Radu
2008-12-07 12:45:20 UTC
Er... You're sure this happen when opening a file? Not when you're trying to use the selection eraser tool? Well. No. When i click on template, Then use this template, krita waits a moment then... crash Does it make a difference which template you select? No. I have tried almost all of them. Tried all profiles. Hm, that's really strange, since that doesn't happen to any of the developers. Which version of eigen are you using? And which distribution, processor type etc.? I use a debian lenny. Compile with gcc (Debian 4.3.2-1) 4.3.2 -march=core2 (Intel core 2 Duo 2.13GHz) Eigen is from kdesupport(trunk). Could you try without the march flag? Maybe there's a problem in eigen2 related to that. This is clearly a bug in Eigen: Explanation: Look at this: #6 0xb79a146d in Eigen::ei_pstore<double, double __vector> (to=0x97a8648, from=@0xbf8291e0) at /usr/lib/gcc/i486-linux-gnu/4.3.2/include/emmintrin.h:150 ei_pstore stores a 128-bit packet at a 128-bit-aligned location in memory. Except that.... the 'to' parameter passed to it here, 0x97a8648, is not a multiple of 128 bits == 16 bytes! (It should end with a 0 in hex!) Now let me scratch my head... And yes if you want a quick & dirty workaround until I fix it, removing the march flag will avoid the crash. Can you svn up Krita and retry? I think I fixed it in revision 893919. This actually wasn't Eigen's bug, though it is such a tricky aspect of Eigen that I'm ashamed of explaining it =) A KisVector2D (which is Eigen::Vector2d) consists of 2 doubles, which is 128 bits. Which is exactly the size of a SSE packet. So Eigen notices that, and starts using SSE instructions for all sorts of operations on these vectors. But SSE instructions (at least the ones that Eigen uses, which are the fast ones) require 128-bit alignment. Otherwise you get a SIGSEGV as was required here. For this reason, Eigen takes care by itself to require 128-bit alignment for KisVector2D, by doing two things: 1) Eigen requires 128-bit alignment for the KisVector2D's array (of 2 doubles). With GCC, this is done with a __attribute__ ((aligned(16))). 2) Eigen overloads the "operator new" of KisVector2D so it will always return 128-bit aligned pointers. Thus, normally, you don't have to worry about anything, Eigen handles alignment for you.... ... except in one case. When you have a struct like this, struct Foo { double x; KisVector2D v; }; and you construct a new Foo: Foo *f = new Foo; Then, since Foo doesn't have aligned operator new, the pointer foo is not necessarily 128-bit aligned. The alignment attribute of the member v is then relative to the start of the struct, foo. If the foo pointer wasn't aligned, then foo->v won't be aligned either! The solution is to let struct Foo have an aligned operator new. Eigen lets you do this as follows: struct Foo : Eigen::WithAlignedOperatorNew { double x; KisVector2D v; }; I just got an idea, I'll add an assert in KisVector2D's constructor to check for alignment. That hopefully will allow to catch these bugs more systematically :) SVN commit 893982 by bjacob: Make deluxe assertion with deluxe error message with link to deluxe web page for this very nasty bug (unaligned member in dynamically allocated struct) that our friends at Krita just encountered: http://bugs.kde.org/show_bug.cgi?id=177133 CCBUG:177133 M +11 -0 Eigen/src/Core/util/Memory.h A doc/UnalignedArrayAssert.dox WebSVN link: http://websvn.kde.org/?view=rev&revision=893982 It should be fixed now. It works. Great work. |