Re: pidgin and VPN issues.
Expect gdb backtraces the next time this happens :) Got them. And things look a bit diffrent: #0 0x003b56c0e627 in __libc_send (fd=17, buf=0x1e2f2a0, n=427, flags=-1) at ../sysdeps/unix/sysv/linux/x86_64/send.c:32 #1 0x0037b5225b8b in pt_Send () from /lib64/libnspr4.so #2 0x0037b5e1cd5c in ssl_DefSend () from /lib64/libssl3.so #3 0x0037b5e20e2e in ssl_SendSavedWriteData () from /lib64/libssl3.so #4 0x0037b5e22240 in ssl_SecureSend () from /lib64/libssl3.so #5 0x0037b5e26197 in ssl_Write () from /lib64/libssl3.so #6 0x7f0d6df57b57 in ssl_nss_write (gsc=optimized out, data=optimized out, len=optimized out) at ssl-nss.c:496 #7 0x7f0d7132b294 in transport_write () from /usr/lib64/purple-2/libsipe.so #8 0x7f0d7132bade in sipe_backend_transport_flush () from /usr/lib64/purple-2/libsipe.so #9 0x7f0d71306230 in sipe_core_deallocate () from /usr/lib64/purple-2/libsipe.so #10 0x7f0d712f3dc2 in sipe_purple_close () from /usr/lib64/purple-2/libsipe.so #11 0x003b6045fee6 in _purple_connection_destroy (gc=0x1fad8c0) at connection.c:275 #12 0x003b60446606 in purple_account_disconnect (account=account@entry=0x192ce90) at account.c:1284 #13 0x003b6045ebd5 in purple_connection_disconnect_cb (data=0x192ce90, data@entry=error reading variable: value has been optimized out) at connection.c:523 #14 0x003b58c485db in g_timeout_dispatch (source=source@entry=0x1b3d700, callback=optimized out, user_data=optimized out) at gmain.c:4026 #15 0x003b58c47a55 in g_main_dispatch (context=0x1494830) at gmain.c:2715 #16 g_main_context_dispatch (context=context@entry=0x1494830) at gmain.c:3219 #17 0x003b58c47d88 in g_main_context_iterate (context=0x1494830, block=block@entry=1, dispatch=dispatch@entry=1, self=optimized out) at gmain.c:3290 ---Type return to continue, or q return to quit--- #18 0x003b58c48182 in g_main_loop_run (loop=0x1c3c7e0) at gmain.c:3484 #19 0x003b6ed4b077 in IA__gtk_main () at gtkmain.c:1257 #20 0x00431491 in main (argc=1, argv=0x7fff65b7df38) at gtkmain.c:934 I did a few contiune's and ctrl+c's but always the same bt. Step 0 lists fd 17: [ra@hamburger ~]$ ll /proc/2863/fd/17 lrwx--. 1 ra ra 64 May 14 00:04 /proc/2863/fd/17 - socket:[155804] This time a socket which makes more sense. the last time I checked what the fd was pidgin had already recovered so perhaps some fd's had been closed and reopened throwing off the numbers? [ra@hamburger ~]$ kill 2863 [ra@hamburger ~]$ kill 2863 [ra@hamburger ~]$ kill 2863 [ra@hamburger ~]$ kill 2863 [ra@hamburger ~]$ kill 2863 [ra@hamburger ~]$ kill 2863 [ra@hamburger ~]$ kill 2863 [ra@hamburger ~]$ kill 2863 [ra@hamburger ~]$ kill 2863 [ra@hamburger ~]$ kill 2863 [ra@hamburger ~]$ kill -9 2863 [ra@hamburger ~]$ kill -9 2863 bash: kill: (2863) - No such process ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: pidgin and VPN issues.
Richard Allen spake unto us the following wisdom: Expect gdb backtraces the next time this happens :) Got them. And things look a bit diffrent: #8 0x7f0d7132bade in sipe_backend_transport_flush () from /usr/lib64/purple-2/libsipe.so #9 0x7f0d71306230 in sipe_core_deallocate () from /usr/lib64/purple-2/libsipe.so #10 0x7f0d712f3dc2 in sipe_purple_close () from /usr/lib64/purple-2/libsipe.so Unfortunately, Pidgin-SIPE is an unsupported third party plugin. Without looking too closely, I'm guessing there's an error on the socket and it's not handling that gracefully. I did a few contiune's and ctrl+c's but always the same bt. Step 0 lists fd 17: [ra@hamburger ~]$ ll /proc/2863/fd/17 lrwx--. 1 ra ra 64 May 14 00:04 /proc/2863/fd/17 - socket:[155804] This time a socket which makes more sense. the last time I checked what the fd was pidgin had already recovered so perhaps some fd's had been closed and reopened throwing off the numbers? Yes, it makes much more sense. I suspect your analysis is correct. Ethan ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: pidgin and VPN issues.
On Sat, May 11, 2013 at 10:54 AM, Richard Allen r...@ra.is wrote: [ra@hamburger ~]$ ll /proc/2694/fd/19 l-wx--. 1 ra ra 64 May 11 01:14 /proc/2694/fd/19 - /home/ra/.purple/logs/sipe/r...@ok.is%2cok%5cra/.system/2013-05-11.125047+GMT.txt This is interesting. Is /home/ra/.purple/logs on a local disk, or network mounted? What filesystem? You really shouldn't see a jillion EAGAINs on filesystem write, and I'm quite surprised to see those sendtos. If this is a network filesystem, I suspect the server (or the network) was out to lunch. No, all on a local disk. The only thing special here is that the filesystem is encrypted: [ra@hamburger ~]$ cd /home/ra/.purple/logs/sipe/r...@ok.is%2cok%5cra/.system [ra@hamburger .system]$ df -h . Filesystem Size Used Avail Use% Mounted on /dev/mapper/luks-d6fe5bfc-b54c-4b4e-918a-148b574c5504 360G 117G 225G 35% /home [ra@hamburger .system]$ mount | grep home /dev/mapper/luks-d6fe5bfc-b54c-4b4e-918a-148b574c5504 on /home type ext4 (rw,relatime,seclabel,data=ordered) [ra@hamburger .system]$ ls -l 2013-05-11.125047+GMT.txt -rw-rw-r--. 1 ra ra 6174 May 11 15:49 2013-05-11.125047+GMT.txt Does /var/log/messages or /var/log/dmesg say anything interesting from around the time that this happened? Any disk errors or timeouts? No, nothing.And disk and/or filesystem errors would have thrown up red flags for me and would have put my pidgin issue way down on the things to worry about list :) Expect gdb backtraces the next time this happens :) ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support Ive not had any problems with pidgin since last week when I lost connection and since then Ive seen only two status messages: incorrect username and password or 503: Service Unavailable. I went to college with a guy whose wife works for fb. I emailed her on Sunday and she responded today that this is a issue causing problems for a lot of users. She did not go into detail so its probably something they are working on. She did tell me that it probably wont be fixed for a while. I really dont like the sound of that. Anyway.. hope that helps others relax a bit. We all just wait :( Wade -- Registered Linux User: #480675 Registered Linux Machine: #408606 Linux since June 2005 ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: pidgin and VPN issues.
Hello all, For some reason this has been happening much less frequently the last couple of weeks. But I did see this just a few minutes ago. The UI gets complete frozen, but it does continue to update itself when I pull a chat window to the forground from behind another window. It prints out no new messages or does not accept input. I cant even select contacts in the buddy list. I dont know how long pidgin had been frozen but I did start trying to debug. I first attached a strace to the process: [ra@hamburger ~]$ ps -ef | grep pidgin ra2694 2267 0 01:14 ?00:05:53 pidgin [ra@hamburger ~]$ strace -p 2694 Process 2694 attached sendto(19, \241h\366\223\272\251\21\23\255\26l9\370p\255\300\214\376\322y\221k\341\3507\16\202\200}~%\301... , 679, 0, NULL, 0) = -1 EAGAIN (Resource temporarily unavailable) sendto(19, \241h\366\223\272\251\21\23\255\26l9\370p\255\300\214\376\322y\221k\341\3507\16\202\200}~%\301... , 679, 0, NULL, 0) = -1 EAGAIN (Resource temporarily unavailable) sendto(19, \241h\366\223\272\251\21\23\255\26l9\370p\255\300\214\376\322y\221k\341\3507\16\202\200}~%\301... , 679, 0, NULL, 0) = -1 EAGAIN (Resource temporarily unavailable) sendto(19, \241h\366\223\272\251\21\23\255\26l9\370p\255\300\214\376\322y\221k\341\3507\16\202\200}~%\301... , 679, 0, NULL, 0) = -1 EAGAIN (Resource temporarily unavailable) sendto(19, \241h\366\223\272\251\21\23\255\26l9\370p\255\300\214\376\322y\221k\341\3507\16\202\200}~%\301... , 679, 0, NULL, 0) = -1 EAGAIN (Resource temporarily unavailable) sendto(19, \241h\366\223\272\251\21\23\255\26l9\370p\255\300\214\376\322y\221k\341\3507\16\202\200}~%\301... , 679, 0, NULL, 0) = -1 EAGAIN (Resource temporarily unavailable) sendto(19, \241h\366\223\272\251\21\23\255\26l9\370p\255\300\214\376\322y\221k\341\3507\16\202\200}~%\301... , 679, 0, NULL, 0) = -1 EAGAIN (Resource temporarily unavailable) sendto(19, \241h\366\223\272\251\21\23\255\26l9\370p\255\300\214\376\322y\221k\341\3507\16\202\200}~%\301... , 679, 0, NULL, 0) = -1 EAGAIN (Resource temporarily unavailable) Huge, endless list of that.. [ra@hamburger ~]$ ll /proc/2694/fd/19 l-wx--. 1 ra ra 64 May 11 01:14 /proc/2694/fd/19 - /home/ra/.purple/logs/sipe/r...@ok.is%2cok%5cra/.system/2013-05-11.125047+GMT.txt I then tried to attach gdb to the process but gdb told me I needed the debuginfo packages (I'm a Fedora user) so I disconnected gdb and installed the needed packages. This is where a miracle happened.pidgin recovered from the infinite loop and proceeded working as normal. I am however ready to hook up gdb the next time this happens. -- Rikki - Original Message - From: Ethan Blanton e...@pidgin.im To: Matthias Apitz g...@unixarea.de Cc: support@pidgin.im Sent: Thursday, 18 April, 2013 2:29:13 PM Subject: Re: pidgin and VPN issues. Matthias Apitz spake unto us the following wisdom: IMHO this sounds like established TCP connections are terminated by the VPN down/change and some layer in pidgin is waiting (for ever) for a response. One could watch with TCPDUMP if this is true. All of our network I/O should be nonblocking, and thus should not affect the UI. This is more likely a logic bug of some kind, as Mark noted. Ethan ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: pidgin and VPN issues.
Richard Allen spake unto us the following wisdom: For some reason this has been happening much less frequently the last couple of weeks. But I did see this just a few minutes ago. The UI gets complete frozen, but it does continue to update itself when I pull a chat window to the forground from behind another window. It prints out no new messages or does not accept input. I cant even select contacts in the buddy list. I dont know how long pidgin had been frozen but I did start trying to debug. I first attached a strace to the process: This is good sleuthing! [ra@hamburger ~]$ ps -ef | grep pidgin ra2694 2267 0 01:14 ?00:05:53 pidgin [ra@hamburger ~]$ strace -p 2694 Process 2694 attached sendto(19, \241h\366\223\272\251\21\23\255\26l9\370p\255\300\214\376\322y\221k\341\3507\16\202\200}~%\301... , 679, 0, NULL, 0) = -1 EAGAIN (Resource temporarily unavailable) Huge, endless list of that.. Your intuition that we need to look at fd 19 is great. [ra@hamburger ~]$ ll /proc/2694/fd/19 l-wx--. 1 ra ra 64 May 11 01:14 /proc/2694/fd/19 - /home/ra/.purple/logs/sipe/r...@ok.is%2cok%5cra/.system/2013-05-11.125047+GMT.txt This is interesting. Is /home/ra/.purple/logs on a local disk, or network mounted? What filesystem? You really shouldn't see a jillion EAGAINs on filesystem write, and I'm quite surprised to see those sendtos. If this is a network filesystem, I suspect the server (or the network) was out to lunch. Does /var/log/messages or /var/log/dmesg say anything interesting from around the time that this happened? Any disk errors or timeouts? I then tried to attach gdb to the process but gdb told me I needed the debuginfo packages (I'm a Fedora user) so I disconnected gdb and installed the needed packages. This is where a miracle happened. pidgin recovered from the infinite loop and proceeded working as normal. I am however ready to hook up gdb the next time this happens. That certainly won't hurt. Ethan signature.asc Description: Digital signature ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: pidgin and VPN issues.
[ra@hamburger ~]$ ll /proc/2694/fd/19 l-wx--. 1 ra ra 64 May 11 01:14 /proc/2694/fd/19 - /home/ra/.purple/logs/sipe/r...@ok.is%2cok%5cra/.system/2013-05-11.125047+GMT.txt This is interesting. Is /home/ra/.purple/logs on a local disk, or network mounted? What filesystem? You really shouldn't see a jillion EAGAINs on filesystem write, and I'm quite surprised to see those sendtos. If this is a network filesystem, I suspect the server (or the network) was out to lunch. No, all on a local disk. The only thing special here is that the filesystem is encrypted: [ra@hamburger ~]$ cd /home/ra/.purple/logs/sipe/r...@ok.is%2cok%5cra/.system [ra@hamburger .system]$ df -h . Filesystem Size Used Avail Use% Mounted on /dev/mapper/luks-d6fe5bfc-b54c-4b4e-918a-148b574c5504 360G 117G 225G 35% /home [ra@hamburger .system]$ mount | grep home /dev/mapper/luks-d6fe5bfc-b54c-4b4e-918a-148b574c5504 on /home type ext4 (rw,relatime,seclabel,data=ordered) [ra@hamburger .system]$ ls -l 2013-05-11.125047+GMT.txt -rw-rw-r--. 1 ra ra 6174 May 11 15:49 2013-05-11.125047+GMT.txt Does /var/log/messages or /var/log/dmesg say anything interesting from around the time that this happened? Any disk errors or timeouts? No, nothing.And disk and/or filesystem errors would have thrown up red flags for me and would have put my pidgin issue way down on the things to worry about list :) Expect gdb backtraces the next time this happens :) ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: pidgin and VPN issues.
On Tue, Apr 16, 2013 at 6:32 AM, Richard Allen r...@ra.is wrote: I'm using pidgin on Fedora 18 (This was also an issue in 17).My work requires me to fire up multiple VPN profiles each day. Normally this is fine. However when disengaging the VPN pidgin tends to lock up. This happens both with Cisco compatible (vpnc) profiles and also Anyconnect profiles.I use network manager for all VPN needs. When pidgin is frozen, there is no indication in the GUI (i.e. I dont notice anything) and pidgin is unkillable. I have to use kill -9 to stop it. Is this a known issue or are there any workarounds? That sounds kinda crazy and obviously shouldn't happen. I'm mildly curious what Pidgin is doing when this happens. Does the UI become gtk gray and blanked out and is unresponsive? If you have a desire to do some debugging, it might be helpful to obtain a backtrace by using gdb /path/to/pidgin 123PID456 to use gdb to connect to the running Pidgin instance and then repeat these commands a few times: backtrace, continue, CTRL+c. If Pidgin is in an infinite loop that will print backtraces hopefully at different places in the loop. You could also step through line by line. Or kill -6 to dump a core file and then get a backtrace from that. There are some more details here: https://developer.pidgin.im/wiki/GetABacktrace And info on filing a bug report here: https://developer.pidgin.im/wiki/TipsForBugReports ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: pidgin and VPN issues.
El día Wednesday, April 17, 2013 a las 11:39:17PM -0700, Mark Doliner escribió: On Tue, Apr 16, 2013 at 6:32 AM, Richard Allen r...@ra.is wrote: I'm using pidgin on Fedora 18 (This was also an issue in 17).My work requires me to fire up multiple VPN profiles each day. Normally this is fine. However when disengaging the VPN pidgin tends to lock up. This happens both with Cisco compatible (vpnc) profiles and also Anyconnect profiles.I use network manager for all VPN needs. When pidgin is frozen, there is no indication in the GUI (i.e. I dont notice anything) and pidgin is unkillable. I have to use kill -9 to stop it. Is this a known issue or are there any workarounds? IMHO this sounds like established TCP connections are terminated by the VPN down/change and some layer in pidgin is waiting (for ever) for a response. One could watch with TCPDUMP if this is true. matthias -- Sent from my FreeBSD netbook Matthias Apitz | - No system with backdoors like Apple/Android E-mail: g...@unixarea.de | - Never being an iSlave WWW: http://www.unixarea.de/ | - No proprietary attachments, no HTML/RTF in E-mail phone: +49-170-4527211 | - Respect for open standards ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: pidgin and VPN issues.
Matthias Apitz spake unto us the following wisdom: IMHO this sounds like established TCP connections are terminated by the VPN down/change and some layer in pidgin is waiting (for ever) for a response. One could watch with TCPDUMP if this is true. All of our network I/O should be nonblocking, and thus should not affect the UI. This is more likely a logic bug of some kind, as Mark noted. Ethan ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: pidgin and VPN issues.
Hi, Do you actually need Pidgins traffic to do down the VPN? Because you can stop the VPN from becoming the default route for all traffic and only set it to be the route for your companies servers. If that is the case you can change the IPv4 Settings for the VPN and press the Routes... button. Tick the box Use this connection only for resources on its network then add the network address range of your company network 10.0.0.0 for example. Regards Phil Hannent On 16 April 2013 14:32, Richard Allen r...@ra.is wrote: Hello all, I'm using pidgin on Fedora 18 (This was also an issue in 17).My work requires me to fire up multiple VPN profiles each day. Normally this is fine. However when disengaging the VPN pidgin tends to lock up. This happens both with Cisco compatible (vpnc) profiles and also Anyconnect profiles.I use network manager for all VPN needs. When pidgin is frozen, there is no indication in the GUI (i.e. I dont notice anything) and pidgin is unkillable. I have to use kill -9 to stop it. Is this a known issue or are there any workarounds? Thanks in advance. -- Rikki ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
Re: pidgin and VPN issues.
Hi, None of my VPN profiles take over the default route. It's just a case of routing some RFC1918 (10.x, 172.16-31.x etc. etc.) via the VPN tunnel. Nothing else is affected. Pidgin sould never go thro the VPN tunnel atleast. -- Rikki - Original Message - From: Phil Hannent p...@hannent.co.uk To: Richard Allen r...@ra.is Cc: Pidgin Support List support@pidgin.im Sent: Tuesday, 16 April, 2013 1:37:30 PM Subject: Re: pidgin and VPN issues. Hi, Do you actually need Pidgins traffic to do down the VPN? Because you can stop the VPN from becoming the default route for all traffic and only set it to be the route for your companies servers. If that is the case you can change the IPv4 Settings for the VPN and press the Routes... button. Tick the box Use this connection only for resources on its network then add the network address range of your company network 10.0.0.0 for example. Regards Phil Hannent On 16 April 2013 14:32, Richard Allen r...@ra.is wrote: Hello all, I'm using pidgin on Fedora 18 (This was also an issue in 17). My work requires me to fire up multiple VPN profiles each day. Normally this is fine. However when disengaging the VPN pidgin tends to lock up. This happens both with Cisco compatible (vpnc) profiles and also Anyconnect profiles. I use network manager for all VPN needs. When pidgin is frozen, there is no indication in the GUI (i.e. I dont notice anything) and pidgin is unkillable. I have to use kill -9 to stop it. Is this a known issue or are there any workarounds? Thanks in advance. -- Rikki ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support ___ Support@pidgin.im mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
