[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ver 1.50 crashes
From: |
rosing |
Subject: |
Re: ver 1.50 crashes |
Date: |
Mon, 14 Oct 2002 10:59:23 -0600 |
The patch worked. Thanks.
You're welcome to have the test case. Therre's no copyright. I was
just playing.
Could you explain to me how the tables are compressed? For each state
there's a table that decides whether to shift or reduce for each
potential token but only a few tokens are of interest. This results
in a sparse table. Somehow these tables are compressed to remove a
lot of zeros.
Matt
Akim Demaille writes:
>
> | | Hi,
> | | I was messing around with bison-1.50 and the following program causes
> | | it to crash. I tried reducing this program and I can't without
> | | removing whatever causes it to crash. Example: removing the BINOP
> | | token, which isn't used or simplifying most other rules. If there's a
> | | better place to send this please let me know.
> |
> | How bizarre... I don't observe this myself. What is your
> | architecture? By any chance, is it a 64 bit platform? Bison is known
> | to have problems there, and it was fixed since then: that will be
> | 1.51.
> |
> | Are there any special options you passed?
> |
> | /tmp % bison gram.y --report=all nostromo
> 9:39
> | gram.y: AVERTISSEMENT: 21 conflits par décalage/réduction et 16 conflits
> par réduction/réduction
> |
> |
> | If ever your architecture is not 64 bits, I'm interested in the traces
> | of `bison --trace=all gram.y'. Thanks!
> |
> | PS/ Please, report bugs to bug-bison, not help.
>
> Please, keep the CC onto the list!
>
> Well, I have it, and I must say the bug is amazing... I think that if
> you apply the following patch, everything will be OK.
>
> ~/src/bison % diff -u src/tables.c.orig src/tables.c -u10 nostromo
> Err 1
> --- src/tables.c.orig 2002-10-14 12:08:34.000000000 +0200
> +++ src/tables.c 2002-10-14 12:05:21.000000000 +0200
> @@ -773,21 +773,21 @@
> `-------------------------------------------------------------*/
>
> static base_t
> table_ninf_remap (base_t tab[], size_t size, base_t ninf)
> {
> base_t res = 0;
> size_t i;
>
> for (i = 0; i < size; i++)
> if (tab[i] < res && tab[i] != ninf)
> - res = base[i];
> + res = tab[i];
>
> --res;
>
> for (i = 0; i < size; i++)
> if (tab[i] == ninf)
> tab[i] = res;
>
> return res;
> }
>
>
> I'm astonished that no other grammar fell onto that problem. I'm also
> surprised I never noticed: it means some of the YY*_NINF guys don't
> fall into the proper range.
>
> Can I use your grammar as test case please? What is its license?
Re: ver 1.50 crashes, Akim Demaille, 2002/10/14