From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3198 invoked by alias); 31 Jul 2005 22:21:12 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 3177 invoked by uid 48); 31 Jul 2005 22:21:11 -0000 Date: Sun, 31 Jul 2005 22:21:00 -0000 Message-ID: <20050731222111.3174.qmail@sourceware.org> From: "greenrd at greenrd dot org" To: java-prs@gcc.gnu.org In-Reply-To: <20031127132523.13212.alessio@itapac.net> References: <20031127132523.13212.alessio@itapac.net> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libgcj/13212] AttachCurrentThread() not working X-Bugzilla-Reason: CC X-SW-Source: 2005-q3/txt/msg00161.txt.bz2 List-Id: ------- Additional Comments From greenrd at greenrd dot org 2005-07-31 22:21 ------- Strangely, this bug is hard to reproduce - with the rssowl test case - with a system compiled for i386. However, the rssowl test case (just start rssowl and load some feeds) appears to be reproducable easily on 64bit x86, according to a bug report I got from a third party. (I can also reproduce it easily on 32bit athlon-xp, but not many distros compile for that.) This is the stack trace on 64bit: #0 0x00002aaaabb794ad in GC_local_malloc_atomic () from /usr/lib/../lib64/libgcj.so.6 #1 0x00002aaaab7c7554 in _Jv_AllocString () from /usr/lib/../lib64/libgcj.so.6 #2 0x00002aaaab7fcda4 in _Jv_NewString () from /usr/lib/../lib64/libgcj.so.6 #3 0x00002aaaab7fe20d in java::lang::Thread::gen_name () from /usr/lib/../lib64/libgcj.so.6 #4 0x00002aaaab7fe7d6 in _Jv_AttachCurrentThread () from /usr/lib/../lib64/libgcj.so.6 #5 0x00002aaaab7c9882 in _Jv_FreeJNIEnv () from /usr/lib/../lib64/libgcj.so.6 #6 0x00002aaab2ad5b32 in callback () from /usr/lib64/libswt-gtk-3138.so #7 0x00002aaab2ac3bb7 in fn70_4 () from /usr/lib64/libswt-gtk-3138.so #8 0x00002aaab4b9a5d1 in NSGetModule () from /usr/lib64/mozilla-1.7.11/components/libnecko.so #9 0x00002aaab40d9b06 in nsStreamCopierOB::FillOutputBuffer () from /usr/lib64/mozilla-1.7.11/libxpcom.so #10 0x00002aaab40d8bd5 in nsPipe::OnPipeException () from /usr/lib64/mozilla-1.7.11/libxpcom.so #11 0x00002aaab40d9e2d in nsStreamCopierOB::DoCopy () from /usr/lib64/mozilla-1.7.11/libxpcom.so #12 0x00002aaab40d9c76 in nsAStreamCopier::Process () from /usr/lib64/mozilla-1.7.11/libxpcom.so #13 0x00002aaab40da10f in nsAStreamCopier::HandleContinuationEvent () from /usr/lib64/mozilla-1.7.11/libxpcom.so #14 0x00002aaab40eeab9 in PL_HandleEvent () from /usr/lib64/mozilla-1.7.11/libxpcom.so #15 0x00002aaab4b91d18 in NSGetModule () from /usr/lib64/mozilla-1.7.11/components/libnecko.so #16 0x000000377672b8f4 in PR_Select () from /usr/lib/../lib64/libnspr4.so #17 0x00002aaaac3b698c in start_thread () from /lib64/libpthread.so.0 #18 0x00002aaaac7a116d in clone () from /lib64/libc.so.6 #19 0x0000000000000000 in ?? () This comment is just to note that this *is* a showstopper for rssowl on 64-bit x86 (I assume this backtrace is on opteron, but I don't know - will find out). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212