3.2 Bug

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

3.2 Bug

Supratik Champati
lua 3.2 bug on HPUX machines

The following piece of code in lparser.c needs to be replaced

static TaggedString *str_checkname (LexState *ls) {
  return tsvalue(&ls->fs->f->consts[checkname(ls)]);
}

-- modified code
static TaggedString *str_checkname (LexState *ls) {
  int sc = checkname(ls);
  return tsvalue(&ls->fs->f->consts[sc]);
}

This is causing a core dump on HPUX machines. The reason
is rather obvious.

I hope this change finds its way thru to the official release.

Thanks
-- 
Supratik

Reply | Threaded
Open this post in threaded view
|

Re: 3.2 Bug

Michael T. Richter-2
At 01:53 PM 9/1/99 , you wrote:
>static TaggedString *str_checkname (LexState *ls) {
>  return tsvalue(&ls->fs->f->consts[checkname(ls)]);
>}

>static TaggedString *str_checkname (LexState *ls) {
>  int sc = checkname(ls);
>  return tsvalue(&ls->fs->f->consts[sc]);
>}

>This is causing a core dump on HPUX machines. The reason
>is rather obvious.

It isn't obvious at all to me.  What's the problem?  Does HPUX's version of
C not allow return values of functions in array accessors?

--
Michael T. Richter    <[hidden email]>    http://www.igs.net/~mtr/
          PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8 

Reply | Threaded
Open this post in threaded view
|

Re: 3.2 Bug

Supratik Champati
oops! I wanted to say it isn't rather obvious.

The problem is ls->fs->f->consts is initially NULL.
the call to checkname(ls) allocates the array.
On HPUX it is trying to access the index of a NULL array
and hence dumping core.

Michael T. Richter wrote:
> 
> At 01:53 PM 9/1/99 , you wrote:
> >static TaggedString *str_checkname (LexState *ls) {
> >  return tsvalue(&ls->fs->f->consts[checkname(ls)]);
> >}
> 
> >static TaggedString *str_checkname (LexState *ls) {
> >  int sc = checkname(ls);
> >  return tsvalue(&ls->fs->f->consts[sc]);
> >}
> 
> >This is causing a core dump on HPUX machines. The reason
> >is rather obvious.
> 
> It isn't obvious at all to me.  What's the problem?  Does HPUX's version of
> C not allow return values of functions in array accessors?
> 
> --
> Michael T. Richter    <[hidden email]>    http://www.igs.net/~mtr/
>           PGP Key: http://www.igs.net/~mtr/pgp-key.html
> PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8

-- 
Supratik

Reply | Threaded
Open this post in threaded view
|

Re: 3.2 Bug

Luiz Henrique de Figueiredo
In reply to this post by Supratik Champati
>From [hidden email] Wed Sep  1 14:54:07 1999
>From: Supratik Champati <[hidden email]>

>lua 3.2 bug on HPUX machines
>
>The following piece of code in lparser.c needs to be replaced
>
>static TaggedString *str_checkname (LexState *ls) {
>  return tsvalue(&ls->fs->f->consts[checkname(ls)]);
>}
>
>-- modified code
>static TaggedString *str_checkname (LexState *ls) {
>  int sc = checkname(ls);
>  return tsvalue(&ls->fs->f->consts[sc]);
>}
>
>This is causing a core dump on HPUX machines. The reason
>is rather obvious.

It's not at all obvious too me.
Unfortunately, we don't have access to HPUX machines.
Could you please send me details? What compiler? gcc?
Perhaps we could compare the assembly output for the two versions of
str_checkname.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: 3.2 Bug

Supratik Champati
In reply to this post by Supratik Champati
I do not know if my earlier message got posted - so here it is again.

I actually wanted to say that the cause 'isnt' rather obvious.

The reason is that initially ls->fs->f->consts is NULL.
The call checkname(ls) in turn calls next_constant()
which grows the array. On HPUX machines it is dumping core
as it is trying to access a NULL array. (Zero Page Read
reported by purify). On SGI it seems to run fine.


-- 
Supratik

>It's not at all obvious too me.
>Unfortunately, we don't have access to HPUX machines.
>Could you please send me details? What compiler? gcc?
>Perhaps we could compare the assembly output for the two versions of
>str_checkname.
>--lhf

Reply | Threaded
Open this post in threaded view
|

Re: 3.2 Bug

Luiz Henrique de Figueiredo
>From [hidden email] Wed Sep  1 17:49:28 1999
>From: Supratik Champati <[hidden email]>

>The reason is that initially ls->fs->f->consts is NULL.
>The call checkname(ls) in turn calls next_constant()
>which grows the array.

I think you're right. :-(
checkname(ls) changes ls->fs->f->consts and so the expression
  tsvalue(&ls->fs->f->consts[checkname(ls)]);
is undefined because of this side-effect.

It seems that all C compilers we tested (and everybody else!) only get
the value of ls->fs->f->consts *after* checkname returns.
Your compiler in HPUX (which is it?) seems to get the value of ls->fs->f->consts
*before* calling checkname, which I think it can, according to ANSI C rules.

We'll look into it and fix it if it's really wrong.
Thanks.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: 3.2 Bug

Roberto Ierusalimschy
In reply to this post by Supratik Champati
Our bug file for 3.2, till now:


** lmathlib.c
Wed Aug 18 11:28:38 EST 1999
>> random(0) and random(x,0) are wrong (0 is read as no argument!).
(by Dave Bollinger; since 3.1)

** lparser.c
Thu Sep  2 10:07:20 EST 1999
>> in the (old) expression << ls->fs->f->consts[checkname(ls)] >>, checkname
could realloc f->consts.
(by Supratik Champati; since 3.2 beta)

Reply | Threaded
Open this post in threaded view
|

Re: 3.2 Bug

Russell Y. Webb
I sent a message about a hex conversion bug using tonumber(...,16) a
couple of weeks ago.  I know one person on the list got the message 
from, but it isn't in the arachive and there was no responce from the
list.  Are my messages getting through?  Why aren't _any_ of my postings
in the archive? 

The bug BTW was that strtoul needs to be used instead of strtol in the 
number conversion, since I don't think people want to specify negative 
numbers in hex and they might want to specify large positive ones.

Russ Webb

On Thu, 2 Sep 1999, Roberto Ierusalimschy wrote:

> Our bug file for 3.2, till now:
> 
> 
> ** lmathlib.c
> Wed Aug 18 11:28:38 EST 1999
> >> random(0) and random(x,0) are wrong (0 is read as no argument!).
> (by Dave Bollinger; since 3.1)
> 
> ** lparser.c
> Thu Sep  2 10:07:20 EST 1999
> >> in the (old) expression << ls->fs->f->consts[checkname(ls)] >>, checkname
> could realloc f->consts.
> (by Supratik Champati; since 3.2 beta)
> 
> 

Reply | Threaded
Open this post in threaded view
|

Re: 3.2 Bug

Roberto Ierusalimschy
> The bug BTW was that strtoul needs to be used instead of strtol in the 
> number conversion, since I don't think people want to specify negative 
> numbers in hex and they might want to specify large positive ones.

We did get your message (I do not know about the archives). We are considering
it, but we do not consider that a bug. It is a matter of preference. Probably
next version will support 0xFFFFFFFF.

-- Roberto