Summary:ASTERISK-13319: Asterisk 1.6 restarts after completion of incoming fax
Reporter:Ian Spice (ian)Labels:
Date Opened:2009-01-07 13:34:10.000-0600Date Closed:2009-01-22 15:15:21.000-0600
Versions:Frequency of

My configuration is as follows. I have an asterisk 1.4 server that interfaces with a POTS network. Our fax calls come into this server on an analog card. The extension is then passed onto a second server running 1.6 which is dedicated for faxes. here is the extensions.conf

exten => _22X,1,Wait(2)
exten => _22X,n,Set(FAXFILE=/var/fax/${UNIQUEID}.tif)
exten => _22X,n,Answer()
exten => _22X,1,Wait(3)
exten => _22X,n,ReceiveFax(${FAXFILE})
exten => _22X,1,Hangup()

The fax is saved in the correct directory. However, after the save asterisk restarts with a code 127

the only error that shows up is:

symbol lookup error /var/lib/asterisk/modules/app_fax.so undefined symbol T30_get_tx_ident

A fresh reinstall of everything did not fix the problem.

When it was first installed everything work great. When I stress tested with 8 incoming faxes simultaneously this problem popped up and never went away.


Comments:By: snuffy (snuffy) 2009-01-08 16:23:56.000-0600

Please post a backtrace of the fault (if it generates one)

Follow guidelines in doc/backtrace.txt on how to get a backtrace.

By: Leif Madsen (lmadsen) 2009-01-20 14:43:56.000-0600

Just pinging this issue again to see if the reporter can provide the information requested?  Thanks!

By: Scott Grim (sgrim) 2009-01-20 18:02:42.000-0600

I am having this identical problem.  There is no backtrace to provide because asterisk doesn't actually crash, it simply exits with a 127 and doesn't leave a core.

I am receiving the fax via SIP rather than POTS lines like the original reporter.

I'm installed on OpenSUSE 11.0 from asterisk16-1.6.0-33.26.x86_64.rpm with libspandsp1-0.0.5pre4-61.2

By: Ian Spice (ian) 2009-01-21 09:10:18.000-0600

here is what I found. The variables in app_fax.c

local_ident = T30_get_tx_ident(f)
far_ident = T30_get_rx_ident(f)

these values hold no value. The code will compile but asterisk will end with a code 127 and restart after the completion of any incoming fax.

local_ident = NULL
far_ident = NULL

'seems' to have fixed the problem, recompile and reinstall asterisk for the fix to take effect. I will be stress testing this configuration and I will let you guys know how it goes.


By: Joshua C. Colp (jcolp) 2009-01-21 17:47:51.000-0600

Code 127 is a symbol resolution error. It means that T30_get_tx_ident and T30_get_rx_ident could not be found in the spandsp library. The concerning thing is that the code obviously compiled so they were declared but were not actually found in the library... have either of you been playing with different spandsp versions? upgraded?

By: Ian Spice (ian) 2009-01-21 18:34:01.000-0600

I tried using different versions of SpanDSP however the SpanDSP-0.0.5pre4 and SpanDSP-0.0.5pre3 yeilded the same result. I will look through those versions and locate these symbols. I could try to find an older version and let you know how it goes.


By: Joshua C. Colp (jcolp) 2009-01-21 18:39:12.000-0600

I meant did you previously have this working fine and then upgraded spandsp?

By: Joshua C. Colp (jcolp) 2009-01-21 18:40:19.000-0600

A further thought: Can you please provide "ldd /usr/lib/asterisk/modules/app_fax.so" output and confirm it is using the right library?

By: Ian Spice (ian) 2009-01-21 19:01:03.000-0600

These were the only versions that I was able to compile and use. I will try and copy that information over tomorrow.

Thanks for all the help,

By: Scott Grim (sgrim) 2009-01-21 20:55:59.000-0600

I removed all traces of asterisk and libspandsp1 from my test system and reinstalled fresh from http://download.opensuse.org/repositories/network:/telephony/openSUSE_11.0/x86_64/ to make sure I had a clean install with binaries which presumably were all built against each other.

Same results.  Note these RPMs were built 1/16/2009 and 1/22/2009.

As a test, I compiled asterisk-, asterisk-addons- and spandsp-0.0.5pre4 (dated Jun 16, 2008) and this problem went away.  However, the installation had it's own issues such as "dialplan reload" causing a segmentation fault in ast_hashtab_start_traversal that seems to be a pthreads issue during a locking call.  Although it could be a config file incompatibility somewhere.

By: Joshua C. Colp (jcolp) 2009-01-22 08:32:24.000-0600

I'm afraid I don't see anything we can do with this specific issue... it seems to be an issue with the packaging.

By: Leif Madsen (lmadsen) 2009-01-22 15:15:20.000-0600

Closed due to file's comment that this is a packaging issue.