Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 13529 invoked from network); 28 Jan 2003 18:41:42 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 28 Jan 2003 18:41:42 -0000 Received: (qmail 29156 invoked by uid 97); 28 Jan 2003 18:43:04 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 29140 invoked by uid 97); 28 Jan 2003 18:43:03 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 29128 invoked by uid 98); 28 Jan 2003 18:43:03 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3E36CEB8.6070505@cs.com> Date: Tue, 28 Jan 2003 13:40:56 -0500 From: Alexander Leyke User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en, ru MIME-Version: 1.0 To: tomcat-dev@jakarta.apache.org Subject: JVM Error References: <1043710167.9040.ezmlm@jakarta.apache.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > > >I've seen similar problems - java is very sensitive to each thread >beeing 'registered'. My understanding is that attaching the >thread will set all the TLDs that are needed, and jk2 is calling the >attach method - so I don't know what is wrong here. >My bet would be on thread creation - I would add some printf with the >TID serving the request ( before attaching the thread ). One thing that >may happen in 10 minutes is the thread management code adding or removing >threads. > >Costin > > Right, something like that. The deepest I can debug is jk2_vm_attach function in jk_vm_default.c module. The function makes a call to JNI's GetEnv method, and if result indicates the thread is not attached, calls AttachCurrentThread. Well, I see Web server create a brand new thread, and GetEnv returns an environment pointer for it... This is obviously wrong and causes a problem later when JK2 attempts to call a static method in Tomcat. I thought GetEnv may be broken somehow and altered the code so Attach always happens. No luck either - this time access violation happens in AttachCurrentThread and stack backtrace looks like this: jk2_vm_attach(env = 0x1cc220, jkvm = 0x224fc0) jni_AttachCurrentThread(0xfe0a0338, 0x580f00, 0x0, 0xfe092000, 0xee171668, 0x0) Thread::initialize_thread_local_storage(0x580f00, 0x6, 0x580f00, 0x0, 0x0, 0x0) ThreadLocalStorage::set_thread(0xfe092000, 0x580f00, 0x580f00, 0xee17156c, 0x0, 0x0) report_fatal(0x42, 0xfe092000, 0xfe0482a8, 0xee171, 0xfe092000, 0xee1714ac) report_error(0xd4, 0xee170b7c, 0x42, 0xfe028208, 0xfe0ffddc, 0xfe092000) Thread::print(0x580f00, 0xfe092000, 0x1e8, 0xee170, 0xfe092000, 0xee1702ec) os::get_priority(0x580f00, 0xee1702ec, 0xfe092000, 0xee17033c, 0x7fffffff, 0xfe092000) os::get_native_priority(0x580f00, 0xee170284, 0x0, 0xee170b50, 0x79, 0xee170357) The offending thread doesn't seem to differ in any way (e.g., stack size, priority attributes) from previous Web server request thread which successfully attached itself to JVM. Am I missing some step here? Thanks, Alex -- To unsubscribe, e-mail: For additional commands, e-mail: