xffm crash report

[edscott wilson garcia]

Hey Olivier,

On Wed, 2003-09-03 at 17:21, Olivier Fourdan wrote:
> Edscott,
> 
> I'm experiencing a crash (sig 11) with latest xffm (bt attached)
> 
> What's puzzling me is that it seems you added features as the font now
> scale with the view size (and the crash seems to be related to fonts and
> pango). We are supposed to be in feature freeze for a couple of months,
> focusing exclusively on bug fixes.

Yes, to the best of my knowledge, I have been focusing on bug fixes. The
font resize with iconsize changes was not working (a minor bug) because
it was commented out. So I uncommented it. The other changes are with
the history list not working as supposed to (another bug) or not working
on all combos it was set to work (a third bug). That was fixed. Also, a
minor cosmetic bug was that some menu items did not have a little icon
when they were supposed to, for overall coherence.

> 
> I'm a bit worried with the current state of xffm. Such errors should not
> happen in a RC cycle... Looks like a regression to me. That problem was
> not showing previously.

The font resizing code was in there, but for some reason it was
commented out. I don't remember why, but I think it was because I was in
the "single font size mood" and forgot to uncomment before commit to
CVS. The reason for the font resize is that when icons grow smaller more
columns will fit in the same window. The font resize code was created
along with the icon resize code. 

Anyways, I will comment out the font resize so you can be sure the crash
is not related to the font resize (now committing to CVS...). Although I
could bet you a bottle of cognac (or tequila) that the font resize
routine has nothing to do. The bottle could be delivered overnight if
you wish to take the bet... ;-)

> 
> Btw, here is how to reproduce the problem: I have a folder with
> pictures, but some don't show the preview (why? no idea) So I left click

Previews are not generated for files of less than XFFM_MAX_PREVIEW_SIZE
(set in mcs, for performance reasons on slower boxes) and only for files
of the following extensions, as defined in libs/constants.h:

#define IS_IMAGE(x)	(strstr(x, ".tif") || strstr(x, ".TIF") ||  \
			 strstr(x, ".png") || strstr(x, ".PNG") || \
			 strstr(x, ".GIF") || strstr(x, ".gif") || \
			 strstr(x, ".JPG") || strstr(x, ".jpg") || \
			 strstr(x, ".JPEG") || strstr(x, ".jpeg") || \
			 strstr(x, ".XPM") || strstr(x, ".xpm") || \
			 strstr(x, ".pm") || strstr(x, ".PM") || \
			 strstr(x, ".bmp") || strstr(x, ".BMP")) 

Should others be added? I believe all these are supported by the gtk
function  gdk_pixbuf_new_from_file().

(In 4.2 strstr() should be replaced by a regexp evaluation with a $ at
the end, sometime in the future, to avoid a very small bug nobody has
noticed, nor probably will, but can be seen in the above code).

> on one of these pictures to get the contectual menu and xffm cores.
> 
> Backtrace attached.

I cannot reproduce it here. From the backtrace it looks like the issue
is with a menu_image_item that has got an invalid pointer for text in
the accelerator field...  

A couple days ago I did convert a menu_item to menu_image_item so that
it would have a little icon (like the other menu entries). It should not
produce any problems unless there is a library mixup since the
menu_image_item is created by xffm but accessed one of the xffm
libraries for the do_popup function (which appears in traceback).
I still have not figured out how to avoid "make uninstall && make
install" without introducing unnecessary library version numbering.  

Please check again without font resizing (but without make uninstall)
and then again with "make uninstall && make install". 

O, and I remember, I also added an extra column to the treemodel which
is not used, but will be used in 4.2. That column I can remove if you
want. It does no good nor harm at the moment. 

regards,

Edscott
 


> Cheers,