Re: CURRENT (r249438): (devel/libiconv)./unistd.h:686:5: error: invalid token at start of a preprocessor expression : #if @GNULIB_EUIDACCESS@

From: Dimitry Andric <dim_at_FreeBSD.org>
Date: Wed, 17 Apr 2013 12:07:47 +0200
On Apr 17, 2013, at 07:31, Jan Beich <jbeich_at_tormail.org> wrote:
> Dimitry Andric <dim_at_FreeBSD.org> writes:
> On Apr 16, 2013, at 00:42, Jan Beich <jbeich_at_tormail.org> wrote:
...
>>> Maybe -O3 overoptimizes regex in libc e.g.,
>>> 
>>> $ echo '#if _at_GNULIB_EUIDACCESS_at_' | sed 's/_at_GNULIB_EUIDACCESS_at_/0/'
>>> #if _at_GNULIB_EUIDACCESS_at_
>>> 
>>> $ echo 'aaaaaaaaaaaaaaaaxxxaaaa' | sed 's/aaaaaaaaaaaaxxxaaaa//'
>>> aaaaaaaaaaaaaaaaxxxaaaa
>> 
>> How did you arrive at this result?
> 
> 1/ chroot into poudriere jail for /head amd64
> 2/ echo CFLAGS+=-O3 >> /etc/make.conf
> 3/ make -j2 (in /usr/src/lib/libc)
> 4/ prepend LD_LIBRARY_PATH=. before sed(1)
> 5/ rebuild regcomp.o, regcomp.So with -O2 to confirm

I have been able to reproduce this on amd64, with -O3, but not on i386.
It seems regcomp() is either miscompiled at -O3, or it contains some bug
triggered only by the vectorizer.  I am still investigating.


> My luck is poor even with -O2 e.g., firefox20 crash on stackoverflow.com
> 
> [New LWP 101222]
> [New Thread 801b02400 (LWP 101222)]
> [New Thread 81060e800 (LWP 101372 StreamTrans #1)]
> [New Thread 810ee8800 (LWP 101373 DOM Worker)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 801b02400 (LWP 101222)]
> PodCopy<JS::Value> (dst=<optimized out>, nelem=<optimized out>,
>    src=<optimized out>, dst=<optimized out>, src=<optimized out>,
>    nelem=<optimized out>) at ../../../js/src/jsutil.h:238
> 238                 PodAssign(dst, src);
> (gdb) bt
> #0  PodCopy<JS::Value> (dst=<optimized out>, nelem=<optimized out>,
>    src=<optimized out>, dst=<optimized out>, src=<optimized out>,
>    nelem=<optimized out>) at ../../../js/src/jsutil.h:238
> #1  getCallFrame (cx=<optimized out>, flags=<optimized out>, fun=<optimized out>,
>    report=(unknown: 2266652928), this=<optimized out>, args=..., script=...)
>    at ../../../js/src/vm/Stack-inl.h:454
> #2  getFixupFrame (cx=<optimized out>, initial=<optimized out>,
>    fun=<optimized out>, ncode=<optimized out>, dummy=0, report=<optimized out>,
>    this=<optimized out>, cx=<optimized out>, report=<optimized out>, args=...,
>    fun=<optimized out>, script=..., ncode=<optimized out>,
>    initial=<optimized out>, stackLimit=<optimized out>)
>    at ../../../js/src/vm/Stack-inl.h:513
> #3  js::mjit::stubs::FixupArity (f=..., nactual=4294945312)
>    at /wrkdirs/usr/ports/www/firefox/work/mozilla-release/js/src/methodjit/InvokeHelpers.cpp:213
> #4  0x00000008019c48c2 in ?? ()
> #5  0x00000008019b56b8 in ?? ()
> #6  0x0000000000000001 in ?? ()
> #7  0x0000000000000000 in ?? ()

This is a completely different issue.  Is there any way you can reduce
the test case?  Or maybe upstream has already fixed it?
Received on Wed Apr 17 2013 - 08:07:54 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:36 UTC