- Inkscape Devel - Inkscape Mailman

[Fwd: [Inkscape-user] moving forward (Was: Re: cause of crashes)]
by MenTaLguY 31 Aug '04

31 Aug '04

Whoops, meant to send this to the development list.. -----Forwarded Message----- From: MenTaLguY <mental@...3...> To: Inkscape Users List <inkscape-user(a)lists.sourceforge.net> Subject: [Inkscape-user] moving forward (Was: Re: cause of crashes) Date: Sun, 29 Aug 2004 13:01:02 -0400 Ok, so it appears we're currently waiting on someone to test with a build of libgc that we know to have been compiled with the appropriate options (this means C++ support, but nothing else -- particularly no malloc replacement). So, is someone willing to assume responsibility for making a new build of libgc to test with, and documenting what steps they took when building it? -mental

2 1

refcount rules
by MenTaLguY 31 Aug '04

31 Aug '04

On Mon, 2004-08-30 at 00:59, bulia byak wrote: > Mental, please check out the patch in this bug: > > https://sourceforge.net/tracker/index.php?func=detail&aid=1012874&group_id=… > > and apply if ok. It fixes a bad memory usage crash in deleteObject. Unfortunately sourceforge is currently in "read-only" mode, so I cannot comment in the bug itself. The patch hides the problem without really fixing it, though (and sort of breaks the intended semantics I had for successors, albeit not in a way that matters too much). The bug is not in deleteObject, but rather that deleteObject's caller is not retaining a reference to it (by increasing the reference count) while deleteObject() does its work. The general rule is always, always, always make sure that you have claimed a refcounted object before calling a nontrivial function (especially one that modifies the object). This holds not just for deleteObject(), or SPObjects in Inkscape, but for any software with simple refcounted objects. [ The garbage collector relaxes this requirement slightly, but only for classes which are managed by it, which SPObject is not yet. ] The correct fix is to modify the portion of sp_marker_prev_new(): SPObject *oldmarker = sandbox->getObjectById("sample"); if (oldmarker) oldmarker->deleteObject(false); thusly: SPObject *oldmarker = sandbox->getObjectById("sample"); if (oldmarker) { sp_object_ref(oldmarker, NULL); oldmarker->deleteObject(false); sp_object_unref(oldmarker, NULL); } Probably simliar mistakes are made in other places as well (and with other functions beyond just deleteObject() -- deleteObject() is simply more likely than most to remove the remaining external refcounts on the object). -mental

2 3

libgc on Win32
by MenTaLguY 30 Aug '04

30 Aug '04

Talking to Simarilius, it looks like the version of libgc we've been using on Win32 has been built to replace the standard malloc. This should in principle be harmless (except that the collector will be scanning a lot of memory it does not need to, and might mistake e.g. bitmap data for pointers), but Could someone try a version of libgc that has been built without the malloc-replacement option and report back? A different problem may be that Win9x and WinNT/2k/XP could require different builds of libgc. -mental

6 14

GC_no_dls
by MenTaLguY 30 Aug '04

30 Aug '04

I'm going to make one small adjustment to the GC code now: adding GC_no_dls = 1 to the GC intialization code. This will prevent libgc from scanning the static data areas of dynamic libraries, which seems to cause problems on FC2, and in any case is unnecessary. Ideally we want the most conservative gc configuration that is reasonably possible; this should bring us a step closer. -mental

3 3

switch + documentation translations
by bulia byak 30 Aug '04

30 Aug '04

With the number of documentation translations growing, the current system becomes less and less sustainable: if I now update an English tutorial, translators will have lots of trouble spotting the changes and updating their translations accordingly. It basically amounts to manual comparisons, which means the translations are likely to almost always be out of sync with the original. How to fix this? I thought about the switch element: http://www.w3.org/TR/SVG11/struct.html#SwitchElement Inkscape needs to support it (it doesn't yet) at least for the systemLanguage attribute. Then, all translations of a tutorial can be stored in one file. A translator would select each text obejct (they will need to be converted to flowed text objects, by the way) and use a command to add an alternative for his language, then type the translation. Illustrations would be shared across all languages. This way, if a new section is added but not translated yet, users of a non-English language will still see this section in English, which is better than not seeing it at all. Inkscape could provide additional help by storing the last-edited timestamps in switch'ed objects, so that a translator could find sections where the original is more recent than a translation. What do you think of this idea?

7 8

resurrecting Win32 builds
by Bob Jamison 30 Aug '04

30 Aug '04

Hi all. Just thought I'd update everyone on the Win32 situation. Re: win32 startup crashes =================== For the entire summer, I have been without a Win32 box on which to do native builds or test Inkscape. All I can do is make cross-compiled builds and depend on other people to test and debug Win32 factors. Simarilius and others have been researching many possible reasons for the crashing bugs, and trying to alleviate them. malloc/free and null pointers seem to be prime suspects. One possibility occurred to me yesterday. The GCC3.4.1 compiler we have been using for cross-compiling was a CVS HEAD version, and not the final 3.4.1 release. It was possible that MinGW patches might insufficiently apply to this code. It is thus possible that the objects created from C++ might be buggy. So I rebuilt the cross-compiler and all of the C++ libs in our gtk24.zip collection, and put these new builds on the web site. Anyone building Win32 Inkscape should get a fresh copy of these. The same links as before have the new items. I built Inkscape with these libs yesterday, put them on the server. Bulia said it works; Simarilius says there are still some problems. So -at least- we are making some progress. One possible problem area to investigate is MSVCRT's RtlFreeHeap() seeing different address spaces in the .exe and .dlls. Allocating memory in one, and freeing in the other would cause a fault in WinNT and above (not 9x). Re: server =================== After more than a week of downtime, my little development server is partially back online. The current location is now: http://troi.hous.es3.titan.com/~rjamison/inkscape By 'partially,' I mean that it can be accessed via http, but the admin has not fixed the routers to allow the machine to see the Net. So it cannot do a cvs checkout, thus cannot do an autobuild. The admin is a good guy, so this condition is certainly temporary. Because of this, I did a manual build, and put a copy in the /builds subfolder (link at the top of the page). I will do this occasionally until things are fixed. InkscapeLatest.zip points to it. Bob

3 5

evil_malloc
by MenTaLguY 30 Aug '04

30 Aug '04

Since I was asked about evil_malloc() -- the main reason I introduced it was that malloc debuggers (e.g. Electric Fence) don't like malloc(0), and I wanted to be able to use them. The reason is that malloc(0) is not required to return NULL; all that is required is that it return a pointer which can be free()d -- this can introduce some subtle bugs depending on the platform and libc versions. [ regrettably, realloc(p, 0) is not guaranteed to return NULL either, though it is more likely to :/ ] While I don't see any harm to livarot specifically resulting from differing malloc(0) behaviors, there is far too much code in there that is "wrong, but harmless". I want rid of it; subtle bugs cropping up in livarot is sapping far too much of my development time. So, anyway, the proper resolution to the evil_malloc() business is to replace the calls to evil_malloc() with an explicit check of the allocation size (really, nrPt or whatever the size is computed from). I will do that myself eventually, but it's a simple enough task that anyone can do it if they are so inclined. -mental References: http://sources.redhat.com/ml/libc-hacker/1998-06/msg00001.html http://users.bestweb.net/~ctips/tip028.html http://lists.freebsd.org/pipermail/freebsd-standards/2004-February/000395.h… http://www.ussg.iu.edu/hypermail/linux/kernel/0011.0/1122.html http://www.uclibc.org/downloads/Glibc_vs_uClibc_Differences.txt (item #4)

1 1

Fedora-2 RPMS
by Plinnell 29 Aug '04

29 Aug '04

Hi all, I've uploaded Fedora-2 rpms for 0.39, thanks to Phil Compton, one of the core Fedora packagers. The move is allmost done, so next time, there will be less delay. Cheers, Peter

1 0

Re: Re: Temp freeze + stuff
by Bob Jamison 29 Aug '04

29 Aug '04

bulia wrote: >Works! Though it is very slow for large images, almost as good as a >dead freeze. To make it usable, we need to provide a progress bar and >to make it interruptible in some way. Another problem is that it puts >the path into 0,0 instead of overlaying the original image; look up >sp_selection_tile in selection-chemistry that solves a similar problem >for Tile. Yeah, it's full of little problems for now. I just wanted to get something out there that people could see. The pathlist that is generated has the x,y coordinates relative to the top/left of the image. All we need to do is copy the x/y attribute of the <image> itself to the <path> and we can fix this. Path simplify works well to reduce the number of nodes. However, I'm sure there there is a tolerance setting or something in Potrace for estimating the curve and controlling the number of nodes output. I noticed the delay. At first, I thought it was the text output/repr parsing that was slowing it down, but it is not. The tracing takes all of the time, and the output is very quick. I'll look at the tiling stuff you mentioned. Maybe execute this in a thread? Maybe not; we might -want- the user to see the delay, so he realizes that it is an expensive operation on large images. Hey, we need an animated 'Busy' icon. How about a potato sleeping on a couch? ;-) Would be appropriate for many of us coders! Bob

1 0

Re: Temp freeze + stuff
by Bob Jamison 29 Aug '04

29 Aug '04

Oops. I haven't been able to use POP access to my email from home recently, so I didn't know about the freeze until just now, by reading it on the list archive on the website. I'll stop now :-). But in the meantime, I have gotten the Tracing operation to a limited initial functionality. Please give it a try. It will obviously need to be tested and tweaked. It will almost certainly need an associated dialog to adjust the settings. Please defer any feature suggestions until later... we just want to get it to work. To make it work, I embedded a copy of Potrace in Inkscape. Instead of using its full functionality of reading images and writing vectored output (that's OUR job), I just have it read the data from an <image>, and create an associated <path>. Eventually, I will probably make a generic Tracer class, with various tracing engines referenced by it. The basic function a tracer needs to perform, is to read a GdkPixbuf, and output the d="" attribute of a <path>; as long as an engine does that, we can consider it a black box. Sooo... give it a try. To use, load an image, select it, and choose "Trace image". That is all it takes. It will of course work much better on line art than a multicolored image. Currently, the color->line art conversion threshold is hardcoded at 50% brightness; this will of course be a future dialog item. So. I'm quitting coding for now... going back to debugging. (Hey, I found a good bug Friday, anyway ;-) Bob

2 1