Bug#466729: asterisk: terminate called ...

[Ron]

On Sun, Mar 16, 2008 at 07:18:24PM -0400, Eloy Paris wrote:
> On Mon, Mar 17, 2008 at 05:30:36AM +1030, Ron wrote:
> 
> > We're going to need a bit more information about what is 'unique'
> > about your system, and/or what you are really seeing when this fails
> > if we are to figure out what is going on. Nobody else seems to be able
> > to reproduce this with the current code, and from everything you've
> > told us so far, neither should you. Even without the latest patch...
> 
> Sorry, I wasn't aware that nobody else had seen this problem; that's
> why I didn't investigate further, and especially because the workaround
> "noload => chan_vpb.so" made things work for me.

It looks like you are having a slightly different problem to the
original report, but with the same channel driver and its autodetection.

> Before I provide this information you've requested please allow me to
> share what I've found. If after going through this you still think the
> information you requested is needed I'll be happy to provide it.

I think I have enough clues from this now to guess what has happened...

Could you please run /usr/sbin/vpbscan and attach its output.
That should confirm my suspicions, and perhaps help with crafting a
more complete fix.

> Now, I have no idea where /etc/vpb came comes from, and I have even less
> idea how "cards" was set to 1 in /etc/vpb/vtcore.conf. There are two
> files in /etc/vpb, vtcore.conf and vpb.conf. Both had a timestamp of
> 2007-12-07. I certainly didn't mess with these files because I don't
> have a VPB card.

These would have been created by the postinst when libvpb was installed.
I suspect it's mistakenly adopted your X100P clone.

Sadly a number of telephony cards are in circulation that all use the
same PCI interface chip and don't override its PCI id.  vpbscan doesn't
appear to be accounting for that properly when deciding what cards are
present in the system.

> I just moved it out of the way and asterisk started fine.

If you leave the /etc/vpb dir, but remove its contents, then nothing
will mess with it again in future.  If you remove it entirely though,
then a future update of libvpb will probably re-create it again ...

They aren't conffiles because they are generated from the (supposed)
hardware detected on the system.  In this case it supposed wrong.

But we should be able to fix it so you won't have to mess with it
in future now that we have an idea about what's still going wrong.

> Thanks for the willigness to help me, and for being involved in
> maintenance of these important VoIP packages. My apologies for the
> noise.

No apologies needed, thanks for the excellent followup triage !

> P.S. If the exit() was happening from within libvpb I think it'd be much
> better for libvpb to return an error code to the caller.

This confused me too, I'd have expected it to trap on an exception
and just not load the module...  but I see that indeed there is still
some code in libvpb that dates back to the days when assert() and exit()
were the cool things to do when C code ran amok in 'unrecoverable' ways.

This one is much easier to fix than the vpbscan problem.  And with this
fixed, the mistake of vpbscan will be caught and corrected automatically.
Which is what we thought we'd done with the last patch...  ;)

You win the corner case prize !
Your fixed .debs will be on the wire shortly ...

Best,
Ron