Hello Cyril,
On Sat, Apr 09, 2016 at 10:43:11AM +0200, Cyril Chaboisseau wrote:
> Sorry Carsten for rushing things out and not giving the proper feedback
> (backtrace et al), but I really thought that before looking more
> precisely into the bug, we would first have to avoid that other users
> from being hit with this crash (conflicts?)
>
> anyway, here is the bt:
> [SNIP]
your posted gdb log doesn't contain a useful backtrace, it's only a log
of the thread 1.
At the Debian Groupware Meeting on the last weekend we tried to debug
the problem a little bit. It's more or less a Icedove bug that provoke a
segfault while setting up the proxy settings. The relevant part look
like this in a gdb session:
> Program received signal SIGSEGV, Segmentation fault.
> nsProtocolProxyService::ApplyFilters (this=this@entry=0x7fffd9a22ee0,
> channel=channel@entry=0x7fffc0af4800, info=...,
> list=list@entry=0x7fffffff6990)
> at
> /build/icedove-nkxIAZ/icedove-38.6.0/mozilla/netwerk/base/nsProtocolProxyService.cpp:1885
> warning: Source file is more recent than executable.
> 1885 getter_AddRefs(result));
> (gdb) list
> 1880 if (iter->filter) {
> 1881 nsCOMPtr<nsIURI> uri;
> 1882 rv = GetProxyURI(channel, getter_AddRefs(uri));
> 1883 if (uri) {
> 1884 rv = iter->filter->ApplyFilter(this, uri, *list,
> 1885 getter_AddRefs(result));
> 1886 }
> 1887 } else if (iter->channelFilter) {
> 1888 rv = iter->channelFilter->ApplyFilter(this, channel, *list,
> 1889
> getter_AddRefs(result));
The problem is the getter function getter_AddRefs(). This function is
untouched since ages. Some basic description on how to use this stuff can be
found on the Mozille Developer Reference.
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Using_nsCOMPtr/Reference_Manual
> BTW, anyone with a valid pop/imap account can reproduce this bug
>
> one would just need to install the xul-ext-foxyproxy-standard package,
> launch icedove with a blank config directory, setup an account and
> witness the crash/segfaults
Yes, "you just need ..."
Pleas understand that we can't just test and use every plugin that is
available. And the foxyproxy plugin is one of the more complicated
plugins as the settings you can make a numerous.
So we are depending on your investigation as much as possible. So as
Christoph has tested the regular Thunderbird release and the issue is
happen there too someone would need to create a upstream bug. This is
done best by a person that is knowing the foxyproxy thing better. Would
you create such a report and provide the URL of this?
Regards
Carsten
