Crashes in msn_cmdproc_process_cmd

Adium Log

Crash log

Crash Log 2

Crash Log 3

Crash Log 4

Debug log for Crash Log 4

The 'version' number in my bug report is wrong -- it is witnessed with 1.3b5, not 1.2.5 as indicated in the ticket.

Ah, that's helpful.

I'm not sure exactly what's the issue here, but I've seen similar behavior and I have a fix that seems to work.

There are multiple "ACK 7" commands. That's extremely bad. Should be fixed in the http parsing code, but for now this seems to do the trick:

http://github.com/felipec/msn-pecan/commit/0cc371f391114da76463f1b138d77fb334b134bb

I created a temporal branch, adium_test, that contains this, and another possible fix.

I will test it today and if everything is ok I'll integrate it into adium.

Thanks for your work so far. Just tried 1.3b6 and the behaviour is still evident in this build.

Best wishes Andy

Hm, I was wrong the ACK's are in different switchboards, so that's ok.

Is there a way to find out in which line the crash happened? "msn_cmdproc_process_cmd + 630"

If someone here is able to reproduce the problem, I suppose running it in GDB would do the trick... if you are one of those people, check out RunningAdiumInGDB

gdb run as requested of crash

Added gdb run of crash; of MSN being enabled of Adium. Again reproduced crash in under 1 minute.

That gdb is not useful since msn-pecan was compiled without debug symbols.

I've tried to analyze the debug log but since it's incomplete I can't do much. I need to see when connection 0x107cd348 was created so I see the corresponding switchboard and if it was closed or destroyed.

felipec

If you can give me directions on compiling msn-peacan with debug symbols I'll do this for you right away.

Just add -g to the CFLAGS, or even better: -ggdb.

felipec

I apologize, but with the directions above I'm not sure how to accomplish the compile of msn-peacan. Can you expand the directions somewhat. I'll assume a few things, that I need to download the adium source for the 1.3b6 tree and work from there.

msn-pecan was compiled with debug symbols. specifically, -gdwarf-2 -g3

Replying to joedunn:

felipec I apologize, but with the directions above I'm not sure how to accomplish the compile of msn-peacan. Can you expand the directions somewhat. I'll assume a few things, that I need to download the adium source for the 1.3b6 tree and work from there.

GettingNewestAdiumSource

If you have Xcode 2.5 or newer, OS X 10.4 or newer and Subversion, run these in Terminal:

svn co -r 24166 svn://svn.adiumx.com/adium/trunk adium
cd adium
ADIUM_CFLAGS="-ggdb" make

You should end up with an Adium.app build of the very revision of 1.3b6, and with appropriate debug symbols on. Then, just follow the previous instructions.

MSN-Peacan with debug added

Attached is Adium checked out from SVN and complied with ADIUM_CFLAGS="-ggdb" make

. Installed in /Applications/Adium.app and run in gdb. If anything else is needed please feel free to reach out.

The problem is that debug symbols for msn-pecan are either not present or being stripped somewhere along the way. Since Adium is using the precompiled libpurple.framework which includes msn-pecan, changing Adium's compilation settings won't change anything with this debug log.

gdb is trying to load debug info from the object files, the intermediate files created during compilation. Unfortunately, these don't exist on your system, but rather on mine, for the binary you're using. That's the source of these lines:

warning: Could not find object file "/Users/evands/adium/Utilities/dep-build-scripts/build/libpurple-i386/libpurple/../libpurple/protocols/msn_pecan/libmsn_pecan.a(libmsn_pecan_a-msn.o)" - no debug information available for "/Users/evands/pidgin-for-adium/libpurple/protocols/msn_pecan/msn.c".

You need to be running with a copy of libpurple you've compiled in order to be able to debug libpurple and its protocol plugins.

adium/Utilities/dep-build-scripts/README has step-by-step instructions for doing so. :)

I'm attempting to get this done, but running into some road blocks. I have monotone and the pidgin source, I have my ENV set up as per spec "PIDGIN_SOURCE=/Users/jdunn/source/im.pidgin.pidgin.next.minor" and I get to the ./purple_make.sh and it borks out. Here is a snippet:

libpurple/protocols/bonjour/Makefile.am:9: compiling bonjour.c' with per-target flags requires AM_PROG_CC_C_O' in `configure.ac' configure.ac:2390: required file `libpurple/protocols/msn_pecan/Makefile.in' not found

I have both a msn_pecan and msn-pecan:

thoth:protocols jdunn$ ls -lhad msn* drwxr-xr-x 72 jdunn staff 2.4K Jul 5 01:57 msn drwxr-xr-x 49 jdunn staff 1.6K Jul 5 01:48 msn-pecan drwxr-xr-x 50 jdunn staff 1.7K Jul 5 01:57 msn_pecan drwxr-xr-x 63 jdunn staff 2.1K Jul 5 01:57 msnp9 thoth:protocols jdunn$ pwd /Users/jdunn/source/im.pidgin.pidgin.next.minor/libpurple/protocols

Any ideas what I missed along the way?

My best guess is that you have the 'origin' branch of msn-pecan rather than the 'adium_test' branch. I think it's a good guess since the README neglects to mention this at all! Here's what to do:

After installing git:

cd libpurple/protocols
rm -rf msn_pecan
rm -rf msn-pecan
git clone git://github.com/felipec/msn-pecan.git msn_pecan
cd msn_pecan
git checkout -b adium_test origin/adium_test

Oh, the README does in HEAD... but that's a recent change. If you hadn't updated, you wouldn't know about it.

Yeah, it's recent. You only need the 'adium' branch, but if you feel adventurous you can try adium_test.

By the way, there's no 'origin' branch; there's 'master' (local) and 'origin/master' (remote).

Would you like a README.adium?

Alright I can get it to compile now my prefs are gone and I only get options to add Bonjour and Facebook IM protocols.

adium with libpurple complied

Hopefully I got it this time. Attached is 1.3b7 with libpurple complied. Crashed within 10 seconds also. Disabling MSN resolves crash issue.

Hi,

This is the original bug reporter. Same behaviour observed with 1.3b7, as indicated by JoeDunn above. Let me know if I can pull some useful new info out from this build for you.

I downgraded 1.3b3.(Works great) If someone wants to email me directions on how to properly compile libpurple. I know the directions are there and I followed them but whenever I install Adium I know get facebook and bonjour protocols available.

Feel free to contact me directly or through the ticketing system.

I created a new ticket, #10477, by mistake.
Anyway, this crash started happening today, on several launches.
[24355], 10.4.11, Mac Mini G4. I'm afraid I don't know which version of msn-pecan is in this revision.

Still there, in [24366] ("libpurple im.pidgin.pidgin 2.5.0mtn @ [65e73f7e5] with msn-pecan 0.0.14-54-g3308354.").

None of the backtraces have debugging symbols, it's not possible to find out what's the issue.

There's also not a complete log, nor any hint about how to reproduce this.

Please add any of these.

Will add information if someone can post how to compile libpurple properly to get debug symbols. Unsuccessful in attempts thus far.

Ahh, nevermind, I just reproduced it... I'm working on it.

Can you confirm that it only happens with http method?

Replying to joedunn:

Will add information if someone can post how to compile libpurple properly to get debug symbols. Unsuccessful in attempts thus far.

It looked in previous attempts like your newly compiled libpurple hadn't been copied into Adium for use. (Note: At some point in the not-too-distant future, compiling libpurple will hopefully be part of a standard build process, making such symbols always available for folks compiling from svn)

Aha! found it.

I've been having this bug presented in a different way for some time, but I wasn't being able to reproduce it reliably until now.

So now it's fixed in 87ff42. Please update.

(In [24381]) "libpurple im.pidgin.pidgin 2.5.0mtn @ [65e73f7e5] with msn-pecan 0.0.14-56-g87ff421. Fixes #10280

I'm afraid this is *not* fixed. Adium crashes at every start, [24386].

Ok, I did a fresh checkout ([24387]), no crashing this time.

FTR, you don't need to do a fresh checkout; a clean build (bulldoze the build folder) will do the job just as well.

Thanks for the hint, Peter, that's a big help! :)

I was experiencing the msn_cmdproc_process_cmd crash just as everybody else in this ticket, but as opposed to them much less frequently, luckily. I just checked out, double-broomed and built a fresh copy of r24387 a little while ago to do some testing, but unfortunately I'm witnessing that the problem has deteriorated considerably, at least for me. Whereas the crashes would easily sparse over a couple of days before r24387, I'm now experiencing them consistently after a couple of minutes of Adium launch, every single launch! Basically Adium has become unusable.

My system is a 10.5.4 Leopard installation, building Adium with Xcode 3.1 and the current default settings for the Xcode project (Adium target, Development rules). Below is an excerpt of the most recent crash log (but I have several of them, all belonging to r24387, so let me know if you want to see them):

Process:         Adium [10563]
Path:            /Applications/Adium.app/Contents/MacOS/Adium
Identifier:      com.adiumX.adiumX
Version:         1.3b7 (1.3b7)
Code Type:       X86 (Native)
Parent Process:  launchd [276]

Date/Time:       2008-07-16 21:04:41.464 -0430
OS Version:      Mac OS X 10.5.4 (9E17)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000200
Crashed Thread:  0

Thread 0 Crashed:
0   libpurple                           0x1880f005 msn_cmdproc_process_cmd + 127
1   libpurple                           0x18811a7c msn_transaction_unqueue_cmd + 137
2   libpurple                           0x1880f25c msn_cmdproc_process_cmd + 726
3   libpurple                           0x1880f2f4 msn_cmdproc_process_cmd_text + 96
4   libpurple                           0x18816d06 parse_impl + 489
5   libpurple                           0x18815a72 pecan_node_parse + 36
6   libpurple                           0x188152f9 read_cb + 378
7   libglib                             0x18632832 g_io_unix_dispatch + 137
8   libglib                             0x185f3506 g_main_dispatch + 498
9   libglib                             0x185f4aa8 g_main_context_dispatch + 138
10  libglib                             0x185f5033 g_main_context_iterate + 1312
11  libglib                             0x185f5273 g_main_context_iteration + 163
12  com.adiumX.AdiumPurple              0x1851b971 glib_runloop_iterator + 32
13  com.apple.CoreFoundation            0x952be9c2 __CFRunLoopDoObservers + 466
14  com.apple.CoreFoundation            0x952bfd32 CFRunLoopRunSpecific + 866
15  com.apple.CoreFoundation            0x952c0cf8 CFRunLoopRunInMode + 88
16  com.apple.HIToolbox                 0x96cadda4 RunCurrentEventLoopInMode + 283
17  com.apple.HIToolbox                 0x96cadbbd ReceiveNextEventCommon + 374
18  com.apple.HIToolbox                 0x96cada31 BlockUntilNextEventMatchingListInMode + 106
19  com.apple.AppKit                    0x96126505 _DPSNextEvent + 657
20  com.apple.AppKit                    0x96125db8 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
21  com.apple.AppKit                    0x9611edf3 -[NSApplication run] + 795
22  com.apple.AppKit                    0x960ec030 NSApplicationMain + 574
23  com.adiumX.adiumX                   0x00003247 main + 30
24  com.adiumX.adiumX                   0x00002bb2 _start + 216
25  com.adiumX.adiumX                   0x00002ad9 start + 41

Let me know if you need any more information!

-jmpp

PS: I'm gonna wait until someone confirms this before I re-open this ticket.

A small correction to my message above, the svn revision I'm referring to is r24381, the one that updated the libpurple framework with the new msn-pecan claiming to correct the msn_cmdproc_process_cmd crash.

-jmpp

Additional comment after my rather alarmist first comment above (for which I apologize if it seemed toooo alarmist): Adium has been running for a long while now, after the many failed attempts previously described, and hasn't crashed so far, with MSN connected and all. Now the only thing left to say is... I hope I didn't jinx it!

I'm holding off re-opening this ticket for the time being.

-jmpp

PS: All this while I've had MSN connected in invisible mode, both during the unstable period and now, if that helps in any way...

So I'm still getting this crash rather consistently (now running r24387 built locally from a double-broomed, fresh checkout), with intermittently long periods of survival in which I can run Adium for more than just a few seconds, but ultimately always getting the same crash, consistently.

Therefore I'm reopening the ticket, 'cause at least in my case the problem is definitely not fixed. I'll happily provide as much information as is needed to get it fixed, so don't be shy to ask!

-jmpp

Are you sure it's this crash? Please attach a new debug log. And again, a backtrace with debugging symbols would be very useful.

I'm seeing this as well; Will attach a backtrace next time it happens.

I just experienced the crash again, but unfortunately I wasn't around when it happened so I don't have a backtrace available (not that I'm acquainted enough with the Adium build process to produce one for msn-pecan, as previous comments in this ticket have revealed it's not that straightforward). I'm attaching the log, however, and later on will look into compiling libpurple/msn-pecan with debugging symbols for a gdb run.

-jmpp

PS: Anyone looking into this problem should feel free to contact me on IRC/AIM if they need more info on my system or whatever. I haven't been that active online lately, but I'm hoping to spring back into internet life soonish.

msn-pecan crash in Adium r24429

Indeed it seems to be the same crash, can you attach a debug log? Also, are you running with MALLOC_CHECK_=2 ?

MALLOC_CHECK_ doesn't exist in Mac OS X. The steps at RunningAdiumInGDB are probably what you want. Note that the default malloc() implementation in Mac OS X will log to stderr on a double-free(); the steps at RunningAdiumInGDB will just let us get a stack trace.

We can't release 1.3 with this crash, so I'm setting as a blocker on the 1.3 milestone.

Replying to evands:

MALLOC_CHECK_ doesn't exist in Mac OS X. The steps at RunningAdiumInGDB are probably what you want. Note that the default malloc() implementation in Mac OS X will log to stderr on a double-free(); the steps at RunningAdiumInGDB will just let us get a stack trace.

guard malloc (http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/libgmalloc.3.html) may also be helpful.

I'm the original reporter. If someone can get me a build containing these debug features, then I am happy to pull more logs. I wouldn't be comfortable making a clean build of Adium (take away my interpreter and you take away my development skills :-) )

Thank you for treating this issue so seriously.

Hi

This bug is listed as fixed in 1.3b9, but the same behaviour is evident in this version as before.

This appears to be fixed in 1.3b10. I am no longer getting the crash, whereas I used to get it within a minute in each previous beta with pecan.

I also have not seen this occur in the last week or so (I think) which would correspond with some of the latest updates in trunk that include msn-pecan updates.

Has anyone running 1.3b10 experienced this crash yet?

I'm one of the seemingly last few who was experiencing the crash rather frequently, but not since a while back, and particularly not once since updating to 1.3b10. If I recall correctly, latest updates to msn-pecan haven't made any reference to this bug, however.

-jmpp

No, but I think many of the crashes are related; bad handling of switchboards.

I've been tracking down all those issues I could find and after the last changes I haven't seen any memory corruption at all.

I'm going to close this. Please re-open if appropriate.

I don't know if my crash is related to this bug, I had a single adium crash since I upgraded to Leopard a few weeks ago.
I compared my crash log to those in this page and it's similar to the number 4.
I attach the crash log, let me know if it's a different issue, maybe we need another ticket.
bye

Please file a new ticket, xja, this one is pretty messy. :)