| 00:59.13 | *** join/#asterisk-bugs blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 00:59.13 | *** mode/#asterisk-bugs [+o blitzrage] by ChanServ |
| 01:48.43 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 01:58.49 | *** join/#asterisk-bugs ddougan (n=ddougan@h24-86-0-246.sbm.shawcable.net) |
| 02:38.10 | *** join/#asterisk-bugs Mackes (n=root@cpe-76-180-236-119.buffalo.res.rr.com) |
| 02:38.36 | *** part/#asterisk-bugs Mackes (n=root@cpe-76-180-236-119.buffalo.res.rr.com) |
| 06:41.37 | *** join/#asterisk-bugs enst (n=enst@60.28.119.64) |
| 06:50.13 | *** join/#asterisk-bugs enst (n=enst@60.28.119.64) |
| 07:54.14 | *** join/#asterisk-bugs agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 10:15.02 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 10:43.11 | *** join/#asterisk-bugs enst (n=enst@60.28.119.64) |
| 13:12.07 | *** join/#asterisk-bugs zerohalo (n=zeroHalo@pool-71-255-162-167.bstnma.east.verizon.net) |
| 13:12.18 | *** join/#asterisk-bugs jsmith (n=jsmith@68.246.137.171) |
| 13:12.19 | *** mode/#asterisk-bugs [+o jsmith] by ChanServ |
| 13:27.54 | *** part/#asterisk-bugs jmls (n=jmls@62.49.235.130) |
| 13:36.06 | *** join/#asterisk-bugs jmls (n=jmls@62.49.235.130) |
| 14:05.15 | *** join/#asterisk-bugs blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:05.16 | *** mode/#asterisk-bugs [+o blitzrage] by ChanServ |
| 15:04.08 | *** join/#asterisk-bugs mbranca (n=matteo@host-210-mi.linuxserver.it) |
| 15:20.41 | *** join/#asterisk-bugs jcmoore (n=jcmoore@unaffiliated/tgrman) |
| 15:21.39 | *** join/#asterisk-bugs miguel3239 (n=elguerom@ns1.nashuacs.com) |
| 15:37.33 | *** join/#asterisk-bugs seanbright (n=elixer@65.207.74.18) |
| 15:44.19 | *** join/#asterisk-bugs putnopvut (i=putnopvu@nat/digium/x-724b8ba603112084) |
| 15:44.19 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 17:07.32 | *** join/#asterisk-bugs zerohalo (n=zeroHalo@pool-71-255-162-167.bstnma.east.verizon.net) |
| 17:23.59 | *** join/#asterisk-bugs jsmith (n=jsmith@68.246.137.171) |
| 17:23.59 | *** mode/#asterisk-bugs [+o jsmith] by ChanServ |
| 17:46.49 | *** join/#asterisk-bugs zerohalo (n=zeroHalo@pool-71-255-162-167.bstnma.east.verizon.net) |
| 17:50.33 | *** part/#asterisk-bugs agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 17:51.57 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 18:32.08 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 19:11.56 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 19:27.34 | *** join/#asterisk-bugs agx (n=badpengu@81-174-46-174.dynamic.ngi.it) |
| 19:44.21 | putnopvut | M11227 |
| 19:44.22 | MuffinMan | [new] [Asterisk] Channels/chan_sip/General 0011227: crash at __ast_pthread_mutex_lock&pkt->owner->lock can not access reported by enst http://bugs.digium.com/view.php?id=11227 |
| 19:44.38 | putnopvut | My first inclination is that the sip_pvt gets destroyed between the time of scheduling and the time of execution. |
| 19:44.56 | putnopvut | Is this a valid assumption, or is such a scenario impossible? |
| 19:57.33 | putnopvut | Looking through chan_sip, I think what I am suggesting CAN happen, sort of. |
| 19:57.37 | file | I see what you are thinking. |
| 19:57.50 | putnopvut | In __sip_destroy, we detach p->owner before destroying all packets... |
| 19:58.12 | putnopvut | So if a scheduled retransmit happens between those two items...crash. |
| 19:59.12 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 19:59.13 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 19:59.22 | putnopvut | Unless the order here serves a real purpose that I don't already know, then I think a fix for the crash would be to schedule the deletion of all the packets, THEN remove the p->owner. |
| 20:02.44 | putnopvut | Okay, I'm going to commit my proposed idea as a fix for the issue then. |
| 20:02.59 | putnopvut | Provided it passes my local testing... |
| 20:30.44 | *** join/#asterisk-bugs oej (n=olle@soll4-125.cust.blixtvik.net) |
| 21:44.20 | *** part/#asterisk-bugs zerohalo (n=zeroHalo@pool-71-255-162-167.bstnma.east.verizon.net) |
| 22:24.05 | Qwell | putnopvut: Tilghman was pondering something similar yesterday - or maybe Friday |
| 22:24.46 | Corydon76-dig | putnopvut: that fix was already committed yesterday |
| 22:25.32 | Qwell | M11227 |
| 22:25.33 | MuffinMan | [new] [Asterisk] Channels/chan_sip/General 0011227: crash at __ast_pthread_mutex_lock&pkt->owner->lock can not access reported by enst http://bugs.digium.com/view.php?id=11227 |
| 22:25.52 | Qwell | same bug? |
| 22:25.58 | Corydon76-dig | A89184 |
| 22:26.00 | MuffinMan | [89184] Committed by tilghman on 2007-11-12 13:29:17: Fix two cases of memory corruption caused by background threads. |
| 22:26.10 | Corydon76-dig | M10923 |
| 22:26.11 | MuffinMan | [feedback] [Asterisk] Channels/chan_sip/General 0010923: crash in ast_var_name on SIP hangup reported by atis http://bugs.digium.com/view.php?id=10923 |
| 22:29.25 | Corydon76-dig | putnopvut: in response to your question, what I'm doing is to delay the destruction until all of those packets have been delivered... because they were put on that queue with reliable_xmit, which means we want to ensure that they get sent |
| 22:30.08 | putnopvut | All right. |
| 22:31.14 | putnopvut | Which question is that in response to? |
| 22:32.22 | Corydon76-dig | [13:59:22] <putnopvut> Unless the order here serves a real purpose that I don't already know, then I think a fix for the crash would be to schedule the deletion of all the packets, THEN remove the p->owner. |
| 22:32.48 | Corydon76-dig | It was in response to that statement |
| 22:33.44 | Corydon76-dig | As Qwell pointed out to me, that reliable_xmit could be a BYE... and if we cancel the BYE, then a SIP dialog remains open... which is bad |
| 22:33.58 | putnopvut | That's true. |
| 22:34.14 | Qwell | ahh, tzanger would love that statement |
| 22:34.33 | putnopvut | The thing is, is it possible for a packet to continue to exist while its sip_pvt "owner" has already been free'd? |
| 22:34.36 | Qwell | he was trolling earlier, talking about how we say "bad things" happen...never really going into detail about what |
| 22:34.51 | putnopvut | I don't think he was trolling so much as finding amusement. |
| 22:34.59 | Qwell | light trolling :) |
| 22:35.01 | Corydon76-dig | putnopvut: it was possible before, because the pkt is scheduled with a background thread |
| 22:35.06 | Qwell | not all trolling is mean |
| 22:35.34 | putnopvut | Okay, so you're saying your fix could also fix 11227 then? |
| 22:35.45 | Corydon76-dig | Yes |
| 22:35.58 | Corydon76-dig | If that's is the actual problem |
| 22:36.17 | Corydon76-dig | I'm asking everybody with a possible crash caused by memory corruption to look at doc/valgrind.txt |
| 22:36.17 | putnopvut | Yeah, unfortunately this seems like something that would be incredibly hard to reproduce. |
| 22:36.35 | Corydon76-dig | Because the valgrind output tells us in no uncertain terms what the issue is |
| 22:36.47 | putnopvut | Okay, so here's my plan with that one then: |
| 22:36.55 | putnopvut | I'll ask the reporter to run under valgrind. |
| 22:37.05 | Corydon76-dig | Well, even if valgrind slows it down to the point where the problem doesn't occur, it still sees the race |
| 22:37.13 | putnopvut | Right. |
| 22:37.23 | Corydon76-dig | and seeing the race is what we need to fix it |
| 22:37.52 | putnopvut | Okay, I was going to suggest running under valgrind in revision 89184 or greater too. |
| 22:38.07 | putnopvut | That way we can see if your fix did the job. |
| 22:38.09 | Corydon76-dig | If you want to revise what I put in doc/valgrind.txt, go ahead... I did it quickly, and I've referenced it a bunch of times already |
| 22:38.36 | putnopvut | I don't see any need for that. doc/valgrind.txt has the steps to take and how to take them. |
| 22:39.12 | Corydon76-dig | I know, but I was in a hurry... and me no talk good when I hurry |
| 22:39.56 | putnopvut | Ah, I see you've already posted a note on the issue. I guess I'll just change the status to feedback and wait for followup. |
| 22:40.05 | Corydon76-dig | k |
| 23:01.43 | *** part/#asterisk-bugs agx (n=badpengu@81-174-46-174.dynamic.ngi.it) |