Thanks for a bug report. it seems to me that these are caused in a cycle, by reuse of one GError instance. It'll be nice to get backtraces of say two of them, thus it'll be easier to check who reused the GError structure, though the error on CamelTcpStreamSSL::read() suggest pretty well that it did something wrong.

I checked the code and CamelTcpStreamSSL::read() uses CamelTcpStreamRaw::read(), which is setting GError only if the read failed, thus the GError is most likely left from other call. Would it be possible to get a backtrace for the warning, please? You can do that with gdb if you run evolution under it like this:
   $ gdb evolution --ex "b g_logv" --ex r
and when the gdb stops with the GLib-WARNING, then get a bactrace with:
   (gdb) bt
command.

I'm guessing Paul is using an IMAPX account.  IMAPX still has a some missing error checking which I didn't get time to fix for 3.6.  It's at the top of my list for 3.7.

(In reply to comment #0)
> Using Debian Sid/unstable and having upgraded from 3.2 to 3.4.3, the first
> start of Evolution 3.4.3 went fine. After closing it without problem and
> restarting the whole system, it now started by no messages are displayed and
> only »Nachrichtenliste wird erzeugt …« (translation: Compiling message list …)
> is shown. On the terminal I see a lot of errors.

First to clarify the not starting issue, looking through the backtrace I see that a password dialog is opened, but which is not displayed. This seems to be a similar issue to bug 657886 but this has not happened for a long time and just started again after upgrading from 3.2.2 to 3.4.3 and GTK+ was already upgraded *before* so was used by 3.2.2 just fine for some time.

This is related to probably using a Awesome as a window manager and not GNOME with Metacity(?).

[…]

(In reply to comment #4)
> (In reply to comment #0)
> > Using Debian Sid/unstable and having upgraded from 3.2 to 3.4.3, the first
> > start of Evolution 3.4.3 went fine. After closing it without problem and
> > restarting the whole system, it now started by no messages are displayed and
> > only »Nachrichtenliste wird erzeugt …« (translation: Compiling message list …)
> > is shown. On the terminal I see a lot of errors.
> 
> First to clarify the not starting issue, looking through the backtrace I see
> that a password dialog is opened, but which is not displayed. This seems to be
> a similar issue to bug 657886 but this has not happened for a long time and
> just started again after upgrading from 3.2.2 to 3.4.3 and GTK+ was already
> upgraded *before* so was used by 3.2.2 just fine for some time.
> 
> This is related to probably using a Awesome as a window manager and not GNOME
> with Metacity(?).
> 
> […]

I forgot to add, that in Awesome quite often maximizing and unmaximizing the Evolution seems to get the password dialog to show up.

(In reply to comment #2)
> I checked the code and CamelTcpStreamSSL::read() uses
> CamelTcpStreamRaw::read(), which is setting GError only if the read failed,
> thus the GError is most likely left from other call. Would it be possible to
> get a backtrace for the warning, please? You can do that with gdb if you run
> evolution under it like this:
>    $ gdb evolution --ex "b g_logv" --ex r
> and when the gdb stops with the GLib-WARNING, then get a bactrace with:
>    (gdb) bt
> command.

Thank you for the instructions. The breakpoint was hit even before a window showed up.

Breakpoint 1, g_logv (log_domain=log_domain@entry=0xb7c894d7 "Gtk", log_level=log_level@entry=G_LOG_LEVEL_DEBUG, 
    format=format@entry=0xb7c92ba4 "Connecting to session manager", args1=args1@entry=0xbffff0ec "\244\274r\267\070F-\200\002")
    at /build/buildd-glib2.0_2.32.3-1-i386-987P8N/glib2.0-2.32.3/./glib/gmessages.c:661
661	/build/buildd-glib2.0_2.32.3-1-i386-987P8N/glib2.0-2.32.3/./glib/gmessages.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt

+ Trace 230758

I hope that is good enough to help you figure out what is going on.

By the way, to surpress the copyright and introductory message you can pass `-q` to `gdb`.

(In reply to comment #6)
> Breakpoint 1, g_logv (log_domain=log_domain@entry=0xb7c894d7 "Gtk",
> log_level=log_level@entry=G_LOG_LEVEL_DEBUG, 

I might also note that g_logv is basically for all logging through glib, thus even for debugging logs. See above "G_LOG_LEVEL_DEBUG" and log_domain being "Gtk". We are looking for log_level GLib and type warning or critical, or the name I forgot they use for these messages - it's just not debug :)

The maximizing - I suppose your window manager hides the password prompt below main Evolution window and even the prompt came (I suppose) after creation of the Evolution's window, then it's just below it, instead of above. In other words, you are right this is caused by the window manager, rather than by a bug in evolution's code. Nonetheless, 3.6.0 will use system dialog, the one provided by Gcr, thus this should be fixed by newer version of evolution.

(In reply to comment #7)
> (In reply to comment #6)
> > Breakpoint 1, g_logv (log_domain=log_domain@entry=0xb7c894d7 "Gtk",
> > log_level=log_level@entry=G_LOG_LEVEL_DEBUG, 
> 
> I might also note that g_logv is basically for all logging through glib, thus
> even for debugging logs. See above "G_LOG_LEVEL_DEBUG" and log_domain being
> "Gtk". We are looking for log_level GLib and type warning or critical, or the
> name I forgot they use for these messages - it's just not debug :)

I am sorry for giving you the wrong trace. It looks like Matthew is right in comment #3. At least IMAP is mentioned in the trace. ;-)

Breakpoint 1, g_logv (log_domain=log_domain@entry=0xb768948e "GLib", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=
    0xb768cf20 "GError set over the top of a previous GError or uninitialized memory.\nThis indicates a bug in someone's code. You must ensure an error is NULL before it's set.\nThe overwriting error message was: %s", 
    args1=args1@entry=0xa2bfea5c "\320\357A\201`\027\374\251`\027\374\251\272<\261\261\203\022\373\251\274\360\277\242\251\017")
    at /build/buildd-glib2.0_2.32.3-1-i386-987P8N/glib2.0-2.32.3/./glib/gmessages.c:661
661	in /build/buildd-glib2.0_2.32.3-1-i386-987P8N/glib2.0-2.32.3/./glib/gmessages.c

+ Trace 230760

(In reply to comment #7)

[…]

> The maximizing - I suppose your window manager hides the password prompt below
> main Evolution window and even the prompt came (I suppose) after creation of
> the Evolution's window, then it's just below it, instead of above. In other
> words, you are right this is caused by the window manager, rather than by a bug
> in evolution's code.

The strange thing is, that I looked for the password window in the window list and there was none. If it is displayed there is at least an entry in the window list.

Furthermore I stress again, that only Evolution was upgraded. All other (GTK) components had been upgrade some weeks beforehand.

> Nonetheless, 3.6.0 will use system dialog, the one provided by Gcr, thus this should be fixed by
> newer version of evolution.

Let’s hope so. ;-)

Created attachment 223075 [details] [review]
proposed eds patch

for evolution-data-server;

I see in the backtrace that this particular issue is going from imap provider (not imapx), though it can be common for any provider using Camel TCP SSL stream. The chunk in "tcp_stream_ssl_connect" makes sure that if connecting with SSL fails, enabling it on the connection fails, then an error is reported as expected. The advantage (or disadvantage?) of this change is that the connection will be always SSL, if user set it to be SSL, and if SSL enabling fails, then the function reports error state, not success. It is correct to follow user's setup strictly, isn't it? The other chunks try to not propagate error when reports success.

I cannot test this, it works fine for me, thus I would like to ask whether you can compile eds with the patch included and verify the error will be gone. You might see, probably, the "Connection reset by peer" error in UI, if not hidden elsewhere in the code.

(In reply to comment #10)
> Created an attachment (id=223075) [details] [review]
> proposed eds patch
> 
> for evolution-data-server;
> 
> I see in the backtrace that this particular issue is going from imap provider
> (not imapx), though it can be common for any provider using Camel TCP SSL
> stream. The chunk in "tcp_stream_ssl_connect" makes sure that if connecting
> with SSL fails, enabling it on the connection fails, then an error is reported
> as expected. The advantage (or disadvantage?) of this change is that the
> connection will be always SSL, if user set it to be SSL, and if SSL enabling
> fails, then the function reports error state, not success. It is correct to
> follow user's setup strictly, isn't it? The other chunks try to not propagate
> error when reports success.
> 
> I cannot test this, it works fine for me, thus I would like to ask whether you
> can compile eds with the patch included and verify the error will be gone. You
> might see, probably, the "Connection reset by peer" error in UI, if not hidden
> elsewhere in the code.

I finally was able to build e-d-s [1] to tested your patch. It works great. I do not see these error messages anymore. Is that patch needed for master? If yes, it would be great if you could include your explanation from above to the commit message to make it easier for me to explain to the Debian maintainers why they should included that patch?

Additionally could you please cherry pick that patch to the 3.4 branch?


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686941

By the way, last question. Was that error caused by a specific IMAP account or by all of them?

Yup, patch target is for git master. The gnome-3-4 branch is effectively dead now, there is not planned any update for that version, thus I would rather not commit it there.

Regarding the explanation in the commit, I like the bug numbers being clickable, thus one can see whole story about the change, rather than summarizing it to few sentences. I agree that bug reports can be sometimes long and hard to read, but it's still the place where the change can be discussed.

I believe it was caused by specific account/server. I use IMAP too, but I do not see these warnings with my server. But it's better to understand this the other way, your server uncovered bug in evolution's IMAP code.

Created commit efc20ad in eds master (3.5.92+)

(In reply to comment #13)

[…]

> Regarding the explanation in the commit, I like the bug numbers being
> clickable, thus one can see whole story about the change, rather than
> summarizing it to few sentences. I agree that bug reports can be sometimes long
> and hard to read, but it's still the place where the change can be discussed.

I moved the discussion to the list. [1]

[…]

Thanks for your fix!


[1] https://mail.gnome.org/archives/evolution-list/2012-September/msg00015.html