Discovered because of a crash in the Pan newsreader, but the actual bug is
in gmime code.  The code referenced is from the gmime code included with
Pan release 0.14.2.90.

In gmime-parser.c, the function parser_scan_mime_part_content() does not
properly handle zero-length mime parts.  When a mime part has zero length
(the part's headers are followed by a single blank line, then immediately
by another boundary), the call to g_mime_stream_substream() at line 988 is
made with the value of "end" one lower than the value of "start".  The
result is that the stream-parsing code wanders off unrestrained in memory,
and either results in the program consuming all available memory, or - more
often - crashing with a segmentation fault.

Below is an example of a mime message that will trigger the problem. 
Notice the single blank line between "7bit" and the following boundary. 
That is the location where the parser fails.
---------------------begin example message---------------------
Mime-Version: 1.0
Content-Type: multipart/mixed;
        boundary="example boundary"

This is a multi-part message in MIME format.

--example boundary
Content-Type:text/plain;
Content-Transfer-Encoding: 7bit

--example boundary
Content-Type: image/jpeg;
Content-Transfer-Encoding:uuencode

begin 666 picture.jpg
M8V1E9F=H:6IS='5V=WAY>H.$A8:'B(F*DI.4E9:7F)F:HJ.DI::GJ*FJLK.T
MM;:WN+FZPL/$Q<;'R,G*TM/4U=;7V-G:X>+CY.7FY^CIZO'R\_3U]O?X^?K_
----------------------end example message----------------------

This is a known bug in gmime, and was already corrected several months ago
according to the gmime maintainer.  However, a rather significant number of
other changes have been made to the gmime code tree, and the current
release of gmime cannot be used with Pan 0.14.2.90 (url_extract() is
missing, along with a few other functions Pan uses).  I assume a future
release of Pan will be updated to use the newer gmime code.

In the meantime, the following VERY UGLY HACK will work around the problem.
 Add the following tweak to lines 987-988 of gmime-parser.c:

     if (priv->seekable) {
+           if (start > end)
+                  start = end;
           stream = g_mime_stream_substream (priv->stream, start, end);

Yes, it's hideous, but it works until and unless something more elegant can
be done.  :)  I acknowledge that messages like these should probably be
considered malformed, but I have encountered more than one such message "in
the wild", and tolerance of the error condition (as opposed to a runaway or
crashing program) is nice to have.