Re: [asterisk-dev] res_fax_spandsp segfaults during fax detection - FIXED?

[Jaco Kroon]

Hi All, Could this backtrace possibly be related? #0  process_rx_data (t=0x7fae54c698a8, user_data=0x2, data_type=1, field_type=<optimized out>, buf=0x7fae11c58cda "cng", len=0) at t38_terminal.c:314 #1  0x00007fae11c22c7d in t38_core_rx_ifp_packet (s=0x7fae54c698a8, buf=0x7fae54c8475b "\002", len=1, seq_no=<optimized out>) at t38_core.c:459 #2  0x00007fae50ea96c5 in generic_fax_exec (chan=chan@entry=0x7fadc4548c18, details=details@entry=0x7fad50602c28, reserved=reserved@entry=0x7fad50155478, token=<optimized out>) at res_fax.c:1498 #3  0x00007fae50eaea9e in receivefax_exec (chan=0x7fadc4548c18, data="" out>) at res_fax.c:1932 #4  0x0000000000530fdd in pbx_exec (c=c@entry=0x7fadc4548c18, app=app@entry=0x2ddca60, data="" "/tmp/morpheus-1391681512.850.tiff") at pbx.c:1622 #5  0x000000000053656f in pbx_extension_helper (c=c@entry=0x7fadc4548c18, context=<optimized out>, exten=exten@entry=0x7fadc4549ab8 "0123489251", priority=priority@entry=6, label=label@entry=0x0, callerid=callerid@entry=0x7fadc44757b0 "0126413300", action="" found=found@entry=0x7fad838bad60,     combined_find_spawn=combined_find_spawn@entry=1, con=0x0) at pbx.c:4922 #6  0x00000000005404a4 in ast_spawn_extension (found=0x7fad838bad60, callerid=0x7fadc44757b0 "0126413300", priority=6, exten=0x7fadc4549ab8 "0123489251", context=<optimized out>, c=0x7fadc4548c18, combined_find_spawn=<optimized out>) at pbx.c:6038 #7  __ast_pbx_run (c=c@entry=0x7fadc4548c18, args=args@entry=0x0) at pbx.c:6513 #8  0x0000000000541c0b in pbx_thread (data="" at pbx.c:6843 #9  0x0000000000587c5a in dummy_start (data="" out>) at utils.c:1162 #10 0x00007fae530f2f3a in start_thread (arg=0x7fad838bb700) at pthread_create.c:308 #11 0x00007fae54754dad in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Had about 11 of those this morning on asterisk 11.7.0.  Codec's that's allowed on SIP though is g729 and gsm only, so no ulaw/alaw allowed.  Actually, just double checked, ulaw/alaw is (was now) allowed, so someone is possibly trying to run in bypass mode, resulting in the t38 gateway instead of t38 pass through.  I downgraded to 11.6.0 and hadn't had a crash since but I opted to disable ulaw+alaw in any case, just to be on the safer side. Kind Regards, Jaco Kroon On 01/02/2014 06:49, Michal Rybárik wrote: Hello Pavel, On 01/31/2014 07:59 AM, Pavel Troller wrote: This code will translate non-slinear frames to slinear, just before they are sent to libspandsp for v21detection. With this patch applied, v21 detection is done also for RTP (SIP) alaw/ulaw frames, so maybe SIP/G711 <->  SIP/T38 gateway will work too. I tested DAHDI<->  SIP/T38, gateway works both ways, voice calls too. Is it better now? :o) I fully understand the code, but I'm not trained enough in the Asterisk internals to respond to questions, which immediately appeared in my head: 1) In the original code, the result from fax_gateway_detect_v21() is returned. Now, you are returning the original frame. I quickly looked at the above routine and it in turn calls fax_gateway_request_t38() and returns its result (but not always), and in the fax_gateway_request_t38() function they are also returning different things according to results of the program flow. So, is it really safe to do this ? Are you sure, that the real result is really unneccessary ? 2) Are you sure, that ast_translate() will always allocate a new buffer for tmpframe ? Is it written somewhere ? Isn't it possible that it will just reallocate the buffer for the original frame to increase its size and return its pointer, so by doing ast_frfree() you would just deallocate the same buffer, thus making big troubles ? You would find it by checking that tmpframe != f...    As you can see, I'm very careful, or maybe even a bit conservative, with patching things, unless I really DEEPLY understand, how they are going... So, I believe, that you really studied the code enough to be sure, that you can really clear my doubts by your deep knowledge... I didn't have time to study the code to such extent... Answering these questions is not easy for me too, there are some parts of res_fax code which I don't fully understand. So I rather reworked the patch and moved it to another place, where functionality is easier to understand, and when it shouldn't harm anything. I uploaded diff to JIRA  - https://issues.asterisk.org/jira/browse/ASTERISK-20149 Regards, Michal Rybarik

<<attachment: jaco.vcf>>

-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev