Re: Bug#86356: analog: analog segfaults

Re: Bug#86356: analog: analog segfaults

[Stephen Turner]

Thanks for your help with this, Kevin (I'm the upstream author).

> To see if it is indeed a parameter passing issue, I need to know what the
> types are for each parameter passed below (specifically if any are long
> long int or float or double types and what the return type is of that
> function so that I can tell is any structures are returned.
>

The definition:

typedef unsigned char logical;
typedef signed char choice;
/* and Strlist, Alias, Include are typedefs to structs */
void printtree(FILE *outf, choice rep, choice outstyle, logical multibyte,
       Hashtable *tree, choice requests, choice date, Hashentry *badp,
       unsigned long badn, unsigned int level, Strlist *partname,
       Alias *aliashead, Include *linkhead, char *baseurl,
       unsigned long totr, unsigned long totp, double totb,
       unsigned int width[], logical possrightalign,
       unsigned int bmult, double unit, char sepchar, char repsepchar,
       char decpt, char *compsep, logical rawbytes, choice *cols,
       char *colhead, char *colheadp, char gender, logical *html,
       char **monthname, char **dayname, unsigned int monthlen,
       unsigned int daylen, unsigned int plainmonthlen,
       unsigned int plaindaylen, char **lngstr) {

The call:

printtree(outf, rep, outstyle, multibyte, tree, requests, date, badp, badn,
    0, NULL, aliashead, linkhead, baseurl, totr, totp, totb, width,
    possrightalign, bmult, unit, sepchar, repsepchar, decpt, compsep,
    rawbytes, cols, colhead, colheadp, gender, html, monthname,
    dayname, monthlen, daylen, plainmonthlen, plaindaylen, lngstr);

I've double-checked that all arguments in the call have the correct types.

However, notice that printtree() has 38 arguments. The C standard (Section
5.2.4.1) only requires implementations to accept 31 arguments. Does gcc have
this limit?

> Another (easier solution) is to modify each routine to print the values of
> all parameters just before the call and just inside the called routine.

I've done this. fprintf'ing the values of all the parameters immediately
before the call and immediately on entry to the function gives:

BEFORE:
0x100f3f48 9 0 0 0x1007f550 0 4 0xffe859c
268919984 0 (nil) (nil) 0x100e8498 (nil)
1 0 88140.000000 0x7ffff8f8 0 0
1.000000 44 0 46 0x1007e498 0 0x100654de
0x100e9eb8 0x100e9ec8 n 0x1006543f 0x1006592c 0x10065910
3 3 3 3 0x100e98b0

AFTER:
0x100f3f48 9 0 0 0x1007f550 0 4 0xffe859c
268919984 0 (nil) (nil) 0x100e8498 (nil)
1 0 88140.000000 0x7ffff8f8 0 0
1.000000 0 46 152 (nil) 222 0x100e9eb8
0x100e9ec8 0x6e ? 0x1006592c 0x10065910 0x3
3 3 3 269392048 0x100f3f48
Segmentation fault

Notice how the second half of the arguments appear to have been shifted up
one. Compare with the same code on an i386/potato machine:

BEFORE:
0x8115a80 9 0 0 0x80a1260 0 4 0x80980b0
1 0 (nil) (nil) 0x8109fc8 (nil)
1 0 88140.000000 0xbffff884 0 1
1.000000 44 0 46 0x80a01a8 0 0x808711e
0x810b9f0 0x810ba00 n 0x808707f 0x80874b0 0x8087494
3 3 3 3 0x810b318

AFTER:
0x8115a80 9 0 0 0x80a1260 0 4 0x80980b0
1 0 (nil) (nil) 0x8109fc8 (nil)
1 0 88140.000000 0xbffff884 0 1
1.000000 44 0 46 0x80a01a8 0 0x808711e
0x810b9f0 0x810ba00 n 0x808707f 0x80874b0 0x8087494
3 3 3 3 0x810b318

Thanks again,

--
Stephen Turner               http://www.statslab.cam.ac.uk/~sret1/
  Statistical Laboratory, Wilberforce Road, Cambridge, CB3 0WB, England
  "Your account can only be used for a single internet session at any one
   time and for no more than 24 hours in any one day." (NTL terms of use)


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Bug#86356: analog: analog segfaults

[Kevin B. Hendricks]

Hi,

I think the second double value is confusing the compiler into skipping a
stack slot when it really shouldn't be doing that at all!!!!!

This is wierd.

Here is a quick and dirty way to test.  Move both double parameters to the
beginning of the function and caller and the problem should go away.

Another solution is to include a "dummy" int variable in both the caller
and the function right before the double parameter "unit".  That dummy will
fill a stack slot and force any messed up double alignment issue to become
moot.

If either of those workarounds work, then please pass all of this info to
Franz Sirl's attention on the gcc@gcc.gnu.org site and he can use it to
track down the messed up code. It the workarounds fix things, this is a
definite bug

Okay, here is what should be where:

gpr registers
r3   outf
r4   rep
r5   outstyle
r6   multibyte
r7   tree
r8   requests
r9   date
r10  badp


floating point registers
f1  totb
f2  unit
f3
f4
f5
f6
f7
f8


overflow stack (starts aligned to 8 at the previous frame pointer + 8
offset  0: badn
offset  4: level
offset  8: partname
offset  c: aliashead
offset 10: linkhead
offset 14: baseurl
offset 18: totr
offset 1c: totp
offset 20: width
offset 24: possrightalign
offset 28: bmult
 <================== (if passed on the stack the double would have
                      been here but there were enough floating point
                      registers so it should not be on the stack.)
                      (However, if it was on the stack, the compiler should
                       have skipped a stack slot since doubles must be
                       passed aligned to 8)
offset 2c: sepchar
offset 30: rsepchar
offset 34: decpt
offset 38: compsep
offset 3c: rawbytes
offset 40: cols
offset 44: colhead
offset 48: colheadp
offset 4c: gender
offset 50: html
offset 54: monthname
offset 58: dayname
offset 5c: monthlen
offset 60: daylen
offset 64: plainmonthend
offset 68: plaindaylen
offset 6c: lngstr



Please let me know if the workaround  "fixes" things.  We will then have a
bug.

Thanks,

Kevin

On Friday 23 February 2001 15:46, Stephen Turner wrote:
> Thanks for your help with this, Kevin (I'm the upstream author).
>
> > To see if it is indeed a parameter passing issue, I need to know what the
> > types are for each parameter passed below (specifically if any are long
> > long int or float or double types and what the return type is of that
> > function so that I can tell is any structures are returned.
> >
>
> The definition:
>
> typedef unsigned char logical;
> typedef signed char choice;
> /* and Strlist, Alias, Include are typedefs to structs */
> void printtree(FILE *outf, choice rep, choice outstyle, logical multibyte,
>        Hashtable *tree, choice requests, choice date, Hashentry *badp,
>        unsigned long badn, unsigned int level, Strlist *partname,
>        Alias *aliashead, Include *linkhead, char *baseurl,
>        unsigned long totr, unsigned long totp, double totb,
>        unsigned int width[], logical possrightalign,
>        unsigned int bmult, double unit, char sepchar, char repsepchar,
>        char decpt, char *compsep, logical rawbytes, choice *cols,
>        char *colhead, char *colheadp, char gender, logical *html,
>        char **monthname, char **dayname, unsigned int monthlen,
>        unsigned int daylen, unsigned int plainmonthlen,
>        unsigned int plaindaylen, char **lngstr) {
>
> The call:
>
> printtree(outf, rep, outstyle, multibyte, tree, requests, date, badp, badn,
>     0, NULL, aliashead, linkhead, baseurl, totr, totp, totb, width,
>     possrightalign, bmult, unit, sepchar, repsepchar, decpt, compsep,
>     rawbytes, cols, colhead, colheadp, gender, html, monthname,
>     dayname, monthlen, daylen, plainmonthlen, plaindaylen, lngstr);
>
> I've double-checked that all arguments in the call have the correct types.
>
> However, notice that printtree() has 38 arguments. The C standard (Section
> 5.2.4.1) only requires implementations to accept 31 arguments. Does gcc have
> this limit?
>
> > Another (easier solution) is to modify each routine to print the values
of
> > all parameters just before the call and just inside the called routine.
>
> I've done this. fprintf'ing the values of all the parameters immediately
> before the call and immediately on entry to the function gives:
>
> BEFORE:
> 0x100f3f48 9 0 0 0x1007f550 0 4 0xffe859c
> 268919984 0 (nil) (nil) 0x100e8498 (nil)
> 1 0 88140.000000 0x7ffff8f8 0 0
> 1.000000 44 0 46 0x1007e498 0 0x100654de
> 0x100e9eb8 0x100e9ec8 n 0x1006543f 0x1006592c 0x10065910
> 3 3 3 3 0x100e98b0
>
> AFTER:
> 0x100f3f48 9 0 0 0x1007f550 0 4 0xffe859c
> 268919984 0 (nil) (nil) 0x100e8498 (nil)
> 1 0 88140.000000 0x7ffff8f8 0 0
> 1.000000 0 46 152 (nil) 222 0x100e9eb8
> 0x100e9ec8 0x6e ? 0x1006592c 0x10065910 0x3
> 3 3 3 269392048 0x100f3f48
> Segmentation fault
>
> Notice how the second half of the arguments appear to have been shifted up
> one. Compare with the same code on an i386/potato machine:
>
> BEFORE:
> 0x8115a80 9 0 0 0x80a1260 0 4 0x80980b0
> 1 0 (nil) (nil) 0x8109fc8 (nil)
> 1 0 88140.000000 0xbffff884 0 1
> 1.000000 44 0 46 0x80a01a8 0 0x808711e
> 0x810b9f0 0x810ba00 n 0x808707f 0x80874b0 0x8087494
> 3 3 3 3 0x810b318
>
> AFTER:
> 0x8115a80 9 0 0 0x80a1260 0 4 0x80980b0
> 1 0 (nil) (nil) 0x8109fc8 (nil)
> 1 0 88140.000000 0xbffff884 0 1
> 1.000000 44 0 46 0x80a01a8 0 0x808711e
> 0x810b9f0 0x810ba00 n 0x808707f 0x80874b0 0x8087494
> 3 3 3 3 0x810b318
>
> Thanks again,
>
> --
> Stephen Turner               http://www.statslab.cam.ac.uk/~sret1/
>   Statistical Laboratory, Wilberforce Road, Cambridge, CB3 0WB, England
>   "Your account can only be used for a single internet session at any one
>    time and for no more than 24 hours in any one day." (NTL terms of use)

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Bug#86356: analog: analog segfaults

[Stephen Turner]

On Fri, 23 Feb 2001, Kevin B. Hendricks wrote:
>
> Here is a quick and dirty way to test.  Move both double parameters to the
> beginning of the function and caller and the problem should go away.
>
> Another solution is to include a "dummy" int variable in both the caller
> and the function right before the double parameter "unit".  That dummy will
> fill a stack slot and force any messed up double alignment issue to become
> moot.
>

The second fix got it past the call to printtree(). Then it crashed when
calling another function, printcols(), which I fixed with the first fix.
This allowed it to run without crashing, but the resultant output was
obviously wrong, with what could have been a related bug.

Anyway, I think this proves that your hypothesis was correct.

> If either of those workarounds work, then please pass all of this info to
> Franz Sirl's attention on the gcc@gcc.gnu.org site and he can use it to
> track down the messed up code. It the workarounds fix things, this is a
> definite bug
>

You said these were mostly fixed in the 2.95.3 series. The original bug
filer is using 2.95.2. Should I still file a bug? Or has someone got a
nightly build or something that they could test it on first, in case it's
already been fixed?

--
Stephen Turner               http://www.statslab.cam.ac.uk/~sret1/
  Statistical Laboratory, Wilberforce Road, Cambridge, CB3 0WB, England
  "Your account can only be used for a single internet session at any one
   time and for no more than 24 hours in any one day." (NTL terms of use)


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Bug#86356: analog: analog segfaults

[Kevin B. Hendricks]

Hi,

I have a working gcc HEAD build from about 2 weeks ago.  If you send me some
standalone test code, I would be happy to test it.

I also have 2.95.3 too and will test with both.

Just create a main with a call to printtrace and have printtrace print all
the values and just return and I will test it for you.

Take care,

Kevin

On Friday 23 February 2001 16:59, Stephen Turner wrote:
> On Fri, 23 Feb 2001, Kevin B. Hendricks wrote:
> >
> > Here is a quick and dirty way to test.  Move both double parameters to
the
> > beginning of the function and caller and the problem should go away.
> >
> > Another solution is to include a "dummy" int variable in both the caller
> > and the function right before the double parameter "unit".  That dummy
will
> > fill a stack slot and force any messed up double alignment issue to become
> > moot.
> >
>
> The second fix got it past the call to printtree(). Then it crashed when
> calling another function, printcols(), which I fixed with the first fix.
> This allowed it to run without crashing, but the resultant output was
> obviously wrong, with what could have been a related bug.
>
> Anyway, I think this proves that your hypothesis was correct.
>
> > If either of those workarounds work, then please pass all of this info to
> > Franz Sirl's attention on the gcc@gcc.gnu.org site and he can use it to
> > track down the messed up code. It the workarounds fix things, this is a
> > definite bug
> >
>
> You said these were mostly fixed in the 2.95.3 series. The original bug
> filer is using 2.95.2. Should I still file a bug? Or has someone got a
> nightly build or something that they could test it on first, in case it's
> already been fixed?
>
> --
> Stephen Turner               http://www.statslab.cam.ac.uk/~sret1/
>   Statistical Laboratory, Wilberforce Road, Cambridge, CB3 0WB, England
>   "Your account can only be used for a single internet session at any one
>    time and for no more than 24 hours in any one day." (NTL terms of use)

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Bug#86356: analog: analog segfaults

[Andrew Sharp]

One look at that interface to printtree is all that is needed to see
where the real problem is.  Whoever wrote this code is badly in need
of a long and meaningful "timeout" with _The Elements of Programming
Style_ by Kernighan & Plauger.  KISS.  Geez, build a structure and
pass the pointer, rather than the much slower [and apparently
bugier, and painful to read] method of trying to force the compiler
and arg passing code to deal with that mountain of ....

a

"Kevin B. Hendricks" wrote:
>
> Hi,
>
> I think the second double value is confusing the compiler into skipping a
> stack slot when it really shouldn't be doing that at all!!!!!
>
> This is wierd.
>
> Here is a quick and dirty way to test.  Move both double parameters to the
> beginning of the function and caller and the problem should go away.
>
> Another solution is to include a "dummy" int variable in both the caller
> and the function right before the double parameter "unit".  That dummy will
> fill a stack slot and force any messed up double alignment issue to become
> moot.
>
> If either of those workarounds work, then please pass all of this info to
> Franz Sirl's attention on the gcc@gcc.gnu.org site and he can use it to
> track down the messed up code. It the workarounds fix things, this is a
> definite bug
>
> Okay, here is what should be where:
>
> gpr registers
> r3   outf
> r4   rep
> r5   outstyle
> r6   multibyte
> r7   tree
> r8   requests
> r9   date
> r10  badp
>
> floating point registers
> f1  totb
> f2  unit
> f3
> f4
> f5
> f6
> f7
> f8
>
> overflow stack (starts aligned to 8 at the previous frame pointer + 8
> offset  0: badn
> offset  4: level
> offset  8: partname
> offset  c: aliashead
> offset 10: linkhead
> offset 14: baseurl
> offset 18: totr
> offset 1c: totp
> offset 20: width
> offset 24: possrightalign
> offset 28: bmult
>  <================== (if passed on the stack the double would have
>                       been here but there were enough floating point
>                       registers so it should not be on the stack.)
>                       (However, if it was on the stack, the compiler should
>                        have skipped a stack slot since doubles must be
>                        passed aligned to 8)
> offset 2c: sepchar
> offset 30: rsepchar
> offset 34: decpt
> offset 38: compsep
> offset 3c: rawbytes
> offset 40: cols
> offset 44: colhead
> offset 48: colheadp
> offset 4c: gender
> offset 50: html
> offset 54: monthname
> offset 58: dayname
> offset 5c: monthlen
> offset 60: daylen
> offset 64: plainmonthend
> offset 68: plaindaylen
> offset 6c: lngstr
>
> Please let me know if the workaround  "fixes" things.  We will then have a
> bug.
>
> Thanks,
>
> Kevin
>
> On Friday 23 February 2001 15:46, Stephen Turner wrote:
> > Thanks for your help with this, Kevin (I'm the upstream author).
> >
> > > To see if it is indeed a parameter passing issue, I need to know what the
> > > types are for each parameter passed below (specifically if any are long
> > > long int or float or double types and what the return type is of that
> > > function so that I can tell is any structures are returned.
> > >
> >
> > The definition:
> >
> > typedef unsigned char logical;
> > typedef signed char choice;
> > /* and Strlist, Alias, Include are typedefs to structs */
> > void printtree(FILE *outf, choice rep, choice outstyle, logical multibyte,
> >        Hashtable *tree, choice requests, choice date, Hashentry *badp,
> >        unsigned long badn, unsigned int level, Strlist *partname,
> >        Alias *aliashead, Include *linkhead, char *baseurl,
> >        unsigned long totr, unsigned long totp, double totb,
> >        unsigned int width[], logical possrightalign,
> >        unsigned int bmult, double unit, char sepchar, char repsepchar,
> >        char decpt, char *compsep, logical rawbytes, choice *cols,
> >        char *colhead, char *colheadp, char gender, logical *html,
> >        char **monthname, char **dayname, unsigned int monthlen,
> >        unsigned int daylen, unsigned int plainmonthlen,
> >        unsigned int plaindaylen, char **lngstr) {
> >
> > The call:
> >
> > printtree(outf, rep, outstyle, multibyte, tree, requests, date, badp, badn,
> >     0, NULL, aliashead, linkhead, baseurl, totr, totp, totb, width,
> >     possrightalign, bmult, unit, sepchar, repsepchar, decpt, compsep,
> >     rawbytes, cols, colhead, colheadp, gender, html, monthname,
> >     dayname, monthlen, daylen, plainmonthlen, plaindaylen, lngstr);
> >
> > I've double-checked that all arguments in the call have the correct types.
> >
> > However, notice that printtree() has 38 arguments. The C standard (Section
> > 5.2.4.1) only requires implementations to accept 31 arguments. Does gcc have
> > this limit?
> >
> > > Another (easier solution) is to modify each routine to print the values
> of
> > > all parameters just before the call and just inside the called routine.
> >
> > I've done this. fprintf'ing the values of all the parameters immediately
> > before the call and immediately on entry to the function gives:
> >
> > BEFORE:
> > 0x100f3f48 9 0 0 0x1007f550 0 4 0xffe859c
> > 268919984 0 (nil) (nil) 0x100e8498 (nil)
> > 1 0 88140.000000 0x7ffff8f8 0 0
> > 1.000000 44 0 46 0x1007e498 0 0x100654de
> > 0x100e9eb8 0x100e9ec8 n 0x1006543f 0x1006592c 0x10065910
> > 3 3 3 3 0x100e98b0
> >
> > AFTER:
> > 0x100f3f48 9 0 0 0x1007f550 0 4 0xffe859c
> > 268919984 0 (nil) (nil) 0x100e8498 (nil)
> > 1 0 88140.000000 0x7ffff8f8 0 0
> > 1.000000 0 46 152 (nil) 222 0x100e9eb8
> > 0x100e9ec8 0x6e ? 0x1006592c 0x10065910 0x3
> > 3 3 3 269392048 0x100f3f48
> > Segmentation fault
> >
> > Notice how the second half of the arguments appear to have been shifted up
> > one. Compare with the same code on an i386/potato machine:
> >
> > BEFORE:
> > 0x8115a80 9 0 0 0x80a1260 0 4 0x80980b0
> > 1 0 (nil) (nil) 0x8109fc8 (nil)
> > 1 0 88140.000000 0xbffff884 0 1
> > 1.000000 44 0 46 0x80a01a8 0 0x808711e
> > 0x810b9f0 0x810ba00 n 0x808707f 0x80874b0 0x8087494
> > 3 3 3 3 0x810b318
> >
> > AFTER:
> > 0x8115a80 9 0 0 0x80a1260 0 4 0x80980b0
> > 1 0 (nil) (nil) 0x8109fc8 (nil)
> > 1 0 88140.000000 0xbffff884 0 1
> > 1.000000 44 0 46 0x80a01a8 0 0x808711e
> > 0x810b9f0 0x810ba00 n 0x808707f 0x80874b0 0x8087494
> > 3 3 3 3 0x810b318

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Bug#86356: analog: analog segfaults

[Kevin B. Hendricks]

Hi,

Regardless of the interface or code, the compiler should be able to handle
this case properly.  I agree simpler is better but I am more interested in
making sure this bug is fixed in gcc if it hasn't already been.

 If not, I personally want to see it fixed since the code I wrote for
sys_invokeNative in the JDK and the openoffice bridges code and the Mozilla
code, and the libffi code, and ... are wrong and need to be changed since
they all follow the published abi.

Kevin

On Friday 23 February 2001 17:10, Andrew Sharp wrote:
> One look at that interface to printtree is all that is needed to see
> where the real problem is.  Whoever wrote this code is badly in need
> of a long and meaningful "timeout" with _The Elements of Programming
> Style_ by Kernighan & Plauger.  KISS.  Geez, build a structure and
> pass the pointer, rather than the much slower [and apparently
> bugier, and painful to read] method of trying to force the compiler
> and arg passing code to deal with that mountain of ....
>
> a
>
> "Kevin B. Hendricks" wrote:
> >
> > Hi,
> >
> > I think the second double value is confusing the compiler into skipping a
> > stack slot when it really shouldn't be doing that at all!!!!!
> >
> > This is wierd.
> >
> > Here is a quick and dirty way to test.  Move both double parameters to the
> > beginning of the function and caller and the problem should go away.
> >
> > Another solution is to include a "dummy" int variable in both the caller
> > and the function right before the double parameter "unit".  That dummy
will
> > fill a stack slot and force any messed up double alignment issue to become
> > moot.
> >
> > If either of those workarounds work, then please pass all of this info to
> > Franz Sirl's attention on the gcc@gcc.gnu.org site and he can use it to
> > track down the messed up code. It the workarounds fix things, this is a
> > definite bug
> >
> > Okay, here is what should be where:
> >
> > gpr registers
> > r3   outf
> > r4   rep
> > r5   outstyle
> > r6   multibyte
> > r7   tree
> > r8   requests
> > r9   date
> > r10  badp
> >
> > floating point registers
> > f1  totb
> > f2  unit
> > f3
> > f4
> > f5
> > f6
> > f7
> > f8
> >
> > overflow stack (starts aligned to 8 at the previous frame pointer + 8
> > offset  0: badn
> > offset  4: level
> > offset  8: partname
> > offset  c: aliashead
> > offset 10: linkhead
> > offset 14: baseurl
> > offset 18: totr
> > offset 1c: totp
> > offset 20: width
> > offset 24: possrightalign
> > offset 28: bmult
> >  <================== (if passed on the stack the double would have
> >                       been here but there were enough floating point
> >                       registers so it should not be on the stack.)
> >                       (However, if it was on the stack, the compiler
should
> >                        have skipped a stack slot since doubles must be
> >                        passed aligned to 8)
> > offset 2c: sepchar
> > offset 30: rsepchar
> > offset 34: decpt
> > offset 38: compsep
> > offset 3c: rawbytes
> > offset 40: cols
> > offset 44: colhead
> > offset 48: colheadp
> > offset 4c: gender
> > offset 50: html
> > offset 54: monthname
> > offset 58: dayname
> > offset 5c: monthlen
> > offset 60: daylen
> > offset 64: plainmonthend
> > offset 68: plaindaylen
> > offset 6c: lngstr
> >
> > Please let me know if the workaround  "fixes" things.  We will then have a
> > bug.
> >
> > Thanks,
> >
> > Kevin
> >
> > On Friday 23 February 2001 15:46, Stephen Turner wrote:
> > > Thanks for your help with this, Kevin (I'm the upstream author).
> > >
> > > > To see if it is indeed a parameter passing issue, I need to know what
the
> > > > types are for each parameter passed below (specifically if any are
long
> > > > long int or float or double types and what the return type is of that
> > > > function so that I can tell is any structures are returned.
> > > >
> > >
> > > The definition:
> > >
> > > typedef unsigned char logical;
> > > typedef signed char choice;
> > > /* and Strlist, Alias, Include are typedefs to structs */
> > > void printtree(FILE *outf, choice rep, choice outstyle, logical
multibyte,
> > >        Hashtable *tree, choice requests, choice date, Hashentry *badp,
> > >        unsigned long badn, unsigned int level, Strlist *partname,
> > >        Alias *aliashead, Include *linkhead, char *baseurl,
> > >        unsigned long totr, unsigned long totp, double totb,
> > >        unsigned int width[], logical possrightalign,
> > >        unsigned int bmult, double unit, char sepchar, char repsepchar,
> > >        char decpt, char *compsep, logical rawbytes, choice *cols,
> > >        char *colhead, char *colheadp, char gender, logical *html,
> > >        char **monthname, char **dayname, unsigned int monthlen,
> > >        unsigned int daylen, unsigned int plainmonthlen,
> > >        unsigned int plaindaylen, char **lngstr) {
> > >
> > > The call:
> > >
> > > printtree(outf, rep, outstyle, multibyte, tree, requests, date, badp,
badn,
> > >     0, NULL, aliashead, linkhead, baseurl, totr, totp, totb, width,
> > >     possrightalign, bmult, unit, sepchar, repsepchar, decpt, compsep,
> > >     rawbytes, cols, colhead, colheadp, gender, html, monthname,
> > >     dayname, monthlen, daylen, plainmonthlen, plaindaylen, lngstr);
> > >
> > > I've double-checked that all arguments in the call have the correct
types.
> > >
> > > However, notice that printtree() has 38 arguments. The C standard
(Section
> > > 5.2.4.1) only requires implementations to accept 31 arguments. Does gcc
have
> > > this limit?
> > >
> > > > Another (easier solution) is to modify each routine to print the
values
> > of
> > > > all parameters just before the call and just inside the called
routine.
> > >
> > > I've done this. fprintf'ing the values of all the parameters immediately
> > > before the call and immediately on entry to the function gives:
> > >
> > > BEFORE:
> > > 0x100f3f48 9 0 0 0x1007f550 0 4 0xffe859c
> > > 268919984 0 (nil) (nil) 0x100e8498 (nil)
> > > 1 0 88140.000000 0x7ffff8f8 0 0
> > > 1.000000 44 0 46 0x1007e498 0 0x100654de
> > > 0x100e9eb8 0x100e9ec8 n 0x1006543f 0x1006592c 0x10065910
> > > 3 3 3 3 0x100e98b0
> > >
> > > AFTER:
> > > 0x100f3f48 9 0 0 0x1007f550 0 4 0xffe859c
> > > 268919984 0 (nil) (nil) 0x100e8498 (nil)
> > > 1 0 88140.000000 0x7ffff8f8 0 0
> > > 1.000000 0 46 152 (nil) 222 0x100e9eb8
> > > 0x100e9ec8 0x6e ? 0x1006592c 0x10065910 0x3
> > > 3 3 3 269392048 0x100f3f48
> > > Segmentation fault
> > >
> > > Notice how the second half of the arguments appear to have been shifted
up
> > > one. Compare with the same code on an i386/potato machine:
> > >
> > > BEFORE:
> > > 0x8115a80 9 0 0 0x80a1260 0 4 0x80980b0
> > > 1 0 (nil) (nil) 0x8109fc8 (nil)
> > > 1 0 88140.000000 0xbffff884 0 1
> > > 1.000000 44 0 46 0x80a01a8 0 0x808711e
> > > 0x810b9f0 0x810ba00 n 0x808707f 0x80874b0 0x8087494
> > > 3 3 3 3 0x810b318
> > >
> > > AFTER:
> > > 0x8115a80 9 0 0 0x80a1260 0 4 0x80980b0
> > > 1 0 (nil) (nil) 0x8109fc8 (nil)
> > > 1 0 88140.000000 0xbffff884 0 1
> > > 1.000000 44 0 46 0x80a01a8 0 0x808711e
> > > 0x810b9f0 0x810ba00 n 0x808707f 0x80874b0 0x8087494
> > > 3 3 3 3 0x810b318

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Bug#86356: analog: analog segfaults

[Stephen Turner]

This turns out to be a bug in gcc, not analog. On ppc, gcc 2.95.2 seems to
have alignment problems when a function is passed certain long lists of
arguments including doubles. But apparently the bug is fixed in the (not yet
released) 2.95.3 version of gcc.

Thanks to Kevin Hendricks for diagnosing this problem and for testing it on
his machine.

The following short program will test whether your gcc has this problem:
====================================
#include <stdio.h>

void f(int b0, int b1, int b2, int b3, int b4, int b5,
       double a0, int a1, int a2, int a3, double a4, int a5, int a6, int a7)
{
  printf("%d %d %d %d %d %d\n", b0, b1, b2, b3, b4, b5);
  printf("%f %d %d %d %f %d %d %d\n", a0, a1, a2, a3, a4, a5, a6, a7);
}

int main(void) {
  f(0, 1, 2, 3, 4, 5, 0.0, 1, 2, 3, 4.0, 5, 6, 7);
  return(0);
}
====================================

--
Stephen Turner               http://www.statslab.cam.ac.uk/~sret1/
  Statistical Laboratory, Wilberforce Road, Cambridge, CB3 0WB, England
  "Your account can only be used for a single internet session at any one
   time and for no more than 24 hours in any one day." (NTL terms of use)


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Bug#86356: analog: analog segfaults

[Franz Sirl]

At 11:29 02.03.2001, Stephen Turner wrote:

>This turns out to be a bug in gcc, not analog. On ppc, gcc 2.95.2 seems to
>have alignment problems when a function is passed certain long lists of
>arguments including doubles. But apparently the bug is fixed in the (not yet
>released) 2.95.3 version of gcc.

No, it won't be fixed in the official gcc-2.95.3, cause the release manager
Bernd Schmidt rejected my patch because of the possible implications for
other platforms. It is fixed in my Linux/PPC RPM's since about a year, and
accordingly in the update RPM's for LinuxPPC and YDL. Suse is fixed too, I
think since around mid-last-year. Somehow Debian slipped through, but I
have been in contact with Daniel Jacobowitz, and I think he will upgrade
the Debian package soon (or he already has?).
My current diff against the GCC CVS gcc-2_95-branch (which will become the
official 2.95.3) can be found at
<ftp://devel.linuxppc.org:21/users/fsirl/cvs-2_95-branch-ppc.diff>, I just
updated it with a fix for the loop bug uncovered by some MPEG player.

gcc-3.0pre (PPC RPM's soon to come) already has all the fixes, so with 3.0
we all will be in sync again.

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Bug#86356: analog: analog segfaults

[Matthias Klose]

Franz Sirl writes:
 > think since around mid-last-year. Somehow Debian slipped through, but I
 > have been in contact with Daniel Jacobowitz, and I think he will upgrade
 > the Debian package soon (or he already has?).

Starting with Debian gcc-2.95-2.95.3-6 Daniel applied your patches.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/