[Bug libgcj/51615] New: Condition Variable queue state corruption and infinite loop

2011-12-18 Thread nwfilardo at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51615

 Bug #: 51615
   Summary: Condition Variable queue state corruption and infinite
loop
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nwfila...@gmail.com


When attempting to run ecj-3.8M4.jar on a large number of files, gij hangs. 
(On a small number of files, it runs fine, curiously enough.)

Invoking gdb (7.3.1), I see that the thread is stuck in
(gdb) bt
#0  _Jv_CondWait (cv=0x1729a48, mu=, millis=,
nanos=)
at ../.././../gcc-4.7-20111210/libjava/posix-threads.cc:241
#1  0x419d99b8 in java::lang::Object::wait (this=0x1704900,
timeout=250, 
nanos=) at
../.././../gcc-4.7-20111210/libjava/java/lang/natObject.cc:226
#2  0x42486aa4 in ffi_call_v9 () at
../.././../gcc-4.7-20111210/libffi/src/sparc/v9.S:83
#3  0x42486400 in ffi_call (cif=0x1815f08, fn=,
rvalue=0x7fdff7f97e8, 
avalue=0x7fdff7f9680) at
../.././../gcc-4.7-20111210/libffi/src/sparc/ffi.c:415
#4  0x424830c8 in ffi_java_raw_call (cif=, fn=, 
rvalue=, raw=)
at ../.././../gcc-4.7-20111210/libffi/src/java_raw_api.c:300
#5  0x419b6430 in _Jv_InterpMethod::run (retp=0x7fdff7f9aa0,
args=0x419b6d9c, meth=0x13a0c00)
at ../.././../gcc-4.7-20111210/libjava/interpret-run.cc:613
#6  0x42483028 in ffi_java_translate_args (cif=,
rvalue=, 
avalue=, user_data=)
at ../.././../gcc-4.7-20111210/libffi/src/java_raw_api.c:314
#7  0x424867e0 in ffi_closure_sparc_inner_v9 (closure=,
rvalue=0x7fdff7f9aa0, 
gpr=0x7fdff7f9bc0, fpr=0x7fdff7f9ac0) at
../.././../gcc-4.7-20111210/libffi/src/sparc/ffi.c:621
#8  0x42486b90 in ffi_closure_v9 () at
../.././../gcc-4.7-20111210/libffi/src/sparc/v9.S:181
#9  0x41dd2ce8 in java.lang.Thread.run()void (this=)
at
/var/ports/usr/ports/lang/gcc47/work/gcc-4.7-20111210/libjava/java/lang/Thread.java:761
#10 0x419ddbec in _Jv_ThreadRun (thread=)
at ../.././../gcc-4.7-20111210/libjava/java/lang/natThread.cc:335
#11 0x419e78a8 in really_start (x=)
at ../.././../gcc-4.7-20111210/libjava/posix-threads.cc:639
#12 0x4249950c in GC_start_routine (arg=0x12ca120)
at ../.././../gcc-4.7-20111210/boehm-gc/pthread_support.c:1301
#13 0x43c68890 in ?? () from /lib/libthr.so.3
#14 0x43c68890 in ?? () from /lib/libthr.so.3

and if I

(gdb) print cv.first
$14 = (_Jv_Thread_t *) 0x446c4830
(gdb) print cv.first.next 
$15 = (_Jv_Thread_t *) 0x446c4830

which is obviously bad since the loop we're stuck in is over ->next pointers
until we see a NULL, which we won't.  Note that current has also become
corrupted in the same way:

(gdb) print current 
$16 = (_Jv_Thread_t *) 0x446c4860
(gdb) print current.next
$17 = (_Jv_Thread_t *) 0x446c4860

I am on a FreeBSD/sparc64 machine, running 8.2 and using gcc47 from ports
(which means exactly 4.7.0 20111210).  It's quite easy to get into this state,
so if I've left something out please don't hesitate to ask.


[Bug middle-end/55308] /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale"

2013-01-13 Thread nwfilardo at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308



nwfilardo at gmail dot com changed:



   What|Removed |Added



 CC||nwfilardo at gmail dot com



--- Comment #1 from nwfilardo at gmail dot com 2013-01-13 19:51:53 UTC ---

This appears to be due to r162478; in particular, gcc/configure.ac:3163 is 

   tls_as_opt="-32 --fatal-warnings", which may be correct for Solaris,

but is certainly wrong on freebsd portbld (where binutils does not support

elf32-sparc-freebsd).  As a result of this mistaken argument to as, the

configuration system does not believe that the machine supports TLS and so

builds an xgcc that does not support it, which yields (after much CPU time) the

reported error message.



Removing the "-32" from gcc/configure.ac (and gcc/configure) does the right

thing for me on my freebsd box, but I won't claim that it's the right fix in

general -- it should probably be conditional either on not-freebsd or

just-solaris.