[Home]

Summary:ASTERISK-13600: [patch] IMAP crash multiple callers / callers hangup at beep
Reporter:vbcrlfuser (vbcrlfuser)Labels:
Date Opened:2009-02-17 22:10:12.000-0600Date Closed:2009-08-05 13:58:06
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Applications/app_voicemail/IMAP
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) __20090701-imapstorage-documentation-patch.txt
( 1) __20090727-imap-documentation-patch.txt
( 2) ast-ubuntu.txt
( 3) backtrace.txt
( 4) backtrace2.txt
( 5) dbrooks_asterisk_valgrind_output.txt
( 6) dbrooks_gdb_backtrace.txt
( 7) malloc_debug.txt
( 8) valgrind.txt
Description:A multiple CPU machine + asterisk-1.4.22 + imap2004g, with more than one user in voicemail (not the same mailbox) disconnecting right after or close to beep + 3 seconds timeout for abandon causes, is a bad combination.  

In same cases IMAP warnings about parsing response and in most cases a segfault. I'd like to know what the root cause is and what fixes it? I can produce any backtraces / scenarios anyone needs to lend a hand here.



****** STEPS TO REPRODUCE ******

# base configuration

 host is multi-cpu server / multi-cpu vmware image
 install minimal setup Ubuntu 8.04.1 server
 create user account phonesys uid=1000 gid=1000
 apt-get install openssh-server


# add packages needed for development and debugging

 apt-get install build-essential
 apt-get install libncurses5-dev
 apt-get install gdb


# download / install imap2004g (version DRUID/CentOS 5.2 tracks)

 cd /usr/src
 wget ftp://ftp.cac.washington.edu/imap/old/imap-2004g.tar.Z
 tar -xzvf imap-2004g.tar.Z
 cd imap-2004g
 make slx SSLTYPE=none
 make install

# install / configure dovecot IMAP server for asterisk and postfix

 apt-get install dovecot-imapd postfix

 mkdir /var/mail/asterisk
 mkdir /var/mail/asterisk/phonesys
 chown phonesys:phonesys /var/mail/asterisk/phonesys
 
 cd /etc/dovecot
 mv dovecot.conf dovecot.conf.bak
 edit /etc/dovecot/dovecot.conf
 mail_location = maildir:/var/mail/asterisk/phonesys/%u
 passdb passwd-file {
    args = /etc/dovecot/dovecot.masterusers
    master = yes
 }  
 userdb static {
    args = uid=1000 gid=1000
 }

 cd /etc/dovecot    
 edit /etc/dovecot/dovecot.masterusers
 phonesys:{PLAIN}phonesys

 /etc/init.d/dovecot restart

# download / install asterisk 1.4.22 (version DRUID tracks)
 
 cd /usr/src
 wget http://downloads.digium.com/pub/asterisk/old-releases/asterisk-1.4.22.tar.gz
 tar -xzvf asterisk-1.4.22.tar.gz
 cd asterisk-1.4.22
 ./configure --with-imap=/usr/src/imap2004g
 make menuselect (enable IMAP_STORAGE under Voicemail Build Options)
 make
 make install
 make samples


# configure some SIP accounts to dial-in with

 mv /etc/asterisk/sip.conf /etc/asterisk/sip.conf.bak
 edit /etc/asterisk/sip.conf

 [general]
 context=recreate
 allowoverlap=no
 bindport=5060
 bindaddr=0.0.0.0
 srvlookup=yes
 dtmfmode=rfc8233
 checkmwi=10

 [softphone](!)
 type=friend
 context=recreate
 host=dynamic
 secret=opensource

 [user1](softphone)
 mailbox=3001
 [user2](softphone)
 mailbox=3002
 [user3](softphone)
 mailbox=3003
 [user4](softphone)
 mailbox=3004
 [user5](softphone)
 mailbox=3005
 [user6](softphone)
 mailbox=3006
 [user7](softphone)
 mailbox=3007
 [user8](softphone)
 mailbox=3008
 [user9](softphone)
 mailbox=3009



# configure some voicemail accounts

 mv /etc/asterisk/voicemail.conf /etc/asterisk/voicemail.conf.bak
 edit /etc/asterisk/voicemail.conf

 [general]
 format=wav
 serveremail=asterisk
 attach=yes
 maxmsg=100
 maxmessage=180
 minmessage=3
 maxgreet=60
 skipms=3000
 maxsilence=10
 silencethreshold=128
 maxlogins=3
 sendvoicemail=yes
 imapserver=localhost
 imapflags=notls
 authuser=phonesys
 authpassword=phonesys
 expungeonhangup=yes


 [zonemessages]
 eastern=America/New_York|'vm-received' Q 'digits/at' IMp
 central=America/Chicago|'vm-received' Q 'digits/at' IMp
 central24=America/Chicago|'vm-received' q 'digits/at' H N 'hours'
 military=Zulu|'vm-received' q 'digits/at' H N 'hours' 'phonetic/z_p'
 european=Europe/Copenhagen|'vm-received' a d b 'digits/at' HM

 [default]
 3001 => 3001,user1,user1@recreate.bug,,imapuser=user1
 3002 => 3002,user2,user2@recreate.bug,,imapuser=user2
 3003 => 3003,user3,user3@recreate.bug,,imapuser=user3
 3004 => 3004,user4,user4@recreate.bug,,imapuser=user4
 3005 => 3005,user5,user5@recreate.bug,,imapuser=user5
 3006 => 3006,user6,user6@recreate.bug,,imapuser=user6
 3007 => 3007,user7,user7@recreate.bug,,imapuser=user7
 3008 => 3008,user8,user8@recreate.bug,,imapuser=user8
 3009 => 3009,user9,user9@recreate.bug,,imapuser=user9


# configure a minimal dialplan to quickly get in to voicemail mailboxes

 mv /etc/asterisk/voicemail.conf /etc/asterisk/voicemail.conf.bak
 edit /etc/asterisk/extension.conf

 [general]
 static=yes
 writeprotect=no
 clearglobalvars=no

 [macro-sendtovmail]
 exten => s,1,Answer
 exten => s,n,Voicemail(${ARG1},u)
 exten => s,n,Hangup

 [recreate]
 exten => _300X,1,Macro(sendtovmail, ${EXTEN})


# fireup asterisk, simulate concurrent callers in vmail how ever you choose, hanging up a close as possible to after beep + 3 seconds, I use a custom SIP client written with PJSUA library here

 asterisk -cgvvvv

 
# asterisk sputters when client disconnects in the first few seconds of voicemail on a production system and in this scenario (NOTE: this not just a PJSUA problem). It starts spitting IMAP parsing errors

[Feb 17 21:47:43] WARNING[23822]: app_voicemail.c:1710 mm_log: IMAP Warning: Missing IMAP reply key: *
[Feb 17 21:47:43] WARNING[23821]: app_voicemail.c:1710 mm_log: IMAP Warning: Not an atom:
[Feb 17 21:47:43] WARNING[23821]: app_voicemail.c:1710 mm_log: IMAP Warning: Bogus string list member:
[Feb 17 21:47:43] WARNING[23821]: app_voicemail.c:1710 mm_log: IMAP Warning: Bogus header field list: (
[Feb 17 21:47:43] WARNING[23821]: app_voicemail.c:1710 mm_log: IMAP Warning: IMAP server sent a blank line
[Feb 17 21:47:43] WARNING[23821]: app_voicemail.c:1710 mm_log: IMAP Warning: Missing IMAP reply key: )

# if it sputters bad enough it chokes on the IMAP parse hard enough to segfault

(gdb) bt
#0  ucase (s=0x0) at misc.c:43
#1  0xb7b8230d in imap_parse_unsolicited (stream=0x825cbb0, reply=0x82b6da4) at imap4r1.c:3596
#2  0xb7b84b0c in imap_reply (stream=0x825cbb0, tag=0xb7132dfe "00000052") at imap4r1.c:3453
#3  0xb7b84c0c in imap_sout (stream=0x825cbb0, tag=0xb7132dfe "00000052", base=0x82b6df8 "PERMANENTFLAGS", s=0xb71329f8)
   at imap4r1.c:3411
#4  0xb7b86687 in imap_send (stream=0x825cbb0, cmd=0xb7bfc73f "SELECT", args=0xb7132e60) at imap4r1.c:3045
ASTERISK-1  0xb7b8cb31 in imap_open (stream=0x825cbb0) at imap4r1.c:957
ASTERISK-2  0xb7b69cf6 in mail_open (stream=0x825cbb0,
   name=0xb7134246 "{localhost:143/imap/authuser=phonesys/notls/user=user8}INBOX", options=0) at mail.c:1220
ASTERISK-3  0xb7b382aa in ?? () from /usr/lib/asterisk/modules/app_voicemail.so
ASTERISK-4  0xb7b4368d in ?? () from /usr/lib/asterisk/modules/app_voicemail.so
ASTERISK-5  0xb7b43fe6 in ?? () from /usr/lib/asterisk/modules/app_voicemail.so
ASTERISK-6 0xb7b4b8db in ?? () from /usr/lib/asterisk/modules/app_voicemail.so
ASTERISK-7 0xb7b4dc3f in ?? () from /usr/lib/asterisk/modules/app_voicemail.so
ASTERISK-8 0x080cd260 in pbx_extension_helper (c=0x81ff888, con=0x0, context=0x81ffa08 "macro-sendtovmail", exten=0x81ffa58 "s",
   priority=2, label=0x0, callerid=0x82fab48 "user8", action=E_SPAWN) at pbx.c:537
ASTERISK-9 0xb7852084 in _macro_exec (chan=0x81ff888, data=<value optimized out>, exclusive=0) at app_macro.c:308
ASTERISK-10 0x080cd260 in pbx_extension_helper (c=0x81ff888, con=0x0, context=0x81ffa08 "macro-sendtovmail", exten=0x81ffa58 "s",
   priority=1, label=0x0, callerid=0x82fab48 "user8", action=E_SPAWN) at pbx.c:537
ASTERISK-11 0x080cec15 in __ast_pbx_run (c=0x81ff888) at pbx.c:2317
ASTERISK-12 0x080cfb5e in pbx_thread (data=0x81ff888) at pbx.c:2621
ASTERISK-13 0x0810215b in dummy_start (data=0x8213578) at utils.c:912
ASTERISK-14 0xb7eff4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
ASTERISK-15 0xb7e18e5e in clone () from /lib/tls/i686/cmov/libc.so.6




****** ADDITIONAL INFORMATION ******

This is a follow on report after blitzrage kindly asked me to reproduce this error in 'vanilla' asterisk not DRUID/VoiceRoute asterisk.

This bug happens using 'vanilla' asterisk using the same UW IMAP version CentOS 5.2 ships with and asterisk 1.4.22 being used by the folks over at DRUID/VoiceRoute

If you want backtraces please see them here http://bugs.digium.com/view.php?id=14494
Comments:By: vbcrlfuser (vbcrlfuser) 2009-02-17 22:11:58.000-0600

Attached are the instructions to reproduce this on Ubuntu 8.04.1
By: Leif Madsen (lmadsen) 2009-02-18 07:33:55.000-0600

Thanks for the thorough bug report! Hopefully a developer can look at it shortly. The primary IMAP developer is gone on vacation for a week, but I'll see if I can get someone else to take a gander :)
By: vbcrlfuser (vbcrlfuser) 2009-02-18 11:18:32.000-0600

Ok more information. Each time there is a core dump the backtrace indicates more than one thread in libc-client library. The segfaults happen on libc calls like ucase or strtok.

Theorized that libc-client is not thread safe like others may have. Say in another bug report the suggestion to have ast_mutex_locks around libc-client calls. But it looks like the locks are implemented the vms structure.

Locks on the vms structure would be "perm mailbox" locks? Right? And these locks would only prevent concurrent libc-client calls to the same mailbox, not concurrent libc-client calls in general.

With that train of thought. Created a global AST_MUTEX_DEFINE_STATIC(cclient-lock). Then replaced all existing vms->lock locks around libc-client calls. Also added ones where none was not present.

The concurrent access test does not fail when these new locks are in place. Putting the non-locking version back in and segfaults come back.

Not sure what the impact of single thread access to libc-client will be. The IMAP server is local to the box. Will test this evening and report. Imagine concurrent users listening to voicemail having to fetch the body might slow down the MWI checks and quota checks for users leaving voicemail.

This heavy handed solution may be tolerable given the alternative is segfaults, until a better solution, by someone far wiser than I, comes along.
By: vbcrlfuser (vbcrlfuser) 2009-02-20 09:36:23.000-0600

This "fix" went in to the production system last night. Things are stable today so far. Could not reproduce the crash. And single threaded access through libc-client calls to IMAP server did not appear to have a negative affect on leaving  / listening to voice mails.

Will leave this issue open until digium accepts a proper fix. Also willing to try to break any official patches that may come out and help to verify this is resolved.
By: Leif Madsen (lmadsen) 2009-02-24 11:52:44.000-0600

I'm going to assign this to putnopvut for now to see if he has an idea of how to move this forward. However he is currently on vacation, so might not be around until sometime next week.

Thanks!
By: vbcrlfuser (vbcrlfuser) 2009-02-24 17:10:23.000-0600

Thanks for the status update lmadsen. Will look for more info from putnopvut as it becomes available.

Update from this end. Going on five days now no crashes. No complaints of vmail performance using single threaded access either.

One clarification I want to make is it does not seem to matter when you hung up so much as you hung up multiple calls in the process of leaving a voice mail at the exact same time.

That was the secret sauce to causing the segfaults. Placing locks around every libc-client call has apparently fixed it. So I've concluded it is a thread safety issue with libc-client. But that may not be the case when someone looks deep enough in to it.
By: vbcrlfuser (vbcrlfuser) 2009-03-03 09:36:05.000-0600

bump
By: Leif Madsen (lmadsen) 2009-03-03 13:21:37.000-0600

mmichelson has just gotten back from being sick, so might still have to wait a bit for him to get through some of the more important issues he is trying to tackle. Thanks!
By: Mark Michelson (mmichelson) 2009-03-03 15:31:12.000-0600

Reading the comments on this bug report are leaving me in awe. Thanks for the thorough investigation into this problem. I can't believe that the c-client has such thread-safety issues. That is just so bizarre. Would you mind uploading your AST_MUTEX_STATIC changes as a patch so that they can be reviewed and potentially merged into Asterisk? Thanks!
By: vbcrlfuser (vbcrlfuser) 2009-03-04 13:26:26.000-0600

I can provide the patch. The problem is I do not work on 'vanilla' Asterisk. Love that expression. Thanks blitzrage!

The patch I would provide comes off of DRUID/VoiceRoute Asterisk which has been hacked on quite a bit.

And I'm sure I did not follow the conventions the Asterisk community expects or any adept C programmer expects. Just did what it took to stop segfaults.

I can provide it as an example of where I went with things but don't expect it to be merged as is. Still interested?
By: Leif Madsen (lmadsen) 2009-03-04 16:34:22.000-0600

vbcrlfuser: glad I could give you a new term to add to your repo :)

OK, so I understand where you're coming from. Perhaps you can provide the patch anyways and one of the developers looking at this issue can see if it'll help to solve the issue. Just make sure you have a license on file if not already so we'll be able to look at it ;)

Thanks!
Leif.
By: vbcrlfuser (vbcrlfuser) 2009-03-05 10:54:30.000-0600

Tell you what. Let me be a good citizen. Make the changes to stock 1.4.22. Then cut a patch and submit that.

That way I can sign the license for myself. And avoid any potential DRUID/VoiceRoute conflicts.

My day job has me rather busy right now. But I'll get the patch in tonight or tomorrow.
By: Leif Madsen (lmadsen) 2009-03-05 11:28:13.000-0600

Awesome! Thanks for doing that. I had actually just been thinking about that after I had posted my note. Will look forward to the patch.

Leif!
By: Leif Madsen (lmadsen) 2009-03-23 12:29:02

vbcrlfuser: just wondering if you might have gotten a chance to make this patch? I'm going to be setting up an IMAP lab so I can test a bunch of IMAP issues soon, so it would be good if I could get your patch so I could test reproducing the crash, and potentially the fix as well.
By: Leif Madsen (lmadsen) 2009-03-24 11:59:30

I'm currently working on reproducing the issue, but wanted to thank you for the extremely detailed report!
By: Leif Madsen (lmadsen) 2009-03-24 12:46:08

I can't seem to reproduce this issue. How are you getting it to crash?

I just get this....

   -- <SIP/user1-08bfcff0> Playing 'beep' (language 'en')
   -- Recording the message
   -- x=0, open writing:  /var/spool/asterisk/voicemail/default/3001/tmp/9gecdZ format: wav, 0x8c1d470
   -- User hung up
   -- Recording was 1 seconds long but needs to be at least 3 - abandoning
 == Spawn extension (macro-sendtovmail, s, 2) exited non-zero on 'SIP/user1-08bfcff0' in macro 'sendtovmail'
 == Spawn extension (macro-sendtovmail, s, 2) exited non-zero on 'SIP/user1-08bfcff0'



I've tried doing it with a couple of phones calling 3001 and both hanging up within 3 seconds, or calling 3001 and 3002, again with both hanging up prior to the 3 second mark.

Am I missing something?

Thanks!
By: Leif Madsen (lmadsen) 2009-03-29 11:45:13

Just pinging the original reporter. Our policy is to close issues after a week of inactivity if we are unable to reproduce the issue locally. Any additional information you could provide to track down this issue would be much appreciated. Thanks!
By: vbcrlfuser (vbcrlfuser) 2009-03-30 11:43:26

Will cut the patch eventually. The job that puts food on the table has been taking all of my time, what is left is for the family, then Asterisk. Sorry folks!

To reproduce this you have to disconnect from multiple calls in voicemail at exactly the same time. The timing for duration in to voice mail does not seem to be important but you do have to mind the short message detection.

This was happening on a production system in a SIP environment using polycom handsets and SIP trunking from Paetec. And a stock 1.4.22 install as well.

I was able to reproduce it using a custom PJSUA SIP client application that simply called voicemail and left a 30 second message. Send a SIG KILL to that process to get all calls to die on the client side simultaneously. And whamo segfaults in Asterisk.

This would happen on our production system ohh about once a week I would say. Company takes 500-700 calls a day, around lunch time typically two or more users would be leaving voice mail, hang up right around the same time and cause this segfault.
By: vbcrlfuser (vbcrlfuser) 2009-03-30 11:45:54

Reading over the response need to make a point of clarification. The calls to make it crash have to be *longer* than the short message detection. That is 3+ seconds on a stock installation.
By: Leif Madsen (lmadsen) 2009-04-01 13:43:13

Thanks for the information. I think I was testing inversely of what I should have been doing. Thanks!
By: Jeff Phelps (blargman) 2009-04-03 11:56:12

vbcrlfuser:

are these the actual and complete steps you took to create this issue??

I tried doing exactly what your "Steps to Reproduce" said with a clean box and all, and couldn't even get dovecot or UW IMAP to install properly...

Also, if you are using Ubuntu, you should be using libc-client2007b and libc-client2007b-dev.

Please let us know, so we can get this reproduced and resolved for you...
By: vbcrlfuser (vbcrlfuser) 2009-04-07 12:20:41

lmadsen: can you contact me off line matt dot mcaughan at gmail dot com? I want to ask some Asterisk as a product related type questions from an person in the know.

Those are the steps documented at the time of building out the asterisk box on ubuntu 8.04.1, multi-cpu vmware image and reproducing the issue.

Re-checked and had no problems following the instructions.

libc-client went on fine. The make install step was wrong, there isn't an install target sorry, if that was the hangup. The path to the library is specified as an argument when compiling Asterisk.

Dovecot installed fine (didn't go through the configuration again).

As far as libc is concerned agree that 2004 is way out of date.

However, this issue is reported originally for DRUID asterisk 1.4.22 which runs on DRUID OS (CentOS 5.2) which ships with libc-client2004.

The Asterisk folks would not entertain a report unless vanilla 1.4.22 showed the same results. Since you probably don't have a copy of the DRUID OS distro lying around went for Ubuntu, my particular favorite.

Every effort was taken to keep all the asterisk dependencies identical between both distros as possible, including using 2004 libc-client.

As far as resolution goes... locking where indicated has resolved the segfaults for us. The bug report is simply to help the Asterisk community which may be experiencing similar.
By: Leif Madsen (lmadsen) 2009-04-09 12:27:49

vbcrlfuser: you can email me at lmadsen@digium.com.

I'll see what I can do to try and reproduce this.
By: Leif Madsen (lmadsen) 2009-05-06 11:15:53

I suppose you can't provide the hammer.sh script can you?
By: Leif Madsen (lmadsen) 2009-05-06 11:38:30

I finally simulated this I think! I got the crash after leaving a msg for about 3-4 seconds, then hanging up several lines (I was able to do this with Zoiper and 3 lines).

Find attached -- however it looks like it crashed in an odd spot!
By: Leif Madsen (lmadsen) 2009-05-06 12:44:55

Any chance of getting a copy of the hammer.sh script?
By: Leif Madsen (lmadsen) 2009-05-06 13:15:50

Reassigned to Tilghman now that I've gotten it to crash under valgrind as well.
By: Tilghman Lesher (tilghman) 2009-05-07 12:42:24

This valgrind is invalid, as it crashed within valgrind itself, not within the Asterisk code.
By: vbcrlfuser (vbcrlfuser) 2009-05-11 10:17:31

There is no hammer.sh script per say. Used custom PJSUA client that connects, plays 30 second message, and hangs up. Would get 5-10 of these working on leaving a message, givem them the 3-4 seconds to get past the too short message, and SIHUP them.

Do not want to send that code because it will digress in to PJSUA not being used correctly, SIP dialog not ending correct, etc. For those already thinking that now this problem happens on a production system where PJSUA is not even involed. PJSUA simply recreates call volume in voicemail for me. It is not a PJSUA SIP usage issue.
By: Leif Madsen (lmadsen) 2009-05-11 10:23:44

I realize it's not a PJSUA problem as I can reproduce this with just 3-4 lines on a softphone.

My problem is that I can't seem to get any sort of valid debugging information, and I was hoping that the script you were using to hit the server would help me reproduce this easier and faster than with a softphone and some lines which didn't seem to be consistant in reproducing (as I have to setup all the lines manually).
By: Leif Madsen (lmadsen) 2009-05-15 08:04:44

I will have to come back to this a bit later as it seems all I was doing was crashing valgrind, and not getting a proper backtrace or valgrind output here. I'll try again later today.
By: Leif Madsen (lmadsen) 2009-06-15 12:56:52

Note: I had attempted to try reproducing this a couple of weeks ago, but was unable to get it to crash for me. I have a feeling I'll have to spend some time getting SIPP setup with a scenario to try and test this that way...
By: Leif Madsen (lmadsen) 2009-06-15 15:29:17

Reassigning this issue to dbrooks so he can take a shot at reproducing this issue. I have a feeling my issue may have been with trying to do it in a virtual machine.

dbrooks: get with me before you start on this so we can discuss. You may need a couple of machines and need to setup sipp to generate the testing reliably.
By: David Brooks (dbrooks) 2009-06-23 17:04:20

I was unable to reproduce this issue exactly, but I did experience a crash. I placed 2 calls, both to voicemail, after beep (3+ seconds) I hung up both calls simultaneously. From the output, it seems there is a lot of data corruption happening, but I'm not versed enough in this to say anything.

I hope the output I uploaded (dbrooks_*.txt) is useful..
By: Leif Madsen (lmadsen) 2009-06-24 14:02:47

This is just being assigned back to mmichelson for feedback.

1) dbrooks and myself can't seem to reproduce this issue, so if 2) is not a problem related here, then please just close this issue as "Unable to reproduce"

2) dbrooks added a backtrace -- is that related to this issue? If not, then he should probably just open a new issue, and attach the backtrace there.

Thanks!
Leif.
By: Mark Michelson (mmichelson) 2009-06-24 17:30:26

I'm not sure if dbrooks' crash is related to this problem or not. The crash is happening in the c-client, not Asterisk. The valgrind output is only showing potential memory leaks, no bad accesses of memory (at least none besides the ones that always show up at startup in libraries used by Asterisk).

However, the string "Unlocked when not locked" in frame 1 of the backtrace makes me suspect that this might be related to the crash initially reported. The fix using the AST_MUTEX_STATIC that initially was reported...I never saw a patch posted. The thread-safety of the c-client really needs to be examined more to see what is up with it. I would hate to have to limit Asterisk to only one connection at a time to an IMAP server just because the IMAP client in use can't handle more. But imho, crappy performance is better than crashing.
By: Leif Madsen (lmadsen) 2009-06-29 11:17:16

Could we add an option like:  imapconnections=1


or something like that? I would agree that crappy performance is better than crashing. It may very well be a problem with the libraries.

dbrooks: what version of c-client were you using? Do you have the same issues with the latest c-client release?
By: David Brooks (dbrooks) 2009-06-29 14:51:19

lmadsen: I was using the 2004g version. Upon installing the 2007e version, the crash doesn't seem to occur.
By: Mark Michelson (mmichelson) 2009-06-29 14:56:23

Hmm, I wonder if the problem here is just that 2004g is really old and crappy. If the problem doesn't seem to happen when using a recent version, then we should perhaps just close this and recommend that people don't use such an ancient version of the c-client.
By: Leif Madsen (lmadsen) 2009-07-01 07:38:30

I'm in agreement. I'll provide a patch soon!
By: Leif Madsen (lmadsen) 2009-07-01 09:46:46

Patch provided!
By: Mark Michelson (mmichelson) 2009-07-01 09:55:48

The patch looks good with one exception, specifically the section about the configure script. The documentation is a bit off both before and after your change.

Currently, the configure script assumes that you have uw-imap toolkit source installed at .. and that the name of the directory is "imap-2004g" if you do not specify an argument for --with-imap. The thing is, you could put imap-2007e or any other source in that directory since all the configure script is looking for is the directory name. EDIT: The configure script does do further processing to make sure that the source is valid, but as far as where the source is located, all it cares about is the name of the directory. The compilation tests the configure script runs will work (or should work anyway) with any version of the imap toolkit.

Now, what we could do is modify the documentation and the configure script so that things are more generic. Perhaps we can clearly document that we expect to find a directory called ../imap and that it may have any version of the imap source in it for the case where --with-imap is given no argument.


By: Leif Madsen (lmadsen) 2009-07-27 12:22:23

I have attached what I hope is the correctly updated documentation, along with the configure script. I tested it, and it seems to work fine.

Let me know if you think this is sufficient. At some point we need to review the entire documentation, as I think there are probably some better "best practices" that we could put in there.

NOTE: Oops -- I will be reuploading the file in a moment since I just remembered I found a typo.
By: Leif Madsen (lmadsen) 2009-07-27 12:27:49

File updated.  What I changed was the line:

make slx SSLTYPE=none!

to not have the bang on the end -- it didn't work for me when using the latest IMAP library.
By: Digium Subversion (svnbot) 2009-08-05 13:46:39

Repository: asterisk
Revision: 210563

U   branches/1.4/doc/imapstorage.txt

------------------------------------------------------------------------
r210563 | lmadsen | 2009-08-05 13:46:39 -0500 (Wed, 05 Aug 2009) | 11 lines

Update imapstorage.txt documentation.
Updated the imapstorage.txt documentation to reflect that issues with
c-client versions older than 2007 seem to cause crashing issues that
are not seen with more recent versions. Documentation has been updated
to reflect this.

(closes issue ASTERISK-13600)
Reported by: vbcrlfuser
Patches:
     __20090727-imap-documentation-patch.txt uploaded by lmadsen (license 10)
Tested by: lmadsen, mmichelson, dbrooks
------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=210563
By: Digium Subversion (svnbot) 2009-08-05 13:50:16

Repository: asterisk
Revision: 210564

_U  trunk/
U   trunk/doc/tex/imapstorage.tex

------------------------------------------------------------------------
r210564 | lmadsen | 2009-08-05 13:50:16 -0500 (Wed, 05 Aug 2009) | 19 lines

Merged revisions 210563 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r210563 | lmadsen | 2009-08-05 13:46:21 -0500 (Wed, 05 Aug 2009) | 11 lines
 
 Update imapstorage.txt documentation.
 Updated the imapstorage.txt documentation to reflect that issues with
 c-client versions older than 2007 seem to cause crashing issues that
 are not seen with more recent versions. Documentation has been updated
 to reflect this.
 
 (closes issue ASTERISK-13600)
 Reported by: vbcrlfuser
 Patches:
       __20090727-imap-documentation-patch.txt uploaded by lmadsen (license 10)
 Tested by: lmadsen, mmichelson, dbrooks
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=210564
By: Digium Subversion (svnbot) 2009-08-05 13:54:01

Repository: asterisk
Revision: 210565

U   branches/1.6.2/doc/tex/imapstorage.tex

------------------------------------------------------------------------
r210565 | lmadsen | 2009-08-05 13:54:01 -0500 (Wed, 05 Aug 2009) | 26 lines

Merged revisions 210564 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r210564 | lmadsen | 2009-08-05 13:49:58 -0500 (Wed, 05 Aug 2009) | 19 lines
 
 Merged revisions 210563 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r210563 | lmadsen | 2009-08-05 13:46:21 -0500 (Wed, 05 Aug 2009) | 11 lines
   
   Update imapstorage.txt documentation.
   Updated the imapstorage.txt documentation to reflect that issues with
   c-client versions older than 2007 seem to cause crashing issues that
   are not seen with more recent versions. Documentation has been updated
   to reflect this.
   
   (closes issue ASTERISK-13600)
   Reported by: vbcrlfuser
   Patches:
         __20090727-imap-documentation-patch.txt uploaded by lmadsen (license 10)
   Tested by: lmadsen, mmichelson, dbrooks
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=210565
By: Digium Subversion (svnbot) 2009-08-05 13:56:46

Repository: asterisk
Revision: 210566

_U  branches/1.6.2/

------------------------------------------------------------------------
r210566 | lmadsen | 2009-08-05 13:56:45 -0500 (Wed, 05 Aug 2009) | 26 lines

Merged revisions 210564 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r210564 | lmadsen | 2009-08-05 13:49:58 -0500 (Wed, 05 Aug 2009) | 19 lines
 
 Merged revisions 210563 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r210563 | lmadsen | 2009-08-05 13:46:21 -0500 (Wed, 05 Aug 2009) | 11 lines
   
   Update imapstorage.txt documentation.
   Updated the imapstorage.txt documentation to reflect that issues with
   c-client versions older than 2007 seem to cause crashing issues that
   are not seen with more recent versions. Documentation has been updated
   to reflect this.
   
   (closes issue ASTERISK-13600)
   Reported by: vbcrlfuser
   Patches:
         __20090727-imap-documentation-patch.txt uploaded by lmadsen (license 10)
   Tested by: lmadsen, mmichelson, dbrooks
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=210566
By: Digium Subversion (svnbot) 2009-08-05 13:57:39

Repository: asterisk
Revision: 210567

_U  branches/1.6.1/
U   branches/1.6.1/doc/tex/imapstorage.tex

------------------------------------------------------------------------
r210567 | lmadsen | 2009-08-05 13:57:38 -0500 (Wed, 05 Aug 2009) | 26 lines

Merged revisions 210564 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r210564 | lmadsen | 2009-08-05 13:49:58 -0500 (Wed, 05 Aug 2009) | 19 lines
 
 Merged revisions 210563 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r210563 | lmadsen | 2009-08-05 13:46:21 -0500 (Wed, 05 Aug 2009) | 11 lines
   
   Update imapstorage.txt documentation.
   Updated the imapstorage.txt documentation to reflect that issues with
   c-client versions older than 2007 seem to cause crashing issues that
   are not seen with more recent versions. Documentation has been updated
   to reflect this.
   
   (closes issue ASTERISK-13600)
   Reported by: vbcrlfuser
   Patches:
         __20090727-imap-documentation-patch.txt uploaded by lmadsen (license 10)
   Tested by: lmadsen, mmichelson, dbrooks
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=210567
By: Digium Subversion (svnbot) 2009-08-05 13:58:05

Repository: asterisk
Revision: 210568

_U  branches/1.6.0/
U   branches/1.6.0/doc/tex/imapstorage.tex

------------------------------------------------------------------------
r210568 | lmadsen | 2009-08-05 13:58:04 -0500 (Wed, 05 Aug 2009) | 26 lines

Merged revisions 210564 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r210564 | lmadsen | 2009-08-05 13:49:58 -0500 (Wed, 05 Aug 2009) | 19 lines
 
 Merged revisions 210563 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r210563 | lmadsen | 2009-08-05 13:46:21 -0500 (Wed, 05 Aug 2009) | 11 lines
   
   Update imapstorage.txt documentation.
   Updated the imapstorage.txt documentation to reflect that issues with
   c-client versions older than 2007 seem to cause crashing issues that
   are not seen with more recent versions. Documentation has been updated
   to reflect this.
   
   (closes issue ASTERISK-13600)
   Reported by: vbcrlfuser
   Patches:
         __20090727-imap-documentation-patch.txt uploaded by lmadsen (license 10)
   Tested by: lmadsen, mmichelson, dbrooks
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=210568