> On 11/19/05, I <[EMAIL PROTECTED]> wrote: > > I just upgraded to 1.2.0 on FreeBSD, and get a segfault when > running the Milliwatt application from a SIP phone. > > So far this seems to only be with SIP devices (an IAX call > from another PBX to the same extension with Milliwatt worked > fine).
Kim Culhan replied: > > Running CVS HEAD from ~1500 UTC 11-19-05 > From a Digium TDM400 FXS port it works with just a slight > glitch in the tone every few seconds. > From a sip phone it causes asterisk to stop with this on the console: > Disconnected from Asterisk server Yes, this is the trouble. You're probably running a slave console (-r) to the master Asterisk process. If you use -c, you should see that the main Asterisk process segfaults and potientially dumps core. I ran Asterisk (-c) with gdb so that I could get a good backtrace to see where the trouble was happening before the segfault (seems to be the only good way when you're running threads). I did try this on a Linux system (Debian) last night and didn't have that trouble, so it's definitely something that FreeBSD doesn't like. That could be a bug in Asterisk that FreeBSD is more prone to than Linux, or that something in Asterisk needs to be #ifdef'd for FreeBSD and we just don't know what it is yet. The problem you mentioned (TDM400 FXS with slight glitch) I also experienced several months ago in the 1.0 train on FreeBSD 5.4. It appears to be related to network interrupts (or just interrupts in general) because the problem became much less frequent when I had the network connection unplugged. I'm not terribly experienced with kernel hacking, so I didn't feel qualified to start trying to hunt that one down. I suspect that problem is more likely to be in the FreeBSD port of the Zaptel drivers and not Asterisk 1.2.0. > It is possible to restart asterisk which then appears to run fine. Yeah I know this, but having a process segfault like that doesn't give me confidence in the software. If I were to guess what's happening in this case, it is likely that some boundary condition is not being checked properly and it could very likely be the case that something is scribbling all over the stack and coincidentally it isn't a fatal crash in Linux. I was helping to hunt down some bizarre timestamp problems (the timestamps were incorrectly huge) in IAX from a 1.0.10 PBX that was causing 1.2.0 to crash, both on FreeBSD and on Linux. Some of the Asterisk source code scares me to death. If you want to see what I mean, take a look at milliwatt_generate() in app_milliwatt.c. There's a variable called "waste" that is expected to either align "buf" on some boundary, or just pre-pad "buf" in case there's a negative array index. In either case, that kind of coding should never be necessary, and is definitely non-portable. I've seen examples of this in several places in Asterisk. The only thing that keeps me running Asterisk is that I'm sure this is the case in commercial software as well, we just don't have the ability to see it in the source code. Thanks for the update! --- Gil Kloepfer [EMAIL PROTECTED] _______________________________________________ Asterisk-BSD mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-bsd
