Hey,

Run Pan inside of gdb and set a breakpoint for g_log.  That will let
you get a backtrace on the g_object_ref assertion message, and you
can attach that backtrace to this ticket in the comments...

% gdb pan
(gdb) break main
(gdb) r
(gdb) break g_log
(gdb) c
...
breakpoint 2 reached
(gdb) bt
g_log ...
g_message ...
g_object_ref ...

Created attachment 87551 [details]
backtrace as requested in comment #1 from Charles Kerr

Not sure if this will show anything much…

Here's a patch to get some more information:

Index: pan/gui/body-pane.cc
===================================================================
--- pan/gui/body-pane.cc        (revision 260)
+++ pan/gui/body-pane.cc        (working copy)
@@ -864,6 +864,7 @@
     GdkPixbuf * original (get_pixbuf_from_gmime_part (part));
     const bool fullsize (!_prefs.get_flag ("size-pictures-to-fit", true));
     GdkPixbuf * scaled (size_to_fit (original, fullsize ? 0 : widget_size));
+std::cerr << LINE_ID << " original " << original << " scaled  " << scaled << std::endl;
 
     if (scaled != 0)
     {

This will show us whether we're failing to pump the picture out of
the GMimeMessage, or whether we'e failing to scale it properly...
my money's on the GMimeMessage.

(In reply to comment #3 from Charles Kerr)
> Here's a patch to get some more information:
> 
> Index: pan/gui/body-pane.cc
> ===================================================================
> --- pan/gui/body-pane.cc        (revision 260)
> +++ pan/gui/body-pane.cc        (working copy)
> @@ -864,6 +864,7 @@
>      GdkPixbuf * original (get_pixbuf_from_gmime_part (part));
>      const bool fullsize (!_prefs.get_flag ("size-pictures-to-fit", true));
>      GdkPixbuf * scaled (size_to_fit (original, fullsize ? 0 : widget_size));
> +std::cerr << LINE_ID << " original " << original << " scaled  " << scaled <<
> std::endl;
> 
>      if (scaled != 0)
>      {
> 
> This will show us whether we're failing to pump the picture out of
> the GMimeMessage, or whether we'e failing to scale it properly...
> my money's on the GMimeMessage.

The above patch gives:
>>>>
(pan:9465): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
(body-pane.cc:867:append_part) original 0 scaled  0
<<<<

btw I neglected to mention the only thing shown in the body window is:
Attachment not shown: MIME type image/jpeg; filename Faith Hill-The Secret Of Life(dvd-2nafish).jpg
(of course ;) )

Thanks.

Just saw this mentioned on the user list, and can confirm.  Gentoo/~amd64 here, gtk+-2.10.12 also, of course built from source as that's what Gentoo /does/.  I'm now running pan svn r273.

Duncan

SciFi, what platform are you on?  You say built and installed, but not on what, hardware or software.  It isn't 64-bit by chance, is it?  Reason I ask is I am and have the problem, someone reported in the group/list that they don't, with at least the same gtk+ version.  Also, what versions of gcc/binutils/glibc (or other libc if not Linux)?  Here's the versions you reported of other things and my current versions.  I'm not sure what findutils has to do with pan, and esound as you mention, but anyway...

(-r# is second or higher Gentoo revision of upstream version)
package     Duncan ver    =?  SciFi ver
Hardware    2xOpteron 242     ?
OS          Gentoo/~amd64     ?
Desktop     KDE-3.5.6         ?
gcc         4.1.2             ?
glibc       2.5-r2            ?
binutils    2.17              ?
xorg-server 1.3.0.0           ?
findutils   4.3.4         =   4.3.4
libidn      0.6.9-r1      <   0.6.12
atk         1.12.4        <   1.19.1
pango       1.14.10       <   1.16.4
cairo       1.4.6         =   1.4.6
esound      n/a           x   0.2.37
glib        2.12.11       <   2.13.1
gmime       2.2.3         <   2.2.8
gtk+        2.10.12       =   2.10.12
pan         svn           =   svn

(In reply to comment #6 from Duncan)
> SciFi, what platform are you on?

Some clues you seek are in the backtrace I attached.  ;)

Also the OS field on this bug-report says "Macintosh" -- they probably need to start extending that choice-list as there are three kinds of PPCs and two or more kinds of x86s being supported by the vendor.  ;)

We don't normally compile with -arch ppc64 even on the G5.  That requires *>EVERYTHING<* up the chain to need -arch ppc64.  Since 99.999% are compiled with -arch ppc (by the vendor and everyone else), if we want 64-bit support we then must compile everything with /both/ -arch ppc /and/ -arch ppc64 specified in CxFLAGS everywhere, and I do mean everything (libraries linked to, frameworks, everything).  I'm not going to do that, quite simply because there's still too much closed-source stuff that we aren't privvy to compile ourselves, and also because most projects aren't (yet if at all) capable of handling multi-cpu objects sometimes known as "universal binaries" -- the projects would likely require knowing how to stitch together the (separate?) .o's with the lipo tool, and I must defer fixing configure & makefile scripts to do that for better experts.  ;)

But we do normally add -mpowerpc64 to the CxFLAGS.  According to man gcc here, this allows gcc to use/generate the extra machine instructions, and treats GPRs as 64-bit, but not alter the runtime-mode (-arch does that).

By that token, we also normally add -mpowerpc-gpopt (gives us hardware sqrt() among others) and -mpowerpc-gfxopt (extra graphics & floating-point instructions on chip).

We add -maltivec in hopes that gcc might be smart enough to "auto-vectorize" some of the source.

The -fast gcc option has known bugs (known to me anyway ;) ) but I've not built glib & gtk with anything out of that group "on purpose".

I try adding -ftree-vectorize (many platforms support this, not unique) but our version of gcc has rare problems here, too, resulting from miscompiled objects (parchive.sf.net aka par2 is a known repeatable case), and some source code can cause "internal gcc errors" if not outright gcc crashes during compilation with this option.  I won't compile gtk or glib with this option, and several other projects, either (sadly, as it can make some loops much more efficient).

In short, we ought to be running pan2 & all cohorts in 32-bit mode here.  ;)

My experience on FreeBSD/x86 was such that the Gnome/KDE/etc. components ought to be at common release levels -- not equal in numbers of course, but time-line when released.  By this I mean pango & atk ought not be so back-level as Duncan's list suggests.  The glib component has two active versions going, but I think Duncan's 2.12.11 is still one step behind equivalently to my 2.13.1.  Gnome esp. usually puts out releases in related groups like this; they may be a few days apart, but they're designed as a group none-the-less.  And then the components need to be built in a certain order, which I've tried to stress when listing my versions; if any other project uses static libs, /those/ projects need to be rebuilt, too.  (I hope I'm clear, it's not a good day for me today.)

All that said, here's more tidbits:

$ gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)

$ uname -a
Darwin SciFiG5.homeip.net 8.9.0 Darwin Kernel Version 8.9.0: Thu Feb 22 20:54:07 PST 2007; root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh powerpc PowerMac7,3 Darwin
(that's the Dual G5 2.7GHz)

XFree86 Version 4.6.99.23 / X Window System
(protocol Version 11, revision 0)
Release Date: 7 May 2007
(freshly built from cvs this weekend as I type this ;) )

coreutils-6.9

make-3.81.90+(cvs) <-- he just accepted our ObjC patches!

glibc and binutils are non-sequiturs here; whatever the vendor provides with OSX & XCode 2.4.1 are what we got, and it's not clear where those pieces come from.  These will not compile here as-is, I've tried & tried...

Clearly it was the jump from the previous grouping of gnome components that put me in this quandry of not being able to view in-line pictures at all.  The previously released grouping would work with 1-or-2 parts, then we're into bug #426377.

Hoping more ppl will chime-in; there's got to be a common problem somewhere, but I'm thinking it's some undocumented (or unclearly documented) changes at this point.  ;)

Thanks for helping.

Just a quick update to note this bug #435863 is still in r293, even tho bug #439841 and bug #426377 have been fixed, which I cannot verify of course since this bug gets in the way.  ;)

Updated components since my original list in this ticket:

gperf-3.0.3 (2 weeks ago)
findutils-4.3.5 (last week)
pango-1.17.0 (fresh, from 1.16.4, see my post in pan-users)
esound-0.2.38 (irrelevant I know ;) )
pcre-7.1 (2 weeks ago)
pan_svn/pan2 r293

Also went thru all components to see if they detected anything needing remaking, and sho'nuf they did.  I feel rather certain we have a homogeneous group of executable code running here with all the updates.  ;)

Again I want to stress:
gmime-2.2.8
was upgraded two weeks ago, well before other gnome bits were updated to cause this particular bug.

Thanks.

As an aside, gmime 2.2.9 is out and is a recommended upgrade.

If you save the images in Pan, can you view them with another gtk+ application
like gqview, eog, or the gimp?

Okay this is apparently one of those multi-level problems that I really hate to get involved with.  Bear with me please.  ;)

A big clue came along with the post to pan-users I made here:
<http://lists.gnu.org/archive/html/pan-users/2007-05/msg00124.html>
or
<http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/8796>
or
<news://news.gmane.org/pan.2007.05.20.05.46.37@hush.ai>

The newer gnome components from the past couple weeks or so were starting to act weird.  As I mentioned in pan-users, starting with pango-1.16.4 and continuing with pango-1.17.0, the make-install script generated an "empty" pango.modules file under /usr/local/etc/pango/ .

Later when gtk+-2.10.12 came out, it also installed "empty" files for gdk-pixbuf.loaders & gtk.immodules under /usr/local/etc/gtk-2.0/ .

Then I posted another blurb here with another clue:
<http://lists.gnu.org/archive/html/pan-users/2007-05/msg00140.html>
or
<http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/8812>
or
<news://news.gmane.org/pan.2007.05.25.09.59.12@hush.ai>

Here's the crux of the matter.

I don't know why the GNU libtool team inserted this bit of code inside libtool.m4 & other macros several years ago, which is now ubiquitously in use:
>>>>-snip-start-[1]->>>>
case $host_os in
[...]
darwin* | rhapsody*)
[...]
  shrext_cmds='`test .$module = .yes && echo .so || echo .dylib`'
[...]
<<<<-snip-end-[1]-<<<<

Many projects such as the glib tarball have this bit of code inside their configure scripts:
>>>>-snip-start-[2]->>>>
module=yes eval std_shrext=$shrext_cmds
<<<<-snip-end-[2]-<<<<
This eval[2] together with snip[1] above is giving darwin builds a '.so' suffix, but ought to be '.dylib'.  Note this eval[2] is usually in common sections of configure scripts, not in platform-specific sections.

Here's my theory.  When pango & glib & gtk etc. install scripts want to scan their "private" libraries e.g. under /usr/local/lib/pango/<version>/ to generate those listings kept under /usr/local/etc/ , the Apple loader isn't seeing the .so's, so we get "empty" listings (nothing useful past the several lines of #comments).

I could "force" the scanners to read each file under those "private" libs in this manner:
# cd /usr/local/etc/gtk-2.0
# gdk-pixbuf-query-loaders /usr/local/lib/gtk-2.0/2.10.0/*/* >gdk-pixbuf.loaders
# gtk-query-immodules-2.0 /usr/local/lib/gtk-2.0/2.10.0/*/* >gtk.immodules
# cd /usr/local/etc/pango
# pango-querymodules /usr/local/lib/pango/1.6.0/modules/* >pango.modules

These will force the gnome components to load .so's even against darwin's druthers, but I don't like having to remember to manually rebuild these listings during an upgrade.  ;)

To do this properly, I'm patching libtool & configure scripts everywhere to force this assignment instead of the test string snip[1] above:
shrext_cmds='`echo .dylib`'
(yes it needs to be done in such a way that an eval will work right, and yes I know many projects comment their scripts with "darwin sux" for this very thing alone)

Now the components are being installed with .dylib suffixes, and their install scripts can find & generate the necessary listings fine.  And I can now view in-line pix with pan2!

I don't know why GNU libtool even wants to test for module=yes[1] inside the darwin sections (and *only* the darwin sections), and I can't find any discussion on this anywhere for the past several years!

I suppose we /could/ patch all projects to get rid of module=yes shown in snip[2] above, but this might break builds on other platforms.  Instead, I think we should take this to the libtool team to see why snip[1] was put in there in the first place, because it is now starting to cause weird problems in too many projects.

What do you-all think?  Thanks for helping.

I have been using Pan for ages and just upgraded to Fedora 11 (64 bit) and find that I am getting this problem on my system.  Running pan from the command line I get these messages everytime I click on an image that won't display in the message window.
This is the error message in the message window.

Attachment not shown: MIME type image/jpeg; filename DOCTOR.WHO.202.THE.NEXT.DOCTOR.DVD9.PAL.SUBS.jpg

These are the messages in the terminal.

(pan:12983): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion `GDK_IS_PIXBUF (pixbuf)' failed

(pan:12983): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion `GDK_IS_PIXBUF (pixbuf)' failed

(pan:12983): GdkPixbuf-CRITICAL **: gdk_pixbuf_scale_simple: assertion `GDK_IS_PIXBUF (src)' failed

(pan:12983): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed


I can save the image with no problems.

See bug
"Bug 587924 – gdk-pixbuf regression: JPG file does not load"

Looks like this is an issue with gtk+ and not pan.

I get the same error message as MeSat's.
System: Fedora 11 32bit.
Pan version: 0.133 (default RPM install)

Thanks for taking the time to report this bug.
However, you are using a version that is too old and not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use.

By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME.
Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME.