- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Some memory leaks in replaceArgs function ( main.cpp )
by Krzysztof Kosiński 10 Jun '14

10 Jun '14

There is no point in rewriting this code; it should be ported to GOption, which recently added functions required to properly support Windows. Regards, Krzysztof From: Johan Engelen Sent: 2014-06-10 19:51 To: inkscape-devel(a)lists.sourceforge.net; neandertalspeople@...400... Subject: Re: [Inkscape-devel] Some memory leaks in replaceArgs function ( main.cpp ) Actually, all your changes are incorrect. Your patch is deleting memory which the code still holds pointers to. The code is quite bad indeed, but should be fixed differently. At the end of the method, all memory that the parser array has pointers to should be freed. The problem is that these pointers point to memory blocks that have been allocated differently, or point to memory locations within an allocated array. It's a mess. The whole function should be rewritten. Please create a bug report for it. regards, Johan On 10-6-2014 19:35, Johan Engelen wrote: > On 10-6-2014 17:29, Guiu Rocafort wrote: >> Hi ! >> >> Making a simple check to see if all the new operators are freed using >> delete i found that there are some memory leaks in main.cpp, in the >> function replaceArgs ( which only affects the windows version of >> inkscape ). >> >> I've added the missing delete operators and those memory leaks should >> be fixed. >> I attach the .patch file, if you want me to fill a bug report and then >> submit the patch instead please tell me. > Did you test your patch? While you are right that there are some > memleaks, there are less than you think there are :) (e.g. your > "delete[] block;" on line 1984 is wrong) > > I'll rework and commit it. > > regards, > Johan > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 1

Some memory leaks in replaceArgs function ( main.cpp )
by Guiu Rocafort 10 Jun '14

10 Jun '14

Hi ! Making a simple check to see if all the new operators are freed using delete i found that there are some memory leaks in main.cpp, in the function replaceArgs ( which only affects the windows version of inkscape ). I've added the missing delete operators and those memory leaks should be fixed. I attach the .patch file, if you want me to fill a bug report and then submit the patch instead please tell me. Guiu Rocafort -- *Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html <http://www.gnu.org/philosophy/no-word-attachments.html>*

2 2

Somebody please test patch for bug 1318657
by mathog 10 Jun '14

10 Jun '14

If one of you gets a chance, please test the patch for bug 1318657 (in post 10) https://bugs.launchpad.net/inkscape/+bug/1318657 and see if you can break it. I didn't want to commit that change until another developer had a look at it. (Because this section of code is easy to break, and we keep running into cases that are not handled, like the present bug, which is the result of an incoming document containing two copies of a gradient/swatch with different names.) Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

Last call for 0.48.5
by Josh Andler 09 Jun '14

09 Jun '14

Hey all, We have some license compliance issues which have been fixed in the 0.48.x branch which is overdue for should release anyway. I don't recall seeing objections the last time releasing 0.48.5 was brought up (but could have missed something). If there are no issues left unmentioned or unresolved prior to next Sunday, May 25, we will move forward with releasing it. Given that our focus is really on moving forward with 0.91, please speak up as this is likely to be the last release in the 0.48 series. Cheers, Josh

5 8

Bug fixed testing
by Jabiertxo Arraiza Cenoz 07 Jun '14

07 Jun '14

Hi to all. I just commit to experimental a fix to the bug https://bugs.launchpad.net/inkscape/+bug/1241902 to the experimental branch, every body are welcome to test it previous to commit to trunk. Thanks to Johan for his persistence in reviews.

1 0

Problem compiling experimental with CMake
by Liam White 06 Jun '14

06 Jun '14

Apologies for the wall of text. liam@...3128...:/home/inkrepo$ cd experimental liam@...3128...:/home/inkrepo/experimental$ ls liam@...3128...:/home/inkrepo/experimental$ cmake . -- Creating build files in: /home/inkrepo/experimental -- Found GSL: /usr/lib/libgsl.so -- Found BoehmGC: /usr/lib/x86_64-linux-gnu/libgc.so -- Found poppler: /usr/lib/x86_64-linux-gnu/libpoppler.so -- Found poppler-glib: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so -- Found cairo-svg: /usr/lib/x86_64-linux-gnu/libcairo.so -- Found poppler-cairo: /usr/lib/x86_64-linux-gnu/libcairo.so -- checking for module 'libwpg-0.1' -- package 'libwpg-0.1' not found -- checking for module 'libwpg-stream-0.1' -- package 'libwpg-stream-0.1' not found -- checking for module 'libwpd-0.8' -- package 'libwpd-0.8' not found -- Found libwpg-0.2: /usr/lib/libwpg-0.2.so -- Found libwpd-0.9: /usr/lib/libwpd-0.9.so -- Found libwpd-stream-0.9: /usr/lib/libwpd-stream-0.9.so -- Found Popt: /usr/lib/x86_64-linux-gnu/libpopt.so -- Boost version: 1.54.0 -- checking for module 'gtkspell-2.0' -- package 'gtkspell-2.0' not found -- Try OpenMP C flag = [ ] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [-fopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [/openmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [-Qopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [-openmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [-xopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [+Oopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [-qsmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP C flag = [-mp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [ ] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-fopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [/openmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-Qopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-openmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-xopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [+Oopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-qsmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-mp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Could NOT find OpenMP (missing: OpenMP_C_FLAGS OpenMP_CXX_FLAGS) -- Generating header and sourcefiles from sp-marshal.list (Glib-Marshal) -- sp-marshal.h unchanged CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: ImageMagick_MagickCore_INCLUDE_DIR used as include directory in directory /home/inkrepo/experimental used as include directory in directory /home/inkrepo/experimental used as include directory in directory /home/inkrepo/experimental/src used as include directory in directory /home/inkrepo/experimental/src used as include directory in directory /home/inkrepo/experimental/src/2geom used as include directory in directory /home/inkrepo/experimental/src/libavoid used as include directory in directory /home/inkrepo/experimental/src/libcola used as include directory in directory /home/inkrepo/experimental/src/libcroco used as include directory in directory /home/inkrepo/experimental/src/libgdl used as include directory in directory /home/inkrepo/experimental/src/libuemf used as include directory in directory /home/inkrepo/experimental/src/libvpsc used as include directory in directory /home/inkrepo/experimental/src/livarot used as include directory in directory /home/inkrepo/experimental/src/libnrtype used as include directory in directory /home/inkrepo/experimental/src/libdepixelize -- Configuring incomplete, errors occurred! See also "/home/inkrepo/experimental/CMakeFiles/CMakeOutput.log". See also "/home/inkrepo/experimental/CMakeFiles/CMakeError.log". Just to prove CMake wrong about OpenMP and ImageMagick, I then did this: liam@...3128...:/home/inkrepo/experimental$ cd .. liam@...3128...:/home/inkrepo$ cat > openmp-test.cpp #include <omp.h> #include <stdio.h> int main() { #pragma omp parallel printf("Hello from thread %d, nthreads %d\n", omp_get_thread_num(), omp_get_num_threads()); }^D liam@...3128...:/home/inkrepo$ g++ -fopenmp openmp-test.cpp -o a.out liam@...3128...:/home/inkrepo$ ./a.out Hello from thread 3, nthreads 4 Hello from thread 0, nthreads 4 Hello from thread 2, nthreads 4 Hello from thread 1, nthreads 4 liam@...3128...:/home/inkrepo$ ls /usr/include/GraphicsMagick magick Magick++ Magick++.h wand liam@...3128...:/home/inkrepo$ ls /usr/include/magick analyze.h blob.h color_lookup.h common.h confirm_access.h deprecate.h enhance.h gem.h list.h magick.h monitor.h pixel_cache.h quantize.h resize.h statistics.h transform.h api.h cdl.h colormap.h compare.h constitute.h describe.h error.h gradient.h log.h magick_types.h montage.h pixel_iterator.h random.h resource.h symbols.h type.h attribute.h channel.h colorspace.h composite.h decorate.h draw.h forward.h hclut.h magic.h memory.h operator.h plasma.h registry.h shear.h texture.h utility.h average.h color.h command.h compress.h delegate.h effect.h fx.h image.h magick_config.h module.h paint.h profile.h render.h signature.h timer.h version.h What I'm not getting here is why CMake requires libmagickcore-dev to be installed — on the same system, with the same installed packages, ./configure with no parameters passed says this: Use gnome-vfs: yes Use openoffice files: yes Use relocation support: no Enable LittleCms: yes Enable DBUS: no Enable Poppler-Cairo: yes ImageMagick Magick++: yes Libwpg: yes Libvisio: yes Libcdr: no Doing Local Install: no After installing libmagickcore-dev, I ran CMake again and it "worked". I then ran make -k (and got the expected errors with poppler), but then this error about missing Magick.h. [ 20%] Building CXX object src/CMakeFiles/inkscape.dir/extension/internal/bitmap/blur.cpp.o /home/inkrepo/experimental/src/extension/internal/bitmap/blur.cpp:13:10: fatal error: 'Magick++.h' file not found #include <Magick++.h> ^ 1 error generated. *TL;DR *how do we get CMake to properly recognize OpenMP support, recognize the correct Magick, and supply the correct headers?

1 0

GSoC blurb for website
by Bryce Harrington 06 Jun '14

06 Jun '14

Now that GSoC is under way, it would be nice to replace the blurb on our homepage with a list of what projects are under way (with links to status if possible?) Bryce

3 3

Tile View widget
by Tomasz Boczkowski 04 Jun '14

04 Jun '14

Hi! I'd like to share the first screenshots of the tile view widget. It displays data in form of rectangular tiles divided into categories. It will be used in pattern selection dialogs, swatches, glyphs and symbols. The pictures are attached to this e-mail. Code is available at lp:~penginsbacon/+junk/tile-view/ Regards, Tomasz

1 0

Frost for 0.91
by Bryce Harrington 04 Jun '14

04 Jun '14

The release process is ready to now move to the Frost phase. 1. Open development. √ Triage and prioritize bugs report this year √ Itemize regression bugs found since last release 2. Chill. √ Development focuses on wrapping up √ Disable features that aren't finished √ Identify 'make distcheck' issues √ Identify any critical OSX/Win32 packaging issues √ Identify remaining writing needed for Release Notes. √ Regressions Bug Hunt: 500 points √ Update tutorials and other docs 3. Frost. √ Experimental Branch is forked √ Mainline Branch focuses on stabilization √ Only production-ready code committed to Mainline Post inkscape-0.91-pre0.tar.gz Finalize any major changes to platform packaging Release Notes should be >90% filled in. Inkscape must pass >90% of 'make distcheck' Start an About Screen contest General Bug Hunt: 1500 points Post additional inkscape-0.91-pre*.tar.gz releases Packagers test creating pkgs of the -pre* releases Mainline Branch =============== During the Frost period, developers should not commit changes to mainline unless the change improves the overall stability of Inkscape or is needed for packaging or to fix distcheck issues. Use your judgment as to what is "safe". If you're unsure, email me or Josh before committing and we'll make case-by-case decisions. As a general rule of thumb, if your commit doesn't specify a LP bug #, then it should probably be signed off on by josh or I. Experimental Branch =================== The Experimental Branch is now forked. You can check it out via: bzr branch lp:inkscape/experimental This is an official (but temporary) branch, for freely merging all development work. Please treat it as you would mainline when we're not in release, and strive to keep it buildable and usable. In particular, all merges of GSoC branches and other sponsored development work should target this experimental branch instead of mainline. Bug reports will be accepted for the experimental branch. These bug reports will be EOL'd when the experimental branch goes EOL. About Screen Contest ==================== Josh, can you and Ryan work on organizing this? This contest will need to be completed before we enter Freeze. Make Distcheck ============== Last I checked we had some distcheck issues, which will need to be resolved before we release. Basically just run `make distcheck` and work on sorting out the errors and warnings that print out. Bug Hunt ======== This time around, any bug filed against Inkscape is fair game. I'll be posting stats on Mondays. This next Monday I'll explain this in more detail. I'll start the count as of May 5th. Packaging ========= If you are working on packaging improvements, please continue to do so, with the goal of having it all in working order by the time Frost is over (probably several weeks from now). Bryce

2 2

SPPattern class refactorization.
by Tomasz Boczkowski 03 Jun '14

03 Jun '14

Hi! Tavmjonh Bah has suggested me to contact you and consult SPPaintServer class refactoring I would like to do. Currently SPPaintServer contains pattern_new method. Since it directly handles rendering and uses cairo, I think it could be moved outside of SP tree. My idea is to implement paint server drawing routines in a parallel hierarchy of classes belonging to New Renderer. Image [1] contains the class diagram. Common base for them would be NRPaintServer, containing pure virtual method pattern_new. Concrete NRPaintServer derivatives would contain a reference to corresponding SPTree items and use it while rendering. To choose an appropriate NRPaintServer for given SPPaintServer I thought about a factory method in NRPaintServer class. Example interfaces and their usage are shown at [2] The tricky part can be the implementation of NRPaintServer::create method. I have thought about two solutions: a) using a battery of dynamic_cast if statements like this: NRPaintServer* NRPaintServer::create(SPPaintServer* ps) { SPPattern* pattern = dynamic_cast<SPPattern*>ps; if (pattern != 0) { return new NRPattern(&pattern); } //and so on for gradients } b) using double-dispatch strategy. There would be an .cpp file internal class NRPaintServerFactory. class NRPaintServerFactory { public: virtual NRPaintServer* create(SPPaintServer*); virtual NRPaintServer* create(SPLinearGradient*); virtual NRPaintServer* create(SPRadialGradient*); //and so on } And NRPaintServer::create implementation would look like this: NRPaintServer* NRPaintServer::create(SPPaintServer* ps) { static NRPaintServerFactory *factory = new NRPaintServerFactory; return factory->create(ps); } What are your thoughts about this solution? [1]https://www.dropbox.com/s/bz83xd0ks378qys/NRPaintServer.svg [2]http://pastebin.com/h9AcrusW Regards, Tomasz

3 2