Bug#391840: marked as done (ztcfg segfaults because of -O4)
rmh at aybabtu.com
Tue Oct 10 14:07:52 UTC 2006
On Tue, Oct 10, 2006 at 01:30:39PM +0200, Tzafrir Cohen wrote:
> Is the problem fixed?
No, that didn't do it. exporting CFLAGS from debian/rules doesn't help, because
-O4 is appended after -fno-inline-functions, overriding its behaviour. You
really need to patch the Makefile.
Besides, after reporting the bug I found the same problem (segfault at same
place, with same stack layout) can still be reproduced with other commands
(ztcfg -d 99), even with -O2. -O0 seems to solve that, but I'll try to nail it
down to the culprit flag (that'll be later, I'm busy atm).
> Is it indeed a reproducable problem?
See if you can reproduce it. My zaptel.conf is the same as default, plus this
line at the end:
I'm running on amd64.
> > diff -ur zaptel-184.108.40.206.dfsg.old/ztcfg.c zaptel-220.127.116.11.dfsg/ztcfg.c
> > --- zaptel-18.104.22.168.dfsg.old/ztcfg.c 2006-02-01 03:33:54.000000000 +0100
> > +++ zaptel-22.214.171.124.dfsg/ztcfg.c 2006-10-08 21:22:27.000000000 +0200
> > @@ -929,6 +929,8 @@
> > if (ind_ioctl(x,fd,ZT_RADIO_GETPARAM,&p) == -1)
> > error("Cannot get number of tones for channel %d\n",x);
> > n = p.data;
> > + if (n > NUM_TONES)
> > + error("Too many tones for channel %d: %d\n",x,n);
> > p.radpar = ZT_RADPAR_INITTONE;
> > if (ind_ioctl(x,fd,ZT_RADIO_SETPARAM,&p) == -1)
> > error("Cannot init tones for channel %d\n",x);
Too bad this doesn't seem to detect anything :(. I suspect the code has been
messed up^W^Woptimised by gcc in a way that the stack becomes broken, and hence
the backtrace output is not reliable. Not sure though, I get pretty confused
when it comes to these things.
My spam trap is honeypot at aybabtu.com. Note: this address is only intended for
spam harvesters. Writing to it will get you added to my black list.
More information about the Pkg-voip-maintainers