Re: [Gimp-developer] Another plugin question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Thomas RIBO <tharibo@xxxxxxx> writes:

> Sorry to interrupt your (more important) conversation, but I still have 
> problems with plugins.
> I really can't figure out why my plugin runs on and on and.... finally 
> stopping some minutes later with a segmentation fault.
> I don't have infinite loop (I trust, but maybe there are hidden one, 
> who knows =) but I think I'm doing something not the proper manner.
> Could someone just have a lookup on my code to see if he (her) finds 
> anything with my use of libgimp?
> 
> The code is here : http://tharibo.free.fr/GIMP/Textures.tar.gz
> There are a C file, a header file and their Makefile.

there are several flaws in your plug-in (see below) but the main
problem is that you are trying to access data outside the
drawable. The offending code is the calculation of the pixel_region 
in variencyMethod():

 unsigned startRow = (unsigned) WINDOW_SIZE /2;
 unsigned endRow = inputDrawable->height - (unsigned) WINDOW_SIZE /2;
 unsigned startCol = (unsigned) WINDOW_SIZE /2;
 unsigned endCol = inputDrawable->width - (unsigned) WINDOW_SIZE /2;

 for(col = startCol; col <= endCol; col++)
   {
     unsigned startColWindow = col - (unsigned) WINDOW_SIZE /2;
     unsigned startRowWindow = row - (unsigned) WINDOW_SIZE /2;

     gimp_pixel_rgn_init(&window, inputDrawable,
	 		 startColWindow, startRowWindow,
			 WINDOW_SIZE, WINDOW_SIZE,
			 FALSE, FALSE);

     ...
   }

you assume that WINDOW_SIZE/2 + WINDOW_SIZE/2 == WINDOW_SIZE
but since WINDOW_SIZE is odd (5) this is not true and you end up 
going one pixel too far, thus trying to access a tile outside 
the drawable. I was surprised that our error checking in libgimp
is that bad, but there's not much we can do about that now.

Some other flaws I've noticed are:

- average() and variency both use a wrong index into the data
  array thus accessing the wrong data. Your loops should go from
  0 to width/height, not from x to x + width, resp. y to y + height
  and using region->rowstride and region->bpp here does not make
  sense.

- You should use g_malloc() or even better g_new() instead of
  malloc(). This is a nitpick for most platforms but generally
  good style when working with glib.

- You should actually free the allocated memory.

- You don't take bpp into account, but then your plug-in only 
  works for GRAYSCALE anyway.

- You would do good to allocate a tile cache to speed things up.

- Your use of unsigned variables will bite you for small images:

  unsigned endRow = inputDrawable->height - (unsigned) WINDOW_SIZE /2;

  This will give unpleasant results for a height smaller than
  WINDOW_SIZE/2. Well, lots of plug-ins have these problems with
  very small images and simply using a signed variables doesn't
  solve the problem (but probably makes it more obvious).


Salut, Sven


[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux