After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 112818 - Pan crashes (Bus error) when compiled 64-bit/Solaris/Sparc
Pan crashes (Bus error) when compiled 64-bit/Solaris/Sparc
Status: RESOLVED FIXED
Product: gmime
Classification: Other
Component: general
unspecified
Other Solaris
: Normal normal
: ---
Assigned To: Charles Kerr
Pan QA Team
Depends on:
Blocks:
 
 
Reported: 2003-05-12 08:05 UTC by blue.meanie
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description blue.meanie 2003-05-12 08:05:31 UTC
Pan compiles (with pointer incompatibility warnings) as a 64-bit app on
Solaris Sparc, and crashes with a bus error when you attempt to view an
article with mime parts (plain text articles were all fine).

The problem appears to be because glib-2.0 defines the "len" component of a
GByteArray struct as a guint (see line 47 of glib-2.0/glib/garray.h), while
Pan attempts to treat it as a size_t in several places.  On 64-bit Solaris,
size_t and guint are not the same size, thus the bus error.

The fix is easy - I've applied it locally and Pan appears to work fine now
running 64-bit.  Simply change size_t to guint in the following five locations:

gmime/gmime-message.c:
  Line 975:
          guint len;
  Line 1045:
          guint len = 0;

gmime/gmime-part.c:
  Line 1177:
    g_mime_part_get_content (const GMimePart *mime_part, guint *len)

gmime/gmime-part.h:
  Line 119:
    const char *g_mime_part_get_content (const GMimePart *mime_part, guint
*len);

pan/base/pan-glib-extensions.c:
  Line 902:
    guint content_len = 0ul;

and re-compile.  No pointer warnings, and a stable Pan!  :)

I haven't checked these changes on a non-64-bit platform, but I can't see
any reason why they would cause problems.  size_t and guint are usually the
same size on 32-bit platforms, right?
Comment 1 Charles Kerr 2003-05-12 14:53:41 UTC
I've fixed this in Pan and am recycling the bug report for fejj's main
GMime repository so that the fix will also make it into GMime's main
branch.

Thanks...
Comment 2 Jeffrey Stedfast 2003-05-23 01:34:58 UTC
I'd rather the API still use size_t - it's more "correct", especially
since streams are all size_t-based.

that said, was pan passing a size_t into get_content()? or a guint? 

I'm just trying to understand why this would cause a bus error. it
sounds to me like you are suggesting an alignment error, except that
there cannot possibly be an alignment error there if pan's code also
uses a size_t unless the compiler is buggy.

this has an alignment error:

------------------------------------------------
guint len;

g_mime_part_get_content (part, &len);
------------------------------------------------

this does not:

------------------------------------------------
size_t len;

g_mime_part_get_content (part, &len);
------------------------------------------------


explanation:

len in the first example is only guarenteed to be 32bit aligned. but a
size_t on a 64bit system MUST be 64bit aligned. thus, a crash.

in the second example, though, len is already 64bit aligned.
Comment 3 Jeffrey Stedfast 2003-06-14 22:34:48 UTC
any new info on this? I'd appreciate it if someone could test gmime
cvs to make sure things are ok.
Comment 4 Jeffrey Stedfast 2003-08-09 17:48:04 UTC
*poke*
Comment 5 Jeffrey Stedfast 2004-02-14 02:03:06 UTC
assuming fixed