headers
Akim Demaille | 4 Mar 16:23
Picon
Picon
Picon
Gravatar

Re: bison 2.4.1


Hi Paolo,

Sorry to bother you, but you are probably the one who knows best what  
should be done here.  If you have some time, of course.

Thanks!

Le 20 févr. 09 à 01:22, Robin Cook a écrit :

> As far as I know it is installed correctly.    I am recompiling it  
> now to see if something had gotten messed up but I am recompiling  
> it.    I know some others are having the same problem and they just  
> remove gcj to build bison then reinstall gcj.
>
> Here is the output from strace.
>
> execve("/usr/bin/gcj", ["gcj", "-C", "-d", ".", "conftestlib.java"],  
> [/* 35 vars */]) = 0
> brk(0)                                  = 0x9a3f000
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,  
> -1, 0) = 0xb7f62000
> access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or  
> directory)
> open("/usr/lib/xorg/tls/i686/sse2/libc.so.6", O_RDONLY) = -1 ENOENT  
> (No such file or directory)
> stat64("/usr/lib/xorg/tls/i686/sse2", 0xbfb83a24) = -1 ENOENT (No  
> such file or directory)
> open("/usr/lib/xorg/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No  
> such file or directory)
(Continue reading)

Permalink | Reply | 4 comments |
headers
Robin Cook | 5 Mar 04:29
Gravatar

Re: bison 2.4.1

Here the strace log with the -ff

Robin Cook

On Wed, 2009-03-04 at 18:52 +0100, Paolo Bonzini wrote:
> >>> This looks like a serious problem, and I doubt this is something we
> >>> can fight :(  As you sure your gcj is properly installed?  Can a
> >>>
> >>>     strace gcj -C -d . conftestlib.java
> 
> You actually need strace -ff in order to track forked processes
> correctly.  I suspect the output will be long, you can send it compressed.
> 
> Paolo
> 
>
Attachment (bison-strace.log.bz2): application/x-bzip, 20 KiB
Permalink | Reply | 2 comments |
headers
Paolo Bonzini | 4 Mar 18:52
Picon
Gravatar

Re: bison 2.4.1


>>> This looks like a serious problem, and I doubt this is something we
>>> can fight :(  As you sure your gcj is properly installed?  Can a
>>>
>>>     strace gcj -C -d . conftestlib.java

You actually need strace -ff in order to track forked processes
correctly.  I suspect the output will be long, you can send it compressed.

Paolo
Permalink | Reply | 3 comments |
headers
Paolo Bonzini | 5 Mar 11:21
Picon
Gravatar

Re: bison 2.4.1

Robin Cook wrote:
> Here the strace log with the -ff

The dump ends like this:

> [pid 26956] tgkill(26956, 26957, SIGPWR <unfinished ...>
> [pid 26957] <... futex resumed> )       = ? ERESTARTSYS (To be restarted)
> [pid 26957] --- SIGPWR (Power failure) @ 0 (0) ---
> [pid 26957] rt_sigsuspend(~[INT QUIT ABRT BUS SEGV TERM XCPU RTMIN RT_1] <unfinished ...>
> [pid 26956] <... tgkill resumed> )      = 0
> [pid 26956] mmap2(0x53f000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x53f000
> [pid 26956] tgkill(26956, 26957, SIGXCPU <unfinished ...>
> [pid 26957] <... rt_sigsuspend resumed> ) = ? ERESTARTNOHAND (To be restarted)
> [pid 26957] --- SIGXCPU (CPU time limit exceeded) @ 0 (0) ---
> [pid 26957] sigreturn()                 = ? (mask now ~[INT QUIT ABRT BUS KILL SEGV TERM STOP RTMIN])
> [pid 26957] sigreturn()                 = ? (mask now [CHLD])
> [pid 26957] futex(0x9c787f0, FUTEX_WAIT_PRIVATE, 3, NULL <unfinished ...>
> [pid 26956] <... tgkill resumed> )      = 0
> [pid 26956] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> [pid 26956] rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0
> [pid 26956] futex(0xb7f965b8, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>

Did you cause the SIGXCPU)?  For example, do you have "ulimit -t" set?
(Regarding SIGPWR, I don't know what it is...).

So it looks like a problem invoking ecj1 (the Java->bytecode compiler of
GCJ), and not an easily solved one.  You probably should report it to
your Linux distribution.

Paolo
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robin Cook | 6 Mar 02:06
Gravatar

Re: bison 2.4.1

Not that I am aware of.   I have posted to our distribution mailing
list.

Robin Cook

On Thu, 2009-03-05 at 11:21 +0100, Paolo Bonzini wrote:
> Robin Cook wrote:
> > Here the strace log with the -ff
> 
> The dump ends like this:
> 
> > [pid 26956] tgkill(26956, 26957, SIGPWR <unfinished ...>
> > [pid 26957] <... futex resumed> )       = ? ERESTARTSYS (To be restarted)
> > [pid 26957] --- SIGPWR (Power failure) @ 0 (0) ---
> > [pid 26957] rt_sigsuspend(~[INT QUIT ABRT BUS SEGV TERM XCPU RTMIN RT_1] <unfinished ...>
> > [pid 26956] <... tgkill resumed> )      = 0
> > [pid 26956] mmap2(0x53f000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x53f000
> > [pid 26956] tgkill(26956, 26957, SIGXCPU <unfinished ...>
> > [pid 26957] <... rt_sigsuspend resumed> ) = ? ERESTARTNOHAND (To be restarted)
> > [pid 26957] --- SIGXCPU (CPU time limit exceeded) @ 0 (0) ---
> > [pid 26957] sigreturn()                 = ? (mask now ~[INT QUIT ABRT BUS KILL SEGV TERM STOP RTMIN])
> > [pid 26957] sigreturn()                 = ? (mask now [CHLD])
> > [pid 26957] futex(0x9c787f0, FUTEX_WAIT_PRIVATE, 3, NULL <unfinished ...>
> > [pid 26956] <... tgkill resumed> )      = 0
> > [pid 26956] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > [pid 26956] rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0
> > [pid 26956] futex(0xb7f965b8, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
> 
> Did you cause the SIGXCPU)?  For example, do you have "ulimit -t" set?
> (Regarding SIGPWR, I don't know what it is...).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexandre Duret-Lutz | 26 Mar 11:44
X-Face
Picon
Picon
Picon

cannot compile C++ skeleton with g++-4.3 -Wall -Werror

Hi,

Debian recently upgraded our copy of Bison from 2.3 to 2.4.1, and we found
that our project no longer compiles with g++-4.3.

This code from position.hh

  /// Compare two position objects.
  inline bool
  operator== (const position& pos1, const position& pos2)
  {
    return
      (pos1.filename == pos2.filename
       || pos1.filename && pos2.filename && *pos1.filename == *pos2.filename)
      && pos1.line == pos2.line && pos1.column == pos2.column;
  }

generates the following error with g++-4.3 -Wall -Werror:

position.hh: In function 'bool yy::operator==(const yy::position&, const yy::position&)':
position.hh:136: error: suggest parentheses around && within ||

Regards,
--

-- 
Alexandre Duret-Lutz
Permalink | Reply | 3 comments |
headers
Alexandre Duret-Lutz | 26 Mar 11:57
X-Face
Picon
Picon
Picon

nitpicking: README-hacking seems out-of-date

I just tried to checkout the git repository of Bison in an attempt
to build it, but it wasn't immediately obvious how to do that, and I
didn't have much the time dig more.

README-hacking gives instruction that don't work.  
First I think it should refer to git and not CVS.  
Then running ./bootstrap directly after the checkout as suggested 
simply results in :

% ./bootstrap
./bootstrap: Bootstrapping from checked-out bison sources...
./bootstrap: line 316: gnulib/gnulib-tool: No such file or directory

Yet there is no mention of a gnulib requirement in README-hacking.

It's also confusing that there are two HACKING and README-hacking
files.  It's not clear to me what's the difference, and I almost
missed the latter.

Regards,
--

-- 
Alexandre Duret-Lutz
Permalink | Reply | 1 comment |
headers
Akim Demaille | 26 Mar 15:05
Picon
Picon
Picon
Gravatar

Re: cannot compile C++ skeleton with g++-4.3 -Wall -Werror


Le 26 mars 09 à 11:44, Alexandre Duret-Lutz a écrit :

> Hi,
>
> Debian recently upgraded our copy of Bison from 2.3 to 2.4.1, and we  
> found
> that our project no longer compiles with g++-4.3.
>
> This code from position.hh
>
>  /// Compare two position objects.
>  inline bool
>  operator== (const position& pos1, const position& pos2)
>  {
>    return
>      (pos1.filename == pos2.filename
>       || pos1.filename && pos2.filename && *pos1.filename ==  
> *pos2.filename)
>      && pos1.line == pos2.line && pos1.column == pos2.column;
>  }
>
> generates the following error with g++-4.3 -Wall -Werror:
>
> position.hh: In function 'bool yy::operator==(const yy::position&,  
> const yy::position&)':
> position.hh:136: error: suggest parentheses around && within ||

Thanks, we will fix that.  There will probably be a 2.4.2.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Akim Demaille | 26 Mar 15:06
Picon
Picon
Picon
Gravatar

Re: nitpicking: README-hacking seems out-of-date


Le 26 mars 09 à 11:57, Alexandre Duret-Lutz a écrit :

> I just tried to checkout the git repository of Bison in an attempt
> to build it, but it wasn't immediately obvious how to do that, and I
> didn't have much the time dig more.
>
> README-hacking gives instruction that don't work.
> First I think it should refer to git and not CVS.
> Then running ./bootstrap directly after the checkout as suggested
> simply results in :
>
> % ./bootstrap
> ./bootstrap: Bootstrapping from checked-out bison sources...
> ./bootstrap: line 316: gnulib/gnulib-tool: No such file or directory
>
> Yet there is no mention of a gnulib requirement in README-hacking.
>
> It's also confusing that there are two HACKING and README-hacking
> files.  It's not clear to me what's the difference, and I almost
> missed the latter.

Sorry about that, Ralf complained about the same thing a while ago :(

After git clone, you also need "git submodule update --init".  that's  
about it I think.
Permalink | Reply | 0 comments |
headers
Alexandre Duret-Lutz | 27 Mar 09:48
Picon
Picon
Picon

Re: cannot compile C++ skeleton with g++-4.3 -Wall -Werror

On Thu, Mar 26, 2009 at 3:05 PM, Akim Demaille <akim <at> lrde.epita.fr> wrote:
> Thanks, we will fix that.  There will probably be a 2.4.2.

Great, thanks.

Wouldn't it make sense to use -Wall -Werror in the Bison test suite to
catch these problems earlier?

--

-- 
Alexandre Duret-Lutz
Permalink | Reply | 1 comment |

Gmane