Hi Tav :)
Let's go over the mechanics of the address sanitizer first.
Imagine a program like this:
int main() { int *p; { int x = 0; p = &x; } return *p; }
Compiling this with the sanitizer, then running it, will produce a stack_use_after_scope error and abort the program.
Let's pick apart the sanitizer dump.
================================================================= ==22156==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fff03896920 at pc 0x4617518 bp 0x7fff03896370 sp 0x7fff03896368
%rax = 0x7fff03896920 %pc = 0x4617518 %rbp = 0x7fff03896370 %rsp = 0x7fff03896368
The value that was attempted to be accessed (probably stored in $rax, but not entirely certain) is outside the range covered by [$rbp, $rsp] (remember, stack grows downwards). Kablam, sanitizer error.
WRITE of size 8 at 0x7fff03896920 thread T0 #0 0x4617517 in std::_Deque_baseGeom::Affine, std::allocator<Geom::Affine >::_Deque_impl::_Deque_impl() (/home/tavmjong/Sandbox_clang/bin/inkscape+0x4617517) #1 0x46170d7 in std::_Deque_baseGeom::Affine, std::allocator<Geom::Affine >::_Deque_base() (/home/tavmjong/Sandbox_clang/bin/inkscape+0x46170d7) #2 0x45fc91e in std::dequeGeom::Affine, std::allocator<Geom::Affine >::deque() (/home/tavmjong/Sandbox_clang/bin/inkscape+0x45fc91e)
At frame 0 the PC is one before the instruction of our crash—possibly an inlined function. The program attempted to write 8 bytes to the area that once existed on the stack ($rax, 0x7fff03896920). This is fairly interesting in itself since these are all calls to the C++ STL.
#3 0x4c0d983 in Inkscape::Extension::Internal::PrintMetafile::PrintMetafile() (/home/tavmjong/Sandbox_clang/bin/inkscape+0x4c0d983) #4 0x4b84106 in Inkscape::Extension::Internal::PrintEmf::PrintEmf() (/home/tavmjong/Sandbox_clang/bin/inkscape+0x4b84106) #5 0x4c0d434 in Inkscape::Extension::Internal::PrintEmf::init() (/home/tavmjong/Sandbox_clang/bin/inkscape+0x4c0d434) #6 0x4183e6a in Inkscape::Extension::init() (/home/tavmjong/Sandbox_clang/bin/inkscape+0x4183e6a)
...yawn.
Address 0x7fff03896920 is located in stack of thread T0 at offset 96 in frame #0 0x4c0d65f in Inkscape::Extension::Internal::PrintMetafile::PrintMetafile() (/home/tavmjong/Sandbox_clang/bin/inkscape+0x4c0d65f)
Now it starts to get interesting. PrintMetaFile() itself is an emtpy constructor, which means all the objects the class contains are initialized with their default values.
This frame has 4 object(s): [32, 40) '' [96, 176) '' <== Memory access at offset 96 is inside this variable [224, 232) '' [288, 292) ''
8 byte item (ulonglong, maybe, or some sort of struct) Class item (this is almost certainly part of the STL, possibly std::vector) 8 byte item 4 byte item (int? intptr_t?)
std::_Deque_base<Geom::Affine, std::allocator<Geom::Affine>
::_Deque_impl::_Deque_impl()
Shadow bytes around the buggy address: ... =>0x10006070ad20: f2 f2 f2 f2[f8]f8 f8 f8 f8 f8 f8 f8 00 00 f4 f4
The f8 in brackets is the address that was attempted to be used/dereferenced.
I can't really figure out too much beyond that without a core dump of the program. I need access to the contents of $rsp and $rip to really figure out what's going on here. I suggest you look at one constructor in particular though ;)
-- View this message in context: http://inkscape.13.x6.nabble.com/Clang-address-sanitizer-abort-tp4970295p497... Sent from the Inkscape - Dev mailing list archive at Nabble.com.