| Summary: | ASTERISK-08075: Asterisk crash when PRI fails | ||
| Reporter: | Mitch Sharp (bluecrow76) | Labels: | |
| Date Opened: | 2006-11-06 20:11:57.000-0600 | Date Closed: | 2006-11-22 13:12:30.000-0600 |
| Priority: | Critical | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_zap |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | We have had a problem at a certain client's lately with their PRI. It has been accompanied by asterisk crashing. Today a Bellsouth line tech found a bad mux down the road from the client's building (his words). He said he was surprised that we had enough signal to actually receive any calls. The system has only crashed twice and the bt of both cores was the same: (gdb) bt #0 0x0000002a97444812 in pri_dchannel (vpri=Variable "vpri" is not available.) at chan_zap.c:8302 #1 0x00000036b0f0610a in start_thread () from /lib64/tls/libpthread.so.0 #2 0x00000036afec68b3 in clone () from /lib64/tls/libc.so.6 #3 0x0000000000000000 in ?? () (gdb) bt full #0 0x0000002a97444812 in pri_dchannel (vpri=Variable "vpri" is not available.) at chan_zap.c:8302 law = 1 pri = (struct zt_pri *) 0x2a97559040 e = Variable "e" is not available. This was running zaptel-1.2.10, libpri-1.2.4, and asterisk-1.2.13. It also occured running zaptel-1.2.9.1, libpri-1.2.3, and asterisk-1.2.12.1. I will report back if the system crashes again after today's line fix. | ||
| Comments: | By: Mitch Sharp (bluecrow76) 2006-11-06 20:14:36.000-0600 Sorry... just noticed this was posted under Chan_agent... needs to be under chan_zap... By: Matthew Fredrickson (mattf) 2006-11-10 16:40:39.000-0600 Can you reproduce this on a build of asterisk with optimizations disabled? (Run a make clean on your source directory, and build it with `make dont-optimize`) By: Matthew Fredrickson (mattf) 2006-11-16 13:57:13.000-0600 Ping..... By: Mitch Sharp (bluecrow76) 2006-11-16 14:05:54.000-0600 The system is a production system. It happened once on Oct 30 and once the first week of Nov. I believe it was the 6th when Bellsouth fixed the mux down the street. Since then it has not failed again. What should I do to help? Should I recompile with dont-optimize or should I leave it be and just report back if it happens again? By: Matthew Fredrickson (mattf) 2006-11-16 14:11:00.000-0600 Recompile without optimizations. If it happens again, and you need to report it again, you will need to have it compiled without optimizations anyways. By: Matthew Fredrickson (mattf) 2006-11-22 13:12:29.000-0600 Closed until someone can reproduce it. | ||