Description of problem: Version-Release number of selected component (if applicable): Fedora 16 / Evolution 3.2.2 How reproducible: Always Steps to Reproduce: 1. Open a VPN connection (pptp in my case) 2. Launch Evolution 3. Click on "New" 4. Send the email or try to save it as draft. 5. Evolution crashes. Actual results: Started from command line, step 5: evolution: ../sysdeps/posix/getaddrinfo.c:1662: rfc3484_sort: Assertion `src->results[i].native == -1 || src->results[i].native == a2_native' failed. Expected results: Evolution doesn't crash. Additional info: Sending Email and Saving Drafts work OK if VPN is disconnected at the of Evolution launch. It also works if you connect VPN while Evolution is running. Email account was gmail IMAP (all default options)
I can confirm this with OpenVPN (configured and set up via the gnome3 NetworkManager applet), and with an IMAP+ account so it is not pptp or IMAP specific. I get the exact same results as Juha. evolution-3.2.2-1.fc16.x86_64 Ingvar
Created attachment 535612 [details] gdb output of 'bt' and 'thread apply all bt full'
Thanks for a bug report. I think I saw this recently, maybe already reported. Could you run evolution under valgrind and reproduce the issue, please? You can do that with command like this: $ G_SLICE=always-malloc valgrind --num-callers=50 evolution &>log.txt and then the log.txt should contain the information about memory being used.
Created attachment 536066 [details] output of G_SLICE=always-malloc valgrind --num-callers=50 evolution
I ran some upgrades yesterday and installed yasm and I can't reproduce this issue any more. I will update this report if this happens again to me.
Thanks for the update. The valgrind doesn't show any issues in the code related to the place of the error message from the comment #1, which is good. Ingvar, could you try to update too, please? Maybe they fixed it recently. The file which crashes is part of glibc package, and I noticed some claims about crashes due to certain version of it (I do not recall precisely, unfortunately), but if the update contains also glibc package, then that may make sense.
I added a similar looking report to "See also" -field.
Milan, I updated to all latest updates (not updates-testing), including updated version of glibc today. While on VPN, evolution still crashes on that same error message: evolution: ../sysdeps/posix/getaddrinfo.c:1662: rfc3484_sort: Assertion `src->results[i].native == -1 || src->results[i].native == a2_native' failed. Aborted (SIGABRT) (core dumped) Ingvar
I'm running Name : glibc Arch : x86_64 Version : 2.14.90 Release : 19 and I have no problems with evolution (I have two IMAP+ mailboxes) now. With or without VPN connection (pptp).
Well, this is 100% reproducable on my system. glibc-2.14.90-19.x86_64 (why is %dist missing from the release tag?) and evolution-3.2.2-1.fc16.x86_64. evolution still crashes when I'm on OpenVPN.
Okay, did some more testing. As stated in #739743 this is related to IPv6 and/or routing, probably in within glibc. In f16, when on ethernet, NetworkManager (at least on my system) takes up an address also on the wlan if possible, and keeps it ready so that hand-over is spontaneous if the ethernet plug is pulled. (Is this a change from f15? It was certainly not like this in f14.) After starting my OpenVPN tunnel, ip configuration looks like this. $ ip a l 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 9c:8e:99:3c:40:6f brd ff:ff:ff:ff:ff:ff inet 192.168.5.9/24 brd 192.168.5.255 scope global eth0 inet6 fe80::9e8e:99ff:fe3c:406f/64 scope link valid_lft forever preferred_lft forever 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 link/ether 00:24:d7:ab:87:90 brd ff:ff:ff:ff:ff:ff inet 192.168.5.3/24 brd 192.168.5.255 scope global wlan0 inet6 fe80::224:d7ff:feab:8790/64 scope link valid_lft forever preferred_lft forever 8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100 link/none inet 10.8.0.38 peer 10.8.0.37/32 brd 10.8.0.38 scope global tun0 Then, deleting the default local inet6 address on wlan0 $ sudo -i # ip a d fe80::224:d7ff:feab:8790/64 dev wlan0 Now evolution does NOT crash while on OpenVPN. Note that I did NOT do anything to the ethernet interface. It still has its inet6 local address. This is an ugly workaround, but may help coders debug further. Ingvar
I asked a co-worker to help me with this, and he pointed me to this bug [1]. I guess you found a new reproducer for it, with IPv6 addresses. If you can modify the attached test case from there, and reproduce it with it, then it'll prove my hypotheses. [1] http://www.sourceware.org/bugzilla/show_bug.cgi?id=9954
Milan, I could not reproduce the error with that test case on my box, no. Ingvar
Krzysztof Kotlenga's trick in #739743 is also a workaround here: > Removing "myhostname" from /etc/nsswitch.conf is a workaround that works for > me.
I've tracked this a bit further. The failing part is in nss-myhostname. Reverting to a recompile of the fedora 15 package makes thing work again. The main change is in upstream git commit 8041b5bada31db152de80e45b3047ed32cef6880. That commit is a jump from 2009 to 2011, which indicates new functionality. The largest difference seems to be that nss-myhostname resolves actual IPv6 addresses (if bound to an interface), instead of just ::1. I do not know enough C to dig into this :-/ So, should this bz be relocated to nss-myhostname, perhaps? Lennart, could you give us a hand, please? Ingvar
Just one more thing, and I'll leave this for tonight: As Lennart stated in bz #739743, adding a bogus IPv6 address to the tun0 interface I got from OpenVPN also resolves the issue (at least for IPv4). Could it be that the sorting algorithms in nss-myhostname have no match for a mix of interfaces with and without IPv6? Ingvar
Thank you for the detailed investigation. I have no knowledge of nss-hostname, thus I cannot help here, I'm sorry, but I'm moving this to there, thus the maintainer can do anything appropriate with it.
This seems to happen because Linux sets up a link-local ipv6 address on the uplink (tunnel) device. Example: $ ip a l dev wlan0 | grep inet6 inet6 fe80::224:d7ff:feab:8790/64 scope link Note the fe80 marking this as link-local, that is, not an uplink address*. So I guess patching nss-myhostname to recognice these would help. Ingvar *) http://tools.ietf.org/html/rfc4291#section-2.4 http://tools.ietf.org/html/rfc4862#section-5.3
This seems to also make iftop crash. iftop-1.0-0.2.pre2.fc17.x86_64 nss-myhostname-0.3-2.fc17.x86_64 # iftop -i wlan0 crash after 5-15 seconds with: netlink.h:43: PROTO_ADDRESS_SIZE: Assertion `proto == 2 || proto == 10' failed. Aborted (core dumped) gdb shows it's crashing in nss-myhostname # grep ^hosts /etc/nsswitch.conf hosts: files mdns_minimal [NOTFOUND=return] dns mdns myhostname I have both IPv4 and IPv6 (global and linklocal) on wlan0.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.