Summary:	ASTERISK-14540: Possible crash in astobj2
Reporter:	Private Name (falves11)	Labels:
Date Opened:	2010-05-18 17:30:46	Date Closed:	2010-06-03 11:50:49
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) crash_obj1.txt ( 1) crash_obj2.txt
Description:	I will upload the traces in 1 minute
Comments:	By: Paul Belanger (pabelanger) 2010-05-18 20:47:42 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.6.0 and 1.6.1 branches has ended. For continued maintenance support please move to the 1.6.2 branch. More information on this change can be found in the release announcement: http://www.asterisk.org/node/49924 By: Private Name (falves11) 2010-05-18 20:55:34 I still have open bugs where I uploaded patches for 1.6.1. How can I move to 1.6.2 unless the patches are applied also to 1.6.2 first? The patches provided critical stability needed to ODBC and other sections. Please check https://issues.asterisk.org/view.php?id=17248 https://issues.asterisk.org/view.php?id=17264 https://issues.asterisk.org/view.php?id=15464 https://issues.asterisk.org/view.php?id=17084 I beg you to commit the patches and also apply them to 1.6.2, so I may upgrade. By: Leif Madsen (lmadsen) 2010-05-19 09:33:56 The first issue I looked at is ASTERISK-16017 which had a patch posted for you to test and there is no feedback from you about the result or an acknowledgement that you are going to test it. The second issue, ASTERISK-16032 will likely get looked at in the next sprint session. Issue ASTERISK-14432 will get looked at as soon as time and resources allow. The last issue ASTERISK-15864 you have already acknowledged it works for you and will be looked at by a developer as soon as time and resources allow. You could also port that forward and apply it against the 1.6.2 branch. I'm guessing it would apply with only minor adjustments. However, for this issue in particular we are going to close this issue. Your inability to move to 1.6.2 still does not move us from the fact that 1.6.1 is only supported for security fixes, and that issues need to be able to reproduce on the 1.6.2 branch in order to move bugs forward. By: Private Name (falves11) 2010-05-19 09:43:13 Regarding 17248, it works. Regarding the rest of the patches, I paid a developer to write them and I will not pay again to rewrite them for 1.6.2. I am not a developer myself, and have no idea what to do. Kindly port them to 1.6.2 and once you publish them in each bug, as a new patch, I will move on happily. By: Leif Madsen (lmadsen) 2010-05-19 09:56:42 If you can get a community developer to port the patch then by all means do so but it is not our responsibility to do so. When/if it gets committed to trunk and then merged to 1.6.2 only then will it be modified if necessary. I imagine the patch will probably apply nearly cleanly to 1.6.2 directly, so the amount of work to fix it would be trivial. I am not a developer either, but applying a patch and fixing any spots where it might not apply cleanly is not that difficult. By: Leif Madsen (lmadsen) 2010-05-19 10:00:20 Now for this issue in particular, here is some information from IRC: <putnopvut> leifmadsen: yikes @ that crash. It's a weirdo memory corruption issue so it's not easy to determine if it's still present in 1.6.2 or not. I would be safe and assume it is a problem there, though. <leifmadsen> ok sounds good -- what other information should I request from him? <putnopvut> leifmadsen: sorry, missed your question earlier. valgrind would be cool if he's willing. <leifmadsen> is the backtrace useful enough on its own? <leifmadsen> if valgrind information is necessary though, that might be more difficult to debug then <putnopvut> leifmadsen: well, valgrind would be ideal. Otherwise, the way that it would have to be done is to comb through chan_sip and try to figure out possible ways that a bad dialog could get into the dialog container. <putnopvut> And honestly, I think that's close to impossible. So to summarize, valgrind output is probably necessary to move this issue forward. By: Private Name (falves11) 2010-05-19 10:01:41 Community developers do not exist for free. The only way I can get a problem fixed is if I pay a guy in Italy who can spot the bugs by simply reading the trace, something that apparently nobody else can do here in the US, not even in Digium. By: Private Name (falves11) 2010-05-19 10:06:32 Valgrind is 100% useless because I have a codec loaded, g729, based on the Intel libraries, and Valgrind ignores all the SSE multimedia instructions, so it fails. I reported the issue years ago to the Valgrind developers and they never fix it. I don't think they ever will. By: Paul Belanger (pabelanger) 2010-06-01 13:37:20 If Valgrind fails because of your codec, you'll have to unload your codec and attempt to reproduce the issue with Valgrind running.  Aside from that, there is not much else we can do. By: Leif Madsen (lmadsen) 2010-06-03 11:50:48 Closing this issue as valgrind output is required and the reporter is unable to provide it. Also, the issue in 15464 has been assigned to a developer, so if you still have this issue AFTER you update to 1.6.2, then you may open a new issue.