Opened 11 years ago

Closed 5 years ago

#5927 closed defect (fixed)

Pidgin crashes when connection dies

Reported by: Manarius Owned by: MarkDoliner
Milestone: Component: AIM
Version: 2.4.2 Keywords:
Cc: ice799, fqueze, Root

Description

Whenever the network connection disconnects, Pidgin just crashes. Can be duplicated simply by disconnecting the internet source (wireless, ethernet, etc).

Attachments (5)

pidgin.RPT (7.3 KB) - added by Manarius 11 years ago.
pidgin-dave1g.RPT (2.1 KB) - added by dave1g 11 years ago.
06-14-2008_17.51.26.45.log (123.6 KB) - added by dave1g 11 years ago.
log file last 20 minutes or so…
8-4-2008_debug.log (5.4 KB) - added by bokamba 11 years ago.
Here's my log. Pidgin 2.4.3 on WinXP Pro. No third-party plugins.
pidgin.2.RPT (2.0 KB) - added by Pixelpaws 10 years ago.
Crash on WinXP, v 2.5.3.

Download all attachments as: .zip

Change History (48)

Changed 11 years ago by Manarius

comment:1 Changed 11 years ago by datallah

  • Component changed from unclassified to AIM
  • Owner changed from lschiere to MarkDoliner

There have a few reports of this (i'll try to find the duplicates at some point), Mark - any ideas what might be happening?

comment:2 Changed 11 years ago by QuLogic

It looks like at some point during a disconnect, flap_connection_schedule_destroy is called, which adds a timeout to call flap_connection_destroy_cb. However, when flap_connection_schedule_destroy returns, the PurpleConnection structure is freed, and so no longer exists for flap_connection_destroy_cb when it's called later by the GLib main loop.

This probably came about because Pidgin disconnects on network loss now, instead of calling the keepalive (which presumably calls things slightly differently).

comment:3 follow-up: Changed 11 years ago by MarkDoliner

  • Resolution set to fixed
  • Status changed from new to closed

QuLogic: If The PurpleConnection? is being destroyed then oscar calls flap_connection_destroy() directly instead of flap_connection_schedule_destroy(), so I don't think that's the problem.

Manarius: It looks like it's crashing in a plugin... it's a part of the plugin pack, something called "album"? I'd try upgrading Pidgin to 2.4.2 (the current version), and try upgrading the plugin pack (if there's a newer version available).

comment:4 Changed 11 years ago by MarkDoliner

Manarius: Oh, and if it's still crashing after than then please file a bug with the plugin pack people. Thanks!

comment:5 Changed 11 years ago by rekkanoryo

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:6 Changed 11 years ago by rekkanoryo

  • Resolution set to invalid
  • Status changed from reopened to closed

This is not a Pidgin or libpurple bug. This is an Album bug. Upgrade to Purple Plugin Pack 2.3.0. This crash has been fixed for seven months now.

comment:7 Changed 11 years ago by datallah

  • Resolution invalid deleted
  • Status changed from closed to reopened

The album crash is from October 3, 2007.

The other crash (at the bottom of pidgin.RPT) is from pidgin 2.4.2 and doesn't involve the album plugin.

comment:8 in reply to: ↑ 3 Changed 11 years ago by QuLogic

Replying to MarkDoliner:

QuLogic: If The PurpleConnection is being destroyed then oscar calls flap_connection_destroy() directly instead of flap_connection_schedule_destroy(), so I don't think that's the problem.

If you look at the second backtrace, you can see that flap_connection_destroy_cb is called by the GLib main loop. Maybe, as you say, it's not being called by the PurpleConnection as it is destroyed, but perhaps by some other connection destroyed at around the same time.

comment:9 Changed 11 years ago by MarkDoliner

Oh, I didn't notice that there was more than one backtrace in that file, thanks.

comment:10 Changed 11 years ago by wordmagekat

this is definitely a 2.4.2 issue, not plugin related, and it's driving me crazy! I can provide another debug report if needed.

Changed 11 years ago by dave1g

Changed 11 years ago by dave1g

log file last 20 minutes or so...

comment:11 Changed 11 years ago by dave1g

My wireless cuts out all the time, but I hadnt seen this problem until now.

Changed 11 years ago by bokamba

Here's my log. Pidgin 2.4.3 on WinXP Pro. No third-party plugins.

comment:12 Changed 11 years ago by bokamba

This bug doesn't seem "minor" to me; if I lose my network connection for more than about 5 seconds, Pidgin crashes.

comment:13 Changed 11 years ago by deryni

The priority doesn't mean what you think it does, ignore it.

comment:14 in reply to: ↑ description Changed 11 years ago by chemistrydioxide

I had this problem as well, but only on Windows. On Linux, i'm also loosing my network connection quite often, but Pidgin doesn't crash.

I suppose that this is a Windows-only problem.

comment:15 Changed 11 years ago by Sim-on

#6314 has been marked as a duplicate of this bug

comment:16 Changed 11 years ago by datallah

Ticket #7285 has been marked as a duplicate of this ticket.

comment:17 Changed 10 years ago by Pixelpaws

Confirming that this bug still exists intermittently as of 2.5.3. I'm running Windows XP and only using plugins that were included by default. I'll attach a new crash report as well.

Changed 10 years ago by Pixelpaws

Crash on WinXP, v 2.5.3.

comment:18 Changed 10 years ago by ice799

fyi i'm seeing this issue too, but on linux x86_64(with the libpurple that comes with pidgin 2.5.5):

Program terminated with signal 11, Segmentation fault.
#0  flap_connection_destroy_cb (data=<value optimized out>) at flap_connection.c:439
439		if (!account->disconnecting && ((od->oscar_connections == NULL)
(gdb) bt
#0  flap_connection_destroy_cb (data=<value optimized out>) at flap_connection.c:439
#1  0x00007ff3f09a490b in g_timeout_dispatch () from /custom/lib/libglib-2.0.so.0
#2  0x00007ff3f09a41e2 in g_main_context_dispatch () from /custom/lib/libglib-2.0.so.0
#3  0x00007ff3f09a74c5 in g_main_context_iterate () from /custom/lib/libglib-2.0.so.0
#4  0x00007ff3f09a77bd in g_main_loop_run () from /custom/lib/libglib-2.0.so.0
Current language:  auto; currently c
(gdb) p *account
Cannot access memory at address 0x343630312d4f5349

comment:19 Changed 9 years ago by evands

I've just marked #a13606 a duplicate of this ticket.

comment:20 Changed 9 years ago by kevinday

Just chiming in that it's still occurring in Adium on the latest beta:

Process:         Adium [5113]
Path:            /Applications/Adium.app/Contents/MacOS/Adium
Identifier:      com.adiumX.adiumX
Version:         1.4b18 (1.4b18)
Code Type:       X86 (Native)
Parent Process:  launchd [192]

Date/Time:       2010-09-17 18:16:31.051 -0500
OS Version:      Mac OS X 10.6.4 (10F569)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000020
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libpurple                           0x0087c2d0 flap_connection_destroy_cb + 217
1   com.adiumX.AdiumPurple              0x003a7e47 callTimerFunc + 120
2   com.apple.CoreFoundation            0x93aae70b __CFRunLoopRun + 8059
3   com.apple.CoreFoundation            0x93aac094 CFRunLoopRunSpecific + 452
4   com.apple.CoreFoundation            0x93aabec1 CFRunLoopRunInMode + 97
5   com.apple.HIToolbox                 0x95888f9c RunCurrentEventLoopInMode + 392
6   com.apple.HIToolbox                 0x95888d51 ReceiveNextEventCommon + 354
7   com.apple.HIToolbox                 0x95888bd6 BlockUntilNextEventMatchingListInMode + 81
8   com.apple.AppKit                    0x948eda89 _DPSNextEvent + 847
9   com.apple.AppKit                    0x948ed2ca -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
10  com.apple.AppKit                    0x948af55b -[NSApplication run] + 821
11  com.apple.AppKit                    0x948a75ed NSApplicationMain + 574
12  com.adiumX.adiumX                   0x00002f42 start + 54

It seems to be happening when there are multiple disconnect/reconnect events in a short period. A normal disconnect/reconnect doesn't ever seem to cause it, but if my connection is rapidly flapping it happens often.

comment:22 Changed 9 years ago by fqueze

This crash is frequent in Instantbird too.

From what I've been told by users, this crash happens mostly when a laptop wakes up from sleep and is connected to a different network. It seems flap_connection_destroy_cb is called from a timeout after the connection has already been destroyed.

This happens in Instantbird 0.2 (libpurple 2.6.6) and current nightly builds (libpurple 2.7.3).

comment:23 Changed 9 years ago by Robby

We get frequent reports of this for Adium.

comment:24 Changed 9 years ago by darkrain42

In attempting to triage this, I'd like to note that Adium 1.4 betas/RCs do not contain 904144db35079f8cc320a0380de5c1a1df95a436 (which fixes one version of this crash, when using SSL).

As fqueze has pointed out, it does happen in Instantbird with that patch.

comment:25 Changed 9 years ago by darkrain42@…

(In bc9c4bb89eb6d36c548b61d8b1e6b8952b9c4c0e):
oscar: Add useful object debugging for #5927.

Won't actually fix anything. Refs #5927

comment:26 Changed 9 years ago by darkrain42

People who are still seeing this, I'd love to see debug logs from the crash with the patch from that commit (bc9c4bb) applied. It should be in the next release (2.7.5).

comment:27 Changed 9 years ago by MarkDoliner

I think this happens when we get a read error on a FlapConnection? of type SNAC_FAMILY_CHAT. flap_connection_destroy_cb() calls purple_connerr() which calls oscar_chat_kill() which calls flap_connection_schedule_destroy(). We're essentially adding a timer to call the destroy function from within the destroy function.

comment:28 Changed 9 years ago by MarkDoliner

  • Milestone set to 2.7.7
  • Resolution set to fixed
  • Status changed from new to closed

Just checked in a fix for this. It'll be in the next release of Pidgin (2.7.7 or 2.8.0). If anyone encounters this crash after then, please leave a comment here and let me know!

comment:29 Changed 9 years ago by MarkDoliner

Oh, also if you experienced this crash in a session where you never used an AIM chat room then please leave a comment and let me know.

comment:30 Changed 9 years ago by markdoliner@…

(In 3ac008cdb1707c831737d497562a2751cdff861c):
Move the call to flap_connection_schedule_destroy from oscar_chat_kill to oscar_chat_leave. This avoids having flap_connection_schedule_destroy called from purple_connerr, which itself is called by flap_connection_destroy_cb I'm hoping this change fixes #5927, the oscar crash when a flap connection is disconnected.

comment:31 Changed 9 years ago by markdoliner@…

(In 6e8da78b6e5ccdafa85c8afebff37e426d9a58d3):
Move the call to flap_connection_schedule_destroy from oscar_chat_kill to oscar_chat_leave. This avoids having flap_connection_schedule_destroy called from purple_connerr, which itself is called by flap_connection_destroy_cb I'm hoping this change fixes #5927, the oscar crash when a flap connection is disconnected.

comment:32 Changed 9 years ago by rekkanoryo@…

(In 587b2bb9fe22fc4c15ba1c1ef8175be06025ea9d):
Apply Mark's specific changes listed below to the 2.7.7 branch.

* Plucked 05ca7c0f8c782c05e9866a9ac6ccc03acc7d2c7f (markdoliner@…): Close open requests related to this xfer when the request is canceled locally. For oscar this includes disconnecting when you have an incoming transfer request. Without this change Pidgin will crash if the user tries to interact with the dialog. This change fixes #11666.

Now instead of crashing we'll leak. See the lengthy comment in the code if anyone wants to fix this.

* Plucked 089c261f1de00667abd623ce3c5b471e91b09016 (markdoliner@…): I noticed a NULL printf crash from the first chunk of this change. In the second chunk I changed the code to match the error message from the first chunk. I prefer this message.

* Plucked 6e8da78b6e5ccdafa85c8afebff37e426d9a58d3 (markdoliner@…): Move the call to flap_connection_schedule_destroy from oscar_chat_kill to oscar_chat_leave. This avoids having flap_connection_schedule_destroy called from purple_connerr, which itself is called by flap_connection_destroy_cb I'm hoping this change fixes #5927, the oscar crash when a flap connection is disconnected.

comment:33 Changed 8 years ago by vulpes

This problem is not fixed.

I am seeing this same problem on pidgin 2.7.7 (portable/installed) on Windows XP professional. I am not using AIM, either. I use pidgin to connect to MSNIM Google Talk, and NateOn (the last thorugh a plug-in)

comment:34 Changed 8 years ago by QuLogic

If you aren't using AIM, how could you ever think this is the same issue? File a new ticket.

comment:35 Changed 7 years ago by BigBrownChunx

This just happened on Pidgin 2.10.3

Error occured on Monday, April 23, 2012 at 23:48:44.

Windows Version 6.1 Build 7601 Service Pack 1

C:\Program Files\Pidgin\pidgin.exe caused an Access Violation at location 68894d4c in module C:\Program Files\Pidgin\liboscar.dll Reading from location 206568bc.

Registers:
eax=00000000 ebx=20656854 ecx=00000000 edx=119d6f88 esi=0ea2d980 edi=0000ffff
eip=68894d4c esp=0022e8d8 ebp=0022e900 iopl=0         nv up ei pl zr na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00210246

Call stack:
         Using Debug Symbols from: C:\Program Files\Pidgin\pidgin-2.10.3-dbgsym\liboscar.dll.dbgsym
68894D4C C:\Program Files\Pidgin\liboscar.dll  flap_connection_destroy_cb  C:/cygwin/home/Eion/pidgin-2.10.3/libpurple/protocols/oscar/flap_connection.c:444
         C:\Program Files\Pidgin\Gtk\bin\libglib-2.0-0.dll [2.20.5.0]
685EA92E C:\Program Files\Pidgin\Gtk\bin\libglib-2.0-0.dll  g_source_get_current_time
685EA27B C:\Program Files\Pidgin\Gtk\bin\libglib-2.0-0.dll  g_main_context_dispatch
685ED185 C:\Program Files\Pidgin\Gtk\bin\libglib-2.0-0.dll  g_main_context_prepare
685ED574 C:\Program Files\Pidgin\Gtk\bin\libglib-2.0-0.dll  g_main_loop_run
         C:\Program Files\Pidgin\Gtk\bin\libgtk-win32-2.0-0.dll [2.16.6.0]
01844260 C:\Program Files\Pidgin\Gtk\bin\libgtk-win32-2.0-0.dll  gtk_main
         C:\Program Files\Pidgin\pidgin.dll [2.10.3.0]
         Using Debug Symbols from: C:\Program Files\Pidgin\pidgin-2.10.3-dbgsym\pidgin.dll.dbgsym
64A97F48 C:\Program Files\Pidgin\pidgin.dll  pidgin_main  C:/cygwin/home/Eion/pidgin-2.10.3/pidgin/gtkmain.c:944
         C:\Program Files\Pidgin\pidgin.exe [2.10.3.0]
         Using Debug Symbols from: C:\Program Files\Pidgin\pidgin-2.10.3-dbgsym\pidgin.exe.dbgsym
0040250B C:\Program Files\Pidgin\pidgin.exe  WinMain  C:/cygwin/home/Eion/pidgin-2.10.3/pidgin/win32/winpidgin.c:821
00402E58 C:\Program Files\Pidgin\pidgin.exe  WinMain  C:/cygwin/home/Eion/pidgin-2.10.3/pidgin/win32/winpidgin.c:726
0040124B C:\Program Files\Pidgin\pidgin.exe
004012B8 C:\Program Files\Pidgin\pidgin.exe
         C:\windows\system32\kernel32.dll [6.1.7601.17651]
76C4ED6C C:\windows\system32\kernel32.dll  BaseThreadInitThunk
         C:\windows\SYSTEM32\ntdll.dll [6.1.7601.17725]
7789377B C:\windows\SYSTEM32\ntdll.dll  RtlInitializeExceptionChain
7789374E C:\windows\SYSTEM32\ntdll.dll  RtlInitializeExceptionChain

comment:36 Changed 7 years ago by Robby

  • Milestone 2.7.7 deleted
  • Resolution fixed deleted
  • Status changed from closed to new

comment:37 Changed 7 years ago by MarkDoliner

Ah-ha! And you have line numbers! It looks like maybe conn->od points to bad memory in flap_connection_destroy_cb()?

BigBrownChunx?: You don't happen to have the debug log output by any chance, do you? :-/ Or do you know what happened when it crashed? Maybe you just signed off? Or maybe your account got disconnected?

comment:38 Changed 7 years ago by EionRobb

I don't have a debug log, no. It happened to me when my laptop woke up out of sleep and connected to a different network.

comment:39 Changed 6 years ago by MikZ

I am experiencing this issue consistently, as currently described under 'Description'. Pidgin/LibPurple? 2.10.6 under Linux (Mint 14).

It is particularly frustrating because I mostly connect by mobile broadband these days, which can have brief (less than 1 second) outages as I travel.

If you can guide me how to turn on helpful debugging information, I'll gladly do so and provide it. All the web-searching I've done has led me to debugging information for writing plug-ins, which I don't think is relevant in this case.

comment:40 Changed 6 years ago by MarkDoliner

Backtraces/call stack and debug log are helpful. More info at TipsForBugReports

comment:41 Changed 5 years ago by MikZ

@MarkDoliner: Thanks for the link. It helped me find that the problem only occurs when I have my Skype account turned on in Pidgen. I'll look for or open a more appropriate bug record.

comment:42 Changed 5 years ago by MarkDoliner

MikZ: Cool. And what are you using to connect to Skype? I believe it must be a 3rd party plugin, right? If so, you'll need to report the problem to the author (who is quite possibly EionRobb? and BigBrownChunx? from the discussion on this bug).

comment:43 Changed 5 years ago by MarkDoliner

  • Resolution set to fixed
  • Status changed from new to closed

I'm going to close this again. Comment 35 indicates that this still happened for AIM accounts in 2.10.3, and I know the code hasn't changed much since then but I feel like it's not worth investigating this unless we're sure it still happens in 2.10.7.

Feel free to reopen with a current backtrace if anyone experiences crashes in flap_connection.c when the networks disconnects or reconnects.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!