[asterisk-dev] Urgent development consultancy wanted

Tue May 22 12:24:19 CDT 2012

On Tue, May 22, 2012 at 04:07:40PM +0200, Alistair Cunningham wrote:
> On 22/05/12 15:44, Kevin P. Fleming wrote:
> >It is possible that the patch in revision 365896 could be related,
> >although the symptoms sound slightly different.
> 
> Kevin,
> 
> Thank you, that does sound similar. Do you know if it's been
> included in any 1.8.X versions? I'm never quite sure how to
> determine this.

In case anyone is interested, this is how I look up what is on the different
Asterisk branches/tags with git:

First you'll need a git clone of Asterisk with the different
branches and tags. I personally just use the one Tzafrir has setup until there
is an official mirror. This clone can take time the first time you do it, but
keeping it updated is quick. Since you're not going to be building from this
clone, the "--mirror" flag simplifies some things.

  $ git clone --mirror git://gitorious.org/asterisk-tools/asterisk.git

Now that you have a local clone you can search for the revision on
all the branches. git-svn, which Tzafrir uses to keep the git repo
synched with the subversion branches, will add a line to the log
that contains an svn url where the commit came from in a
"git-svn-id" line.

  $ git log --branches --grep="@365896" -1
  commit f22c41cbfb08b7438107311cd28a33909e89274b
  Author: Mark Michelson <mmichelson at digium.com>
  Date:   Wed May 9 16:11:52 2012 +0000

      Prevent sip_pvt refleak when an ast_channel outlasts its corresponding sip_pvt.

      chan_sip was coded under the assumption that a SIP dialog with an owner channel
      will always be destroyed after the owner channel has been hung up.

      However, there are situations where the SIP dialog can time out and auto destruct
      before the corresponding channel has hung up. A typical example of this would be
      if the 'h' extension in the dialplan takes a long time to complete. In such cases,
      __sip_autodestruct() would complain about the dialog being auto destroyed with
      an owner channel still in place. The problem is that even once the owner channel
      was hung up, the sip_pvt would still be linked in its ao2_container because nothing
      would ever unlink it.

      The fix for this is that if __sip_autodestruct() is called for a sip_pvt that still
      has an owner channel in place, the destruction is rescheduled for 10 seconds in the
      future. This will continue until the owner channel is finally hung up.

      (closes issue ASTERISK-19425)
      reported by David Cunningham
      Patches:
          ASTERISK-19425.patch uploaded by Mark Michelson (License #5049)

      (closes issue ASTERISK-19455)
      reported by Dean Vesvuio
      Tested by Dean Vesvuio

      git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@365896 f38db490-d61c-443f-a65b-d21fe96a405b
  $

Now I can take the oneline summary from the commit "Prevent sip_pvt
refleak when an ast_channel outlasts its corresponding sip_pvt." and
search for that in the histories of all tags:

  $ git log --grep="Prevent sip_pvt refleak when an ast_channel outlasts its corresponding sip_pvt." --tags
  $

This comes back empty which means that there are no tags in the repo
have this particular summary in any of the commits that are
contained in the tag.

For a more interesting example, pretend you want to see which 10.x releases
have AST-2012-006 on them.  First, let's see what branches have a commit with
that string in the commit message:

  $ git log --grep="AST-2012-006" --branches  | grep -e ^commit -e git-svn-id
  commit 264ad42db6006b9f34a6b40e3c333fadabff4b36
      git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10-digiumphones@365214 f38db490-d61c-443f-a65b-d21fe96a405b
  commit 78d4bb412036a789474341ad74a3f476b0b329fc
      git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8-digiumphones@363161 f38db490-d61c-443f-a65b-d21fe96a405b
  commit a739bd7b4103383ed99f0754c6ccc90369217439
      git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@363108 f38db490-d61c-443f-a65b-d21fe96a405b
  commit b600e134c70bd1c2069c8c3b63d39ac12c96d1dc
      git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@363107 f38db490-d61c-443f-a65b-d21fe96a405b
  commit 2c068733315b9f5f7d7b93aa9992d93674d98e1c
      git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/1.8@363106 f38db490-d61c-443f-a65b-d21fe96a405b

Ok, we can see that it went onto the 10 branch in commit 363107 above. So let's
see all the tags that reference that commit:

  $ git log --grep="363107" --tags | grep ^commit | xargs git describe --contains
  Could not get sha1 for commit. Skipping.
  Could not get sha1 for commit. Skipping.
  Could not get sha1 for commit. Skipping.
  Could not get sha1 for commit. Skipping.
  v10.5.0-digiumphones-rc1~5
  v10.4.0-rc2~2
  v10.3.1~3
  v10.5.0-rc1~38

So it looks like 10.5.0-digiumphones 10.4.0 10.3.1 and 10.5.0 all have commits
on them that directly reference that svn revision. If you grab the commit where
it went in on the 1.8 branch you can also see that it looks like 1.8.12.0 and
1.8.11.1, and 1.8.13 also contain that fix.

  $ git log --grep="363106" --tags | grep ^commit | xargs git describe --contains
  Could not get sha1 for commit. Skipping.
  Could not get sha1 for commit. Skipping.
  Could not get sha1 for commit. Skipping.
  Could not get sha1 for commit. Skipping.
  Could not get sha1 for commit. Skipping.
  v10.5.0-digiumphones-rc1~5
  v1.8.12.0-rc2~2
  v1.8.11.1~3
  v10.5.0-rc1~38
  v1.8.13.0-rc1~34

Maybe someone will find this useful...

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org