Hello
I have updated my Cairo branch today, as a step towards merging it. There is one new regression, namely feImage does not handle aspect ratio. It will be fixed before merging. IIRC, there is a problem with CMS output, the editing controls are not using custom XOR blending, and there are build failures on Windows. Does anyone remember any other bugs?
Regards, Krzysztof
On Fri, 2011-04-08 at 01:59 +0200, Krzysztof Kosiński wrote:
Hello
I have updated my Cairo branch today, as a step towards merging it.
Excellent!
There is one new regression, namely feImage does not handle aspect ratio. It will be fixed before merging.
I can have a look at this next week if you haven't already fixed it.
IIRC, there is a problem with CMS output, the editing controls are not using custom XOR blending, and there are build failures on Windows. Does anyone remember any other bugs?
I have seen a problem with clipping not working reliably (object sometimes just partially clipped) but I haven't had time to investigate.
Tav
2011/4/7 Krzysztof Kosiński <tweenk.pl@...400...>
Hello
I have updated my Cairo branch today, as a step towards merging it. There is one new regression, namely feImage does not handle aspect ratio. It will be fixed before merging. IIRC, there is a problem with CMS output, the editing controls are not using custom XOR blending, and there are build failures on Windows. Does anyone remember any other bugs?
Was building on OSX resolved as well? If not, that's still an outstanding bug too.
Cheers, Josh
On 8/4/11 19:40, Josh Andler wrote:
2011/4/7 Krzysztof Kosiński <tweenk.pl@...400...>
I have updated my Cairo branch today, as a step towards merging it. There is one new regression, namely feImage does not handle aspect ratio. It will be fixed before merging. IIRC, there is a problem with CMS output, the editing controls are not using custom XOR blending, and there are build failures on Windows. Does anyone remember any other bugs?
Was building on OSX resolved as well? If not, that's still an outstanding bug too.
Building r9582 of the gsoc-cairo branch on osx fails with the same error message as before. Has anyone tested on Windows?
~suv
On 8-4-2011 1:59, Krzysztof Kosiński wrote:
Hello
I have updated my Cairo branch today, as a step towards merging it. There is one new regression, namely feImage does not handle aspect ratio. It will be fixed before merging. IIRC, there is a problem with CMS output, the editing controls are not using custom XOR blending, and there are build failures on Windows.
Can you give specific people (like me :P) commit access, so I can help with the build problems?
Thanks, Johan
On 8-4-2011 22:30, Krzysztof Kosiński wrote:
2011/4/8 Johan Engelen<jbc.engelen@...2592...>:
Can you give specific people (like me :P) commit access, so I can help with the build problems?
Looks like there is now way in Launchpad to do this.
I'm not surprised...
I'm now uploading it with ~inkscape.dev as the owner.
Thanks. I've (temporarily) fixed the Windows build. I get a crash on startup and have to work around an assert. src/libnrtype/FontInstance.cpp, line 560: //g_assert(polyCurve->cpfx % 2 == 0); if (polyCurve->cpfx % 2 != 0) return;
One thing I noticed is funny: the diamond-shaped knots are not symmetric any more. The topleft edge is shorter than the others :) Not sure whether I like the "better looking" knots now. They look more part of the figure instead of part of the UI (the old ones are more pixelated, and 1 pixel stroked).
Ciao, Johan
W dniu 8 kwietnia 2011 22:37 użytkownik Johan Engelen <jbc.engelen@...2592...> napisał:
One thing I noticed is funny: the diamond-shaped knots are not symmetric any more. The topleft edge is shorter than the others :) Not sure whether I like the "better looking" knots now. They look more part of the figure instead of part of the UI (the old ones are more pixelated, and 1 pixel stroked).
Yes, the knots need fixing - the old display was better. It requires some pixel manipulation wizardry that cannot be duplicated using Cairo compositing operators, but I have this almost figured out.
The problem in FontInstance probably results from me gutting out raster_font completely - we are rendering the fonts as vector curves now. Even better would be to directly render the Pango layouts.
Regards, Krzysztof
W dniu 8 kwietnia 2011 22:30 użytkownik Krzysztof Kosiński <tweenk.pl@...400...> napisał:
Looks like there is no way in Launchpad to do this. I'm now uploading it with ~inkscape.dev as the owner.
The inkscape.dev-owned branch is now available at: lp:~inkscape.dev/inkscape/cairo-rendering
Regards, Krzysztof
On 8-4-2011 22:45, Krzysztof Kosiński wrote:
W dniu 8 kwietnia 2011 22:30 użytkownik Krzysztof Kosiński <tweenk.pl@...400...> napisał:
Looks like there is no way in Launchpad to do this. I'm now uploading it with ~inkscape.dev as the owner.
The inkscape.dev-owned branch is now available at: lp:~inkscape.dev/inkscape/cairo-rendering
Cool. I have committed my build fixing changes. One final required thing I did not commit: I disabled some code in win32.cpp to get a complete build. But it really needs to be fixed, instead of disabled. Can you look into this Krzysztof?
/src/extension/internal/win32.cpp line 316 line 334 etc, use pixblocks, and should be converted to cairo stuff.
Thanks! Johan
W dniu 8 kwietnia 2011 23:46 użytkownik Johan Engelen <jbc.engelen@...2592...> napisał:
Cool. I have committed my build fixing changes. One final required thing I did not commit: I disabled some code in win32.cpp to get a complete build. But it really needs to be fixed, instead of disabled. Can you look into this Krzysztof?
/src/extension/internal/win32.cpp line 316 line 334 etc, use pixblocks, and should be converted to cairo stuff.
This has something to do with printing. I thought we were using Cairo and GtkPrint for this. Does anyone know how printing is done on Windows?
Regards, Krzysztof
On 2011-04-09 0:12, Krzysztof Kosiński wrote:
W dniu 8 kwietnia 2011 23:46 użytkownik Johan Engelen <jbc.engelen@...2592...> napisał:
Cool. I have committed my build fixing changes. One final required thing I did not commit: I disabled some code in win32.cpp to get a complete build. But it really needs to be fixed, instead of disabled. Can you look into this Krzysztof?
/src/extension/internal/win32.cpp line 316 line 334 etc, use pixblocks, and should be converted to cairo stuff.
This has something to do with printing. I thought we were using Cairo and GtkPrint for this. Does anyone know how printing is done on Windows?
I just had a look (on Windows of course) and as far I can tell this code is unused. I can cut it out (as well as all relevant references and id's that I've been able to find) and I can still print. Apparently it used to have some function, and we even had a print preview and such, but I think at some point this was superseded by a new system and the old stuff was just left. In file.h there is even a comment that some print(preview) related functions are probably redundant, which apparently dates back to SVN(!!!) revision 1600-something.
In short: I'd like to try and cut out some of this apparently unused code, cleaning up our code base and "fixing" an issue with the cairo branch at the same time. But, it seems a little scary to just remove a whole lot of code that apparently at least used to have some function, so if anyone has a reason to keep this code around, please let me know.
On Sat, Apr 9, 2011 at 4:13 AM, Jasper van de Gronde < th.v.d.gronde@...528...> wrote:
On 2011-04-09 0:12, Krzysztof Kosiński wrote:
W dniu 8 kwietnia 2011 23:46 użytkownik Johan Engelen <jbc.engelen@...2592...> napisał:
Cool. I have committed my build fixing changes. One final required thing I did not commit: I disabled some code in
win32.cpp
to get a complete build. But it really needs to be fixed, instead of disabled. Can you look into this Krzysztof?
/src/extension/internal/win32.cpp line 316 line 334 etc, use pixblocks, and should be converted to cairo stuff.
This has something to do with printing. I thought we were using Cairo and GtkPrint for this. Does anyone know how printing is done on Windows?
I just had a look (on Windows of course) and as far I can tell this code is unused. I can cut it out (as well as all relevant references and id's that I've been able to find) and I can still print. Apparently it used to have some function, and we even had a print preview and such, but I think at some point this was superseded by a new system and the old stuff was just left. In file.h there is even a comment that some print(preview) related functions are probably redundant, which apparently dates back to SVN(!!!) revision 1600-something.
In short: I'd like to try and cut out some of this apparently unused code, cleaning up our code base and "fixing" an issue with the cairo branch at the same time. But, it seems a little scary to just remove a whole lot of code that apparently at least used to have some function, so if anyone has a reason to keep this code around, please let me know.
Was the code not commented out? If not... *ugh*. I would say that you should kill it all, test, and if it still works it's a win for spring cleaning!
Cheers, Josh
2011/4/9 Jasper van de Gronde <th.v.d.gronde@...528...>:
In short: I'd like to try and cut out some of this apparently unused code, cleaning up our code base and "fixing" an issue with the cairo branch at the same time. But, it seems a little scary to just remove a whole lot of code that apparently at least used to have some function, so if anyone has a reason to keep this code around, please let me know.
Kill it with fire.
The code was really bad in the first place, because it unconditionally rasterized the image before printing.
Regards, Krzysztof
On 8/4/11 22:45, Krzysztof Kosiński wrote:
W dniu 8 kwietnia 2011 22:30 użytkownik Krzysztof Kosiński <tweenk.pl@...400...> napisał:
Looks like there is no way in Launchpad to do this. I'm now uploading it with ~inkscape.dev as the owner.
The inkscape.dev-owned branch is now available at: lp:~inkscape.dev/inkscape/cairo-rendering
Building the branch 'cairo-renderer' (r9586) on Mac OS X 10.5.8 this time ran through without failure, but inkscape crashes when launching the GUI ('inkscape --version' or 'inkscape--verb-list' is ok). Preferences are default (new).
Backtrace attached - a proposed fix by Johan on jabber didn't help:
in /display/nr-style.cpp try changing from line 198 to : void NRStyle::update() { // force pattern update if (fill_pattern) cairo_pattern_destroy(fill_pattern); if (stroke_pattern) cairo_pattern_destroy(stroke_pattern); fill_pattern = NULL; stroke_pattern = NULL; } maybe that will fix your crash
Dependencies (using the X11 backend of GTK+): gtk2 @2.24.4 gtkmm @2.22.0 glib2 @2.28.5 glibmm @2.24.2 cairo @1.10.2
~suv
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xf0f0f0f4 0x02fbadfc in cairo_pattern_destroy () (gdb) bt #0 0x02fbadfc in cairo_pattern_destroy () #1 0x0027edc7 in NRStyle::update () at display/nr-style.cpp:201 #2 0x0027edc7 in NRStyle::set (this=0xf0f0f0f0, style=0x6887b70) at display/nr-style.cpp:140 #3 0x00258941 in nr_arena_shape_set_style (shape=0x643ce00, style=0x6887b70) at display/nr-arena-shape.cpp:543 #4 0x0018f7c8 in SPShape::sp_shape_show (item=0x65f1a28, arena=0x4fa6f80) at sp-shape.cpp:859 #5 0x001572a0 in SPItem::invoke_show (this=0x65f1a28, arena=0x4fa6f80, key=1, flags=1) at sp-item.cpp:1045 #6 0x00158b26 in CGroup::_showChildren (this=0x6887ad0, arena=0x4fa6f80, ai=0x4fa8a00, key=1, flags=1) at sp-item-group.cpp:770 #7 0x001599b0 in CGroup::show (this=0x6887ad0, arena=0x4fa6f80, key=1, flags=1) at sp-item-group.cpp:757 #8 0x0015b792 in sp_group_show (item=0x65f4120, arena=0x4fa6f80, key=1, flags=1) at sp-item-group.cpp:319 #9 0x001572a0 in SPItem::invoke_show (this=0x65f4120, arena=0x4fa6f80, key=1, flags=1) at sp-item.cpp:1045 #10 0x001a7346 in sp_use_show (item=0x37061a8, arena=0x4fa6f80, key=1, flags=1) at sp-use.cpp:359 #11 0x001572a0 in SPItem::invoke_show (this=0x37061a8, arena=0x4fa6f80, key=1, flags=1) at sp-item.cpp:1045 #12 0x00158b26 in CGroup::_showChildren (this=0x6200720, arena=0x4fa6f80, ai=0x4fa8c00, key=1, flags=1) at sp-item-group.cpp:770 #13 0x001599b0 in CGroup::show (this=0x6200720, arena=0x4fa6f80, key=1, flags=1) at sp-item-group.cpp:757 #14 0x0015b792 in sp_group_show (item=0x3739218, arena=0x4fa6f80, key=1, flags=1) at sp-item-group.cpp:319 #15 0x001890cd in sp_root_show (item=0x3739218, arena=0x4fa6f80, key=1, flags=1) at sp-root.cpp:622 #16 0x001572a0 in SPItem::invoke_show (this=0x3739218, arena=0x4fa6f80, key=0, flags=57905688) at sp-item.cpp:1045 #17 0x004126c6 in IconImpl::load_svg_pixels (names=@0xbfffebcc, psize=16, stride=@0xbfffebf4) at widgets/icon.cpp:1296 #18 0x00413fad in IconImpl::prerenderIcon (name=0x5db439c "edit-select-all-layers", lsize=GTK_ICON_SIZE_SMALL_TOOLBAR, psize=16) at widgets/icon.cpp:1430 #19 0x00415a6f in Inkscape::queueIconPrerender (name=@0xbfffed0c, lsize=Inkscape::ICON_SIZE_SMALL_TOOLBAR) at widgets/icon.cpp:1339 #20 0x00427999 in create_action_for_verb (verb=0x2, view=<value temporarily unavailable, due to optimizations>, size=Inkscape::ICON_SIZE_SMALL_TOOLBAR) at widgets/select-toolbar.cpp:387 #21 0x00429434 in sp_select_toolbox_prep (desktop=0x4fa3d80, mainActions=0x5f39428, holder=0x37de0a8) at widgets/select-toolbar.cpp:405 #22 0x00458af4 in setup_aux_toolbox (toolbox=0x507e328, desktop=0x4fa3d80) at widgets/toolbox.cpp:1901 #23 0x0044a560 in Inkscape::UI::ToolboxFactory::setToolboxDesktop (toolbox=0x507e328, desktop=0x4fa3d80) at widgets/toolbox.cpp:1667 #24 0x00491232 in std::_Rb_tree<SPDesktop*, std::pair<SPDesktop* const, std::vector<_GtkWidget*, std::allocator<_GtkWidget*> > >, std::_Select1st<std::pair<SPDesktop* const, std::vector<_GtkWidget*, std::allocator<_GtkWidget*> > > >, std::less<SPDesktop*>, std::allocator<std::pair<SPDesktop* const, std::vector<_GtkWidget*, std::allocator<_GtkWidget*> > > > >::_M_begin () at stl_tree.h:230 #25 0x00491232 in std::map<SPDesktop*, std::vector<_GtkWidget*, std::allocator<_GtkWidget*> >, std::less<SPDesktop*>, std::allocator<std::pair<SPDesktop* const, std::vector<_GtkWidget*, std::allocator<_GtkWidget*> > > > >::lower_bound () at ui/uxmanager.cpp:1146 #26 std::_Rb_tree<SPDesktop*, std::pair<SPDesktop* const, std::vector<_GtkWidget*, std::allocator<_GtkWidget*> > >, std::_Select1st<std::pair<SPDesktop* const, std::vector<_GtkWidget*, std::allocator<_GtkWidget*> > > >, std::less<SPDesktop*>, std::allocator<std::pair<SPDesktop* const, std::vector<_GtkWidget*, std::allocator<_GtkWidget*> > > > >::lower_bound () at stl_tree.h:336 #27 Inkscape::UI::UXManagerImpl::connectToDesktop (this=0x5d0e030, toolboxes=@0xbffff0d8, desktop=0x4fa3d80) at stl_map.h:540 #28 0x003fad2f in ~_Vector_base [inlined] () at widgets/desktop-widget.cpp:1476 #29 0x003fad2f in ~vector [inlined] () at stl_vector.h:273 #30 0x003fad2f in SPDesktopWidget::createInstance (namedview=0x370f7f0) at widgets/desktop-widget.cpp:1478 #31 0x003faec2 in sp_desktop_widget_new (namedview=0x370f7f0) at widgets/desktop-widget.cpp:1425 #32 0x00078152 in sp_file_new (templ=@0xbffff1ac) at file.cpp:125 #33 0x0007878a in sp_file_new_default () at file.cpp:177 #34 0x0000557e in ptr_fun<bool> [inlined] () at functors/ptr_fun.h:982 #35 0x0000557e in sp_main_gui (argc=1, argv=0xbffff2d0) at main.cpp:985 #36 0x00004216 in start () (gdb) quit
W dniu 9 kwietnia 2011 01:56 użytkownik ~suv <suv-sf@...58...> napisał:
#0 0x02fbadfc in cairo_pattern_destroy () #1 0x0027edc7 in NRStyle::update () at display/nr-style.cpp:201 #2 0x0027edc7 in NRStyle::set (this=0xf0f0f0f0, style=0x6887b70) at display/nr-style.cpp:140
0xf0f0f0f0 for "this" is obviously wrong, the stack is getting corrupted for some reason.
#3 0x00258941 in nr_arena_shape_set_style (shape=0x643ce00, style=0x6887b70) at display/nr-arena-shape.cpp:543
The "style" pointer looks correct here, so something went awry in nr_arena_shape_set_style. At the moment I have no idea what is going on.
Can you try compiling without optimization (-O0), or adding "g_return_if_fail(style != NULL);" at the top of nr_arena_shape_set_style()?
Regards, Krzysztof
On 9/4/11 02:12, Krzysztof Kosiński wrote:
W dniu 9 kwietnia 2011 01:56 użytkownik ~suv <suv-sf@...58...> napisał:
#0 0x02fbadfc in cairo_pattern_destroy () #1 0x0027edc7 in NRStyle::update () at display/nr-style.cpp:201 #2 0x0027edc7 in NRStyle::set (this=0xf0f0f0f0, style=0x6887b70) at display/nr-style.cpp:140
0xf0f0f0f0 for "this" is obviously wrong, the stack is getting corrupted for some reason.
#3 0x00258941 in nr_arena_shape_set_style (shape=0x643ce00, style=0x6887b70) at display/nr-arena-shape.cpp:543
The "style" pointer looks correct here, so something went awry in nr_arena_shape_set_style. At the moment I have no idea what is going on.
Can you try compiling without optimization (-O0), or adding "g_return_if_fail(style != NULL);" at the top of nr_arena_shape_set_style()?
Editing 'src/display/nr-arena-shape.cpp' didn't help:
LeWitt:inkscape-cairo2 suv$ mvim src/display/nr-arena-shape.cpp LeWitt:inkscape-cairo2 suv$ bzr diff !$ bzr diff src/display/nr-arena-shape.cpp === modified file 'src/display/nr-arena-shape.cpp' --- src/display/nr-arena-shape.cpp 2011-04-07 23:42:04 +0000
+++ src/display/nr-arena-shape.cpp 2011-04-09 00:15:56 +0000 @@ -533,6 +533,7 @@ void nr_arena_shape_set_style(NRArenaShape *shape, SPStyle *style) { + g_return_if_fail(style != NULL); g_return_if_fail(shape != NULL); g_return_if_fail(NR_IS_ARENA_SHAPE(shape));
LeWitt:inkscape-cairo2 suv$
Backtrace attached. I'll do a full rebuild changing optimization from '-O3' to '-O0'.
~suv
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xf0f0f0f4 0x02fbadfc in cairo_pattern_destroy () (gdb) bt #0 0x02fbadfc in cairo_pattern_destroy () #1 0x0027edc7 in NRStyle::update () at display/nr-style.cpp:201 #2 0x0027edc7 in NRStyle::set (this=0xf0f0f0f0, style=0x69e4f10) at display/nr-style.cpp:140 #3 0x0025893b in nr_arena_shape_set_style (shape=0x6516e00, style=0x69e4f10) at display/nr-arena-shape.cpp:544 #4 0x0018f7b8 in SPShape::sp_shape_show (item=0x6711a00, arena=0x4fe7f80) at sp-shape.cpp:859 #5 0x00157290 in SPItem::invoke_show (this=0x6711a00, arena=0x4fe7f80, key=1, flags=1) at sp-item.cpp:1045 #6 0x00158b16 in CGroup::_showChildren (this=0x69e4e70, arena=0x4fe7f80, ai=0x4fe9a00, key=1, flags=1) at sp-item-group.cpp:770 #7 0x001599a0 in CGroup::show (this=0x69e4e70, arena=0x4fe7f80, key=1, flags=1) at sp-item-group.cpp:757 #8 0x0015b782 in sp_group_show (item=0x6714120, arena=0x4fe7f80, key=1, flags=1) at sp-item-group.cpp:319 #9 0x00157290 in SPItem::invoke_show (this=0x6714120, arena=0x4fe7f80, key=1, flags=1) at sp-item.cpp:1045 #10 0x001a7336 in sp_use_show (item=0x37061a8, arena=0x4fe7f80, key=1, flags=1) at sp-use.cpp:359 #11 0x00157290 in SPItem::invoke_show (this=0x37061a8, arena=0x4fe7f80, key=1, flags=1) at sp-item.cpp:1045 #12 0x00158b16 in CGroup::_showChildren (this=0x6300720, arena=0x4fe7f80, ai=0x4fe9c00, key=1, flags=1) at sp-item-group.cpp:770 #13 0x001599a0 in CGroup::show (this=0x6300720, arena=0x4fe7f80, key=1, flags=1) at sp-item-group.cpp:757 #14 0x0015b782 in sp_group_show (item=0x3774230, arena=0x4fe7f80, key=1, flags=1) at sp-item-group.cpp:319 #15 0x001890bd in sp_root_show (item=0x3774230, arena=0x4fe7f80, key=1, flags=1) at sp-root.cpp:622 #16 0x00157290 in SPItem::invoke_show (this=0x3774230, arena=0x4fe7f80, key=0, flags=58147376) at sp-item.cpp:1045 #17 0x004126c6 in IconImpl::load_svg_pixels (names=@0xbfffebcc, psize=16, stride=@0xbfffebf4) at widgets/icon.cpp:1296 #18 0x00413fad in IconImpl::prerenderIcon (name=0x61156bc "edit-select-all-layers", lsize=GTK_ICON_SIZE_SMALL_TOOLBAR, psize=16) at widgets/icon.cpp:1430 #19 0x00415a6f in Inkscape::queueIconPrerender (name=@0xbfffed0c, lsize=Inkscape::ICON_SIZE_SMALL_TOOLBAR) at widgets/icon.cpp:1339 #20 0x00427999 in create_action_for_verb (verb=0x2, view=<value temporarily unavailable, due to optimizations>, size=Inkscape::ICON_SIZE_SMALL_TOOLBAR) at widgets/select-toolbar.cpp:387 #21 0x00429434 in sp_select_toolbox_prep (desktop=0x4fe4d80, mainActions=0x602cb40, holder=0x60860b8) at widgets/select-toolbar.cpp:405 #22 0x00458af4 in setup_aux_toolbox (toolbox=0x50c0328, desktop=0x4fe4d80) at widgets/toolbox.cpp:1901 #23 0x0044a560 in Inkscape::UI::ToolboxFactory::setToolboxDesktop (toolbox=0x50c0328, desktop=0x4fe4d80) at widgets/toolbox.cpp:1667 #24 0x00491232 in std::_Rb_tree<SPDesktop*, std::pair<SPDesktop* const, std::vector<_GtkWidget*, std::allocator<_GtkWidget*> > >, std::_Select1st<std::pair<SPDesktop* const, std::vector<_GtkWidget*, std::allocator<_GtkWidget*> > > >, std::less<SPDesktop*>, std::allocator<std::pair<SPDesktop* const, std::vector<_GtkWidget*, std::allocator<_GtkWidget*> > > > >::_M_begin () at stl_tree.h:230 #25 0x00491232 in std::map<SPDesktop*, std::vector<_GtkWidget*, std::allocator<_GtkWidget*> >, std::less<SPDesktop*>, std::allocator<std::pair<SPDesktop* const, std::vector<_GtkWidget*, std::allocator<_GtkWidget*> > > > >::lower_bound () at ui/uxmanager.cpp:1146 #26 std::_Rb_tree<SPDesktop*, std::pair<SPDesktop* const, std::vector<_GtkWidget*, std::allocator<_GtkWidget*> > >, std::_Select1st<std::pair<SPDesktop* const, std::vector<_GtkWidget*, std::allocator<_GtkWidget*> > > >, std::less<SPDesktop*>, std::allocator<std::pair<SPDesktop* const, std::vector<_GtkWidget*, std::allocator<_GtkWidget*> > > > >::lower_bound () at stl_tree.h:336 #27 Inkscape::UI::UXManagerImpl::connectToDesktop (this=0x5d6ba00, toolboxes=@0xbffff0d8, desktop=0x4fe4d80) at stl_map.h:540 #28 0x003fad2f in ~_Vector_base [inlined] () at widgets/desktop-widget.cpp:1476 #29 0x003fad2f in ~vector [inlined] () at stl_vector.h:273 #30 0x003fad2f in SPDesktopWidget::createInstance (namedview=0x3747e90) at widgets/desktop-widget.cpp:1478 #31 0x003faec2 in sp_desktop_widget_new (namedview=0x3747e90) at widgets/desktop-widget.cpp:1425 #32 0x00078142 in sp_file_new (templ=@0xbffff1ac) at file.cpp:125 #33 0x0007877a in sp_file_new_default () at file.cpp:177 #34 0x0000556e in ptr_fun<bool> [inlined] () at functors/ptr_fun.h:982 #35 0x0000556e in sp_main_gui (argc=1, argv=0xbffff2d0) at main.cpp:985 #36 0x00004206 in start () (gdb)
On 9/4/11 02:12, Krzysztof Kosiński wrote:
W dniu 9 kwietnia 2011 01:56 użytkownik ~suv <suv-sf@...58...> napisał:
#0 0x02fbadfc in cairo_pattern_destroy () #1 0x0027edc7 in NRStyle::update () at display/nr-style.cpp:201 #2 0x0027edc7 in NRStyle::set (this=0xf0f0f0f0, style=0x6887b70) at display/nr-style.cpp:140
0xf0f0f0f0 for "this" is obviously wrong, the stack is getting corrupted for some reason.
#3 0x00258941 in nr_arena_shape_set_style (shape=0x643ce00, style=0x6887b70) at display/nr-arena-shape.cpp:543
The "style" pointer looks correct here, so something went awry in nr_arena_shape_set_style. At the moment I have no idea what is going on.
Can you try compiling without optimization (-O0), or adding "g_return_if_fail(style != NULL);" at the top of nr_arena_shape_set_style()?
Same error after 'make clean' and rebuilding with '-O0'.
~suv
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xf0f0f0f4 0x03c77dfc in cairo_pattern_destroy () (gdb) bt #0 0x03c77dfc in cairo_pattern_destroy () #1 0x002e5e94 in NRStyle::update (this=0x713eec4) at display/nr-style.cpp:201 #2 0x002e6974 in NRStyle::set (this=0x713eec4, style=0x7587aa0) at display/nr-style.cpp:140 #3 0x002c0afb in nr_arena_shape_set_style (shape=0x713ee00, style=0x7587aa0) at display/nr-arena-shape.cpp:544 #4 0x001e00b3 in SPShape::sp_shape_show (item=0x72ada20, arena=0x5c83f80) at sp-shape.cpp:859 #5 0x0019f405 in SPItem::invoke_show (this=0x72ada20, arena=0x5c83f80, key=1, flags=1) at sp-item.cpp:1045 #6 0x001a64ff in CGroup::_showChildren (this=0x7587a00, arena=0x5c83f80, ai=0x5c85a00, key=1, flags=1) at sp-item-group.cpp:770 #7 0x001a667c in CGroup::show (this=0x7587a00, arena=0x5c83f80, key=1, flags=1) at sp-item-group.cpp:757 #8 0x001a89e7 in sp_group_show (item=0x72b0140, arena=0x5c83f80, key=1, flags=1) at sp-item-group.cpp:319 #9 0x0019f405 in SPItem::invoke_show (this=0x72b0140, arena=0x5c83f80, key=1, flags=1) at sp-item.cpp:1045 #10 0x001fa33a in sp_use_show (item=0x42c31a8, arena=0x5c83f80, key=1, flags=1) at sp-use.cpp:359 #11 0x0019f405 in SPItem::invoke_show (this=0x42c31a8, arena=0x5c83f80, key=1, flags=1) at sp-item.cpp:1045 #12 0x001a64ff in CGroup::_showChildren (this=0x6f00740, arena=0x5c83f80, ai=0x5c85c00, key=1, flags=1) at sp-item-group.cpp:770 #13 0x001a667c in CGroup::show (this=0x6f00740, arena=0x5c83f80, key=1, flags=1) at sp-item-group.cpp:757 #14 0x001a89e7 in sp_group_show (item=0x42e1218, arena=0x5c83f80, key=1, flags=1) at sp-item-group.cpp:319 #15 0x001db39a in sp_root_show (item=0x42e1218, arena=0x5c83f80, key=1, flags=1) at sp-root.cpp:622 #16 0x0019f405 in SPItem::invoke_show (this=0x42e1218, arena=0x5c83f80, key=1, flags=1) at sp-item.cpp:1045 #17 0x004d5ea8 in IconImpl::load_svg_pixels (names=@0xbfffeb94, psize=16, stride=@0xbfffeb90) at widgets/icon.cpp:1296 #18 0x004d8c51 in IconImpl::prerenderIcon (name=0x69b42cc "edit-select-all-layers", lsize=GTK_ICON_SIZE_SMALL_TOOLBAR, psize=16) at widgets/icon.cpp:1430 #19 0x004da3ca in Inkscape::queueIconPrerender (name=@0xbfffed00, lsize=Inkscape::ICON_SIZE_SMALL_TOOLBAR) at widgets/icon.cpp:1339 #20 0x004e714a in create_action_for_verb (verb=0x430f840, view=0x5c80d80, size=Inkscape::ICON_SIZE_SMALL_TOOLBAR) at widgets/select-toolbar.cpp:387 #21 0x004e8d61 in sp_select_toolbox_prep (desktop=0x5c80d80, mainActions=0x6bf63f8, holder=0x42f50a8) at widgets/select-toolbar.cpp:405 #22 0x00533e7a in setup_aux_toolbox (toolbox=0x5d3b328, desktop=0x5c80d80) at widgets/toolbox.cpp:1901 #23 0x0051edc3 in Inkscape::UI::ToolboxFactory::setToolboxDesktop (toolbox=0x5d3b328, desktop=0x5c80d80) at widgets/toolbox.cpp:1667 #24 0x0056316f in Inkscape::UI::UXManagerImpl::connectToDesktop (this=0x690e030, toolboxes=@0xbffff054, desktop=0x5c80d80) at ui/uxmanager.cpp:230 #25 0x004b1355 in SPDesktopWidget::createInstance (namedview=0x42cc7f0) at widgets/desktop-widget.cpp:1476 #26 0x004b13a3 in sp_desktop_widget_new (namedview=0x42cc7f0) at widgets/desktop-widget.cpp:1425 #27 0x0009237b in sp_file_new (templ=@0xbffff19c) at file.cpp:125 #28 0x000926be in sp_file_new_default () at file.cpp:177 #29 0x00008071 in sp_main_gui (argc=1, argv=0xbffff2d0) at main.cpp:982 #30 0x000088f0 in main (argc=1, argv=0xbffff2d0) at main.cpp:717 (gdb)
W dniu 9 kwietnia 2011 03:30 użytkownik ~suv <suv-sf@...58...> napisał:
Same error after 'make clean' and rebuilding with '-O0'.
~suv
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xf0f0f0f4 0x03c77dfc in cairo_pattern_destroy () (gdb) bt #0 0x03c77dfc in cairo_pattern_destroy () #1 0x002e5e94 in NRStyle::update (this=0x713eec4) at display/nr-style.cpp:201 #2 0x002e6974 in NRStyle::set (this=0x713eec4, style=0x7587aa0) at display/nr-style.cpp:140
This looks like uninitialized memory in NRStyle. I added explicit NULL initializers in rev. 9588, see whether it fixes the crash.
Regards, Krzysztof
On 9/4/11 03:48, Krzysztof Kosiński wrote:
W dniu 9 kwietnia 2011 03:30 użytkownik ~suv <suv-sf@...58...> napisał:
Same error after 'make clean' and rebuilding with '-O0'.
~suv
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xf0f0f0f4 0x03c77dfc in cairo_pattern_destroy () (gdb) bt #0 0x03c77dfc in cairo_pattern_destroy () #1 0x002e5e94 in NRStyle::update (this=0x713eec4) at display/nr-style.cpp:201 #2 0x002e6974 in NRStyle::set (this=0x713eec4, style=0x7587aa0) at display/nr-style.cpp:140
This looks like uninitialized memory in NRStyle. I added explicit NULL initializers in rev. 9588, see whether it fixes the crash.
Success! :)
Inkscape (cairo-renderer r9588) up and running on osx too (this is still with '-O0'). I'll do some tests and rebuild with '-O3' tomorrow, and maybe also a quartz-based version.
Thank you for making this work, ~suv
On Apr 8, 2011, at 6:48 PM, Krzysztof Kosiński wrote:
This looks like uninitialized memory in NRStyle. I added explicit NULL initializers in rev. 9588, see whether it fixes the crash.
Well, since we're C++ we should be using 0 instead of NULL. :-)
But more importantly, this is exactly the sort of issue that Valgrind is very good at spotting and pointing out.
When problems like this (subtle corruptions or crashing) are hit, running under valgrind should be a first step. It will generally catch a problem when it first occurs, not later on after it has cascaded enough to actually cause a crash, etc.
If anyone needs more detail on the wiki for this, let me know. Also drop on in to IRC to hash it out (that really helps).
On Fri, Apr 8, 2011 at 11:13 PM, Jon Cruz <jon@...18...> wrote:
On Apr 8, 2011, at 6:48 PM, Krzysztof Kosiński wrote:
This looks like uninitialized memory in NRStyle. I added explicit NULL initializers in rev. 9588, see whether it fixes the crash.
Well, since we're C++ we should be using 0 instead of NULL. :-)
But more importantly, this is exactly the sort of issue that Valgrind is very good at spotting and pointing out.
When problems like this (subtle corruptions or crashing) are hit, running under valgrind should be a first step. It will generally catch a problem when it first occurs, not later on after it has cascaded enough to actually cause a crash, etc.
If anyone needs more detail on the wiki for this, let me know. Also drop on in to IRC to hash it out (that really helps).
Krzysztof,
It appears that the new renderer doesn't release memory on zooming operations. Without any modifications to the document, just zooming in and out a number of times shows memory growth and memory that isn't released. If it's known and expected, okay, but it's just an observation I figured I would point out. The document I sent you off-list is a good test file for this behavior btw. (a follow-up to a valgrind reply seemed like it was a relevant place to comment)
Cheers, Josh
On 10/4/11 00:29, Josh Andler wrote:
It appears that the new renderer doesn't release memory on zooming operations. Without any modifications to the document, just zooming in and out a number of times shows memory growth and memory that isn't released. If it's known and expected, okay, but it's just an observation I figured I would point out. The document I sent you off-list is a good test file for this behavior btw. (a follow-up to a valgrind reply seemed like it was a relevant place to comment)
Does you sample file contain (fairly complex) patterns?
We do have two reports about zooming-related memory leaks with files containing patterns for the current renderer already:
706294 Huge memory leak when zooming in & out complex pattern https://bugs.launchpad.net/inkscape/+bug/706294
608944 Enormous memory consumption (memory leak? https://bugs.launchpad.net/inkscape/+bug/608944
~suv
2011/4/9 ~suv <suv-sf@...58...>
On 10/4/11 00:29, Josh Andler wrote:
It appears that the new renderer doesn't release memory on zooming operations. Without any modifications to the document, just zooming in
and
out a number of times shows memory growth and memory that isn't released.
If
it's known and expected, okay, but it's just an observation I figured I would point out. The document I sent you off-list is a good test file for this behavior btw. (a follow-up to a valgrind reply seemed like it was a relevant place to comment)
Does you sample file contain (fairly complex) patterns?
Nope. Paths, LPEs, and filters.
Cheers, Josh
W dniu 9 kwietnia 2011 08:13 użytkownik Jon Cruz <jon@...18...> napisał:
When problems like this (subtle corruptions or crashing) are hit, running under valgrind should be a first step. It will generally catch a problem when it first occurs, not later on after it has cascaded enough to actually cause a crash, etc.
Last time I tried using valgrind, Inkscape crashed hard, and it was apparently due to our usage of libgc. Did anyone manage to run Inkscape under valgrind?
Regards, Krzysztof
I had a while ago, John Bintz has too.
Cheers, Josh On Apr 9, 2011 7:00 PM, "Krzysztof Kosiński" <tweenk.pl@...400...> wrote:
W dniu 9 kwietnia 2011 08:13 użytkownik Jon Cruz <jon@...18...>
napisał:
When problems like this (subtle corruptions or crashing) are hit, running
under valgrind should be a first step. It will generally catch a problem when it first occurs, not later on after it has cascaded enough to actually cause a crash, etc.
Last time I tried using valgrind, Inkscape crashed hard, and it was apparently due to our usage of libgc. Did anyone manage to run Inkscape under valgrind?
Regards, Krzysztof
------------------------------------------------------------------------------
Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 8/4/11 01:59, Krzysztof Kosiński wrote:
I have updated my Cairo branch today, as a step towards merging it. There is one new regression, namely feImage does not handle aspect ratio. It will be fixed before merging. IIRC, there is a problem with CMS output, the editing controls are not using custom XOR blending, and there are build failures on Windows. Does anyone remember any other bugs?
a) outline view mode
cairo-renderer r9589, OS X 10.5.8 (i386), Apple's GCC 4.2.1, no OpenMP: - cairo 1.10.2, GTK+/X11 - cairo 1.11.2, GTK+/Quartz
Outline view mode uses white to draw the outlines: they are not visible on default backgrounds (white). The color of the outline apparently is not inverted (or xor-composited (?)) when using a dark background, either.
Currently, outline mode is only usable with a solid, darker background.
b) multi-threading / OpenMP
As described earlier [1], OpenMP is not detected by the configure script when building with Apple's GCC 4.2.1 (although the man page states otherwise, and e.g. 'libgomp.a' and the omp header do exist).
Testing a build of the cairo-renderer branch using plain GCC 4.2.4 installed via MacPorts does enable OpenMP (-fopenmp), but when used in rendering, Inkscape randomly hangs (apparently waiting for something to finish(?) - see attached backtrace when interrupting Inkscape after it no longer accepts any input).
The build with GCC 4.2.4 also produced several warnings from the linker ("ld warning: can't find atom for N_GSYM stabs (...)").
I will try with newer GCC versions [2], but so far my earlier tests building inkscape trunk with GCC 4.5 and GCC 4.4 had other serious issues (crashes, or e.g. broken text rendering on canvas).
IMHO with the new renderer, we should get OpenMP working on OS X as well. Any input or help - maybe it just needs adjusted compiler and linker flags (?) - would be appreciated.
~suv
[1] http://article.gmane.org/gmane.comp.graphics.inkscape.devel/34491 [2] currently installed GCC versions (XCode 3.1.4, MacPorts): gcc-4.0 (4.0.1, Apple) gcc-4.2 (4.2.1, Apple) gcc-mp-4.2 (4.2.4, MacPorts) gcc-mp-4.3 (4.3.5, MacPorts) gcc-mp-4.4 (4.4.5, Macports) gcc-mp-4.5 (4.5.2, MacPorts)
Program received signal SIGINT, Interrupt. 0x90d8444e in __semwait_signal () (gdb) bt #0 0x90d8444e in __semwait_signal () #1 0x90daf3e6 in _pthread_cond_wait () #2 0x90daedcd in pthread_cond_wait$UNIX2003 () #3 0x1386589c in gomp_sem_wait () #4 0x13865993 in gomp_barrier_wait_end () #5 0x138659f9 in gomp_barrier_wait () #6 0x1386511d in gomp_team_start () #7 0x138648cf in GOMP_parallel_start () #8 0x0029b25b in Inkscape::Filters::filter2D_FIR<unsigned char, 4u> (dst=0x4 <Address 0x4 out of bounds>, dstr1=<incomplete type>, dstr2=<incomplete type>, src=0x1acd5030 "", sstr1=<incomplete type>, sstr2=<incomplete type>, n1=<incomplete type>, n2=<incomplete type>, kernel=0xbfffdcc0, scr_len=<incomplete type>, num_threads=<incomplete type>) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/gcc42/c++/complex:954 #9 0x0029b44c in Inkscape::Filters::gaussian_pass_FIR (d=<incomplete type>, deviation=<incomplete type>, src=<incomplete type>, dest=<incomplete type>, num_threads=<incomplete type>) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/gcc42/c++/complex:954 #10 0x0029bc80 in Inkscape::Filters::FilterGaussian::render_cairo (this=0x1ac92190, slot=<incomplete type>) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/gcc42/c++/complex:954 #11 0x0029527b in Inkscape::Filters::Filter::render (this=0x1a9262d0, item=0x1a92a1c0, bgct=0x15769594, bgarea=0xbfffe354, graphic=0x15769a68, area=0xbfffe1e4) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/gcc42/c++/ext/new_allocator.h:89 #12 0x00280113 in nr_arena_item_invoke_render (ct=0x15769594, item=0x1a92a1c0, area=0xbfffe354, pb=0x0, flags=0) at display/nr-arena-item.h:73 #13 0x00278d88 in nr_arena_group_render (ct=0x15769594, item=0x1a929700, area=0xbfffe354, pb=0x0, flags=0) at ./display/nr-arena-item.h:73 #14 0x0027fd81 in nr_arena_item_invoke_render (ct=0x157690c0, item=0x1a929700, area=0xbfffe85c, pb=0x0, flags=0) at display/nr-arena-item.h:73 #15 0x00278d88 in nr_arena_group_render (ct=0x157690c0, item=0x1912d900, area=0xbfffe85c, pb=0x0, flags=0) at ./display/nr-arena-item.h:73 #16 0x0027fd81 in nr_arena_item_invoke_render (ct=0x157690c0, item=0x1912d900, area=0xbfffe85c, pb=0x0, flags=0) at display/nr-arena-item.h:73 #17 0x00278d88 in nr_arena_group_render (ct=0x157690c0, item=0x1912dd00, area=0xbfffe85c, pb=0x0, flags=0) at ./display/nr-arena-item.h:73 #18 0x0027fd81 in nr_arena_item_invoke_render (ct=0x157690c0, item=0x1912dd00, area=0xbfffe85c, pb=0x0, flags=0) at display/nr-arena-item.h:73 #19 0x00278d88 in nr_arena_group_render (ct=0x157690c0, item=0x1910c000, area=0xbfffe85c, pb=0x0, flags=0) at ./display/nr-arena-item.h:73 #20 0x0027fd81 in nr_arena_item_invoke_render (ct=0x157690c0, item=0x1910c000, area=0xbfffe85c, pb=0x0, flags=0) at display/nr-arena-item.h:73 #21 0x0025839a in sp_canvas_arena_render (item=0x191bd5b0, buf=0xbfffe9e0) at display/canvas-arena.cpp:64 #22 0x002b2142 in sp_canvas_group_render (item=0x18e5f1c0, buf=0xbfffe9e0) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #23 0x002b2142 in sp_canvas_group_render (item=0x18e5f130, buf=0xbfffe9e0) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #24 0x002b0c5a in sp_canvas_paint_rect_internal (setup=0xbfffedf4, this_rect={x0 = -16, y0 = -368, x1 = 704, y1 = -320}) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #25 0x002b0670 in sp_canvas_paint_rect_internal (setup=0xbfffedf4, this_rect={x0 = -16, y0 = -368, x1 = 704, y1 = -272}) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #26 0x002b0670 in sp_canvas_paint_rect_internal (setup=0xbfffedf4, this_rect={x0 = -16, y0 = -368, x1 = 704, y1 = -176}) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #27 0x002b0670 in sp_canvas_paint_rect_internal (setup=0xbfffedf4, this_rect={x0 = -16, y0 = -368, x1 = 704, y1 = 10}) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #28 0x002b3826 in sp_canvas_paint_rect (canvas=0x191efa48, xx0=-16, yy0=-368, xx1=704, yy1=16) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #29 0x002b3d04 in do_update (canvas=0x191efa48) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #30 0x002b61a8 in idle_handler (data=0x191efa48) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #31 0x15ae671d in g_main_context_dispatch () #32 0x15aea5ab in g_main_context_iterate () #33 0x15aea887 in g_main_loop_run () #34 0x13eaefa1 in gtk_main () #35 0x138c2d4b in Gtk::Main::run () #36 0x000058fa in sp_main_gui (argc=1, argv=0xbffff2d0) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/gcc42/c++/bits/basic_string.tcc:146 #37 0x00003e9b in _start () #38 0x00003dc9 in start () (gdb) quit The program is running. Exit anyway? (y or n) y LeWitt:mp-inkscape suv$
participants (7)
-
Jasper van de Gronde -
Johan Engelen -
Jon Cruz -
Josh Andler -
Krzysztof Kosiński -
Tavmjong Bah -
~suv