Re: [gmime-devel] GMimeFilterHTML: ignoring URL at the end of part?

[Jeffrey Stedfast <fejj gnome org>]

Hi Gaute,

Just to rule out gmime_iostream.cc, can you write a simple program to do 
this?

char buffer[4096];
ssize_t n;

while ((n = g_mime_stream_read (filtered_stream, buffer, 4096) > 0)
    write (1, buffer, n);

(in this case filtered_stream is your HTML filtered stream, set up the 
same way you are setting it up in chunk.cc)

It sounds to me like you are saying that priv->filtered has the data at 
line 231 in gmime-stream-filter.c? If so, then a subsequent call to 
g_mime_stream_read() should scoop up the remaining filtered data. If 
another call is not being made to g_mime_stream_read(), then it sounds 
like a bug in gmime_iostream.cc.

Presumably at some point, g_mime_stream_read() is reading 0 bytes from 
the source stream, and so the "if (nread <= 0) ..." code-path is taken 
(line 191). At this point, the g_mime_stream_eos() check on the source 
stream should return true, and priv->flushed should be false, so it 
should go into that code-path and loop over all of the filters calling 
the complete() method on them. At the end of that loop, 
priv->filteredlen should have a value > 0 which means that the "if 
<nread <= 0) return nread" check should fail, allowing the code to fall 
through to the end of the function which will copy data from 
priv->filtereddata into your buffer.

Hope that helps explain how things *should* work... whether they do or 
not, I can't tell, because I can't get gmime to build on my Mac yet :-(

Jeff

On 4/9/2015 3:44 AM, Gaute Hope wrote:
> Excerpts from Gaute Hope's message of September 11, 2014 8:44:
> > Excerpts from Jeffrey Stedfast's message of September 10, 2014 15:21:
> > > Hi Gaute,
> > >
> > > I suspect that the problem is that you are pulling data through the 
> > > filter as opposed to pushing data through it. The complete() method 
> > > of the GMimeFilterHTML filter is probably not getting called when 
> > > the end of the stream has been reached (which it needs in order to 
> > > recognize that the url is complete).
> > >
> > > If this is the case, then it's a bug in GMime, but I'm not sure 
> > > where. The bug is probably in GMimeStreamFilter's stream_read() 
> > > implementation, but I do not currently have a development machine 
> > > that I can use to test/debug this.
> > >
> > > If you could step through gmime-stream-filter.c's stream_read() in a 
> > > debugger and see if the code-path that calls the complete() method 
> > > on each filter is called, that would at least tell us if my theory 
> > > is correct or if it is actually a bug in GMimeFilterHTML's logic 
> > > instead.
> >
> > Hi Jeff,
> >
> > I've tried stepping through GMimeStreamFilter's stream_read(), but I
> > haven't been able to make any sense of it yet.
> >
> > It seems that the last part of the text is at some point converted to
> > HTML, but that it is done in a separate iteration (shows up when I put a
> > breakpoint before return at line 231). All this using version 2.6.20 of
> > gmime.
> >
> > In short, I have not been able to figure out what the problem is yet.
> > All the filters seem to be run through the complete() method though.
> >
> > I won't have time to try any more this week.
> >
> > Thanks for the help so far,
> > Gaute
>
> Hi again Jeff + list,
>
> as you have probably noticed I put up a bug report (#744417 [0]) for
> reference.
>
> I've also largely isolated the issue in a test case for my
> implementation [1] with a test email [2]. Do you have any other hints
> for how I can either change my implementation to 'push' data through the
> filter or debug the issue in gmime?
>
> This bug (wherever it is..) keeps coming back and biting me..
>
> Regards, Gaute
>
> [0] https://bugzilla.gnome.org/show_bug.cgi?id=744417
> [1] https://github.com/gauteh/astroid/issues/16
> [2] 
> https://github.com/gauteh/astroid/blob/master/test/mail/test_mail/no-nl.eml