On Apr 17, 2013, at 07:31, Jan Beich <jbe...@tormail.org> wrote: > Dimitry Andric <d...@freebsd.org> writes: > On Apr 16, 2013, at 00:42, Jan Beich <jbe...@tormail.org> wrote: ... >>> Maybe -O3 overoptimizes regex in libc e.g., >>> >>> $ echo '#if @GNULIB_EUIDACCESS@' | sed 's/@GNULIB_EUIDACCESS@/0/' >>> #if @GNULIB_EUIDACCESS@ >>> >>> $ 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? _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
