I'm having a similar problem, when I increase the load on tomcat(3.1) running on Solaris, hotspot crashes and a generate a core file: I was also taking snapshots of memory usage of the process using "top", the last few snapshots before the crash, the memory usage of the process was increasing by ~50M (increments), it did this a few times and then it crashed. I can't tell who's allocating all this memory, it I try to run this in debug, of course everything works fine. Below is the stack trace from the core file. something about rewriting method. Does any know have any idea how I find who is and why all of the sudden the process starts allocating all this memory? khaled Message from hotspot
# # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Error ID: 47454E45524154452F4F502D41500E435050084B 01 # # Problematic Thread: prio=5 tid=0x66daa8 nid=0x17 runnable # Stack trace for the failing thread (from the core file): current thread: t@23 =>[1] __sigprocmask(0x0, 0xd687e528, 0x0, 0x0, 0x0, 0x0), at 0xff369ab8 [2] _resetsig(0xff36c340, 0x0, 0x0, 0xd6881d78, 0xff37e000, 0x0), at 0xff35e50c [3] _sigon(0xd6881d78, 0xff385980, 0x6, 0xd687e5fc, 0xd6881d78, 0xd687e640), at 0xff35dcac [4] _thrp_kill(0x0, 0x17, 0x6, 0xff37e000, 0x17, 0xff2bc4a0), at 0xff360cc0 [5] raise(0x6, 0x0, 0x0, 0xffffffff, 0xff2bc40c, 0xd687e750), at 0xff24b190 [6] abort(0xff2b801c, 0xd687e750, 0x0, 0xfffffff8, 0x4, 0xd687e771), at 0xff2357bc [7] os::abort(0x1, 0xfe796000, 0x1, 0xfe796000, 0x66daa8, 0xd687e76c), at 0xfe6e7ac4 [8] report_error(0xdc, 0xd687eff4, 0x84b, 0xfe746da0, 0xfe7d1830, 0xfe796000), at 0xfe652c08 [9] report_fatal(0x84b, 0xfe796000, 0xfe748ed8, 0xd687fc3c, 0xfe7a7fdc, 0xfe796000), at 0xfe6524d8 [10] GenerateOopMap::error_work(0xfe796000, 0xfe749230, 0xd687fc3c, 0x0, 0xd687fbec, 0xfd9), at 0xfe660b98 [11] GenerateOopMap::report_error(0xd687ff1c, 0xfe749230, 0x4057, 0x4, 0xd687fcf4, 0x66daa8), at 0xfe660bcc [12] GenerateOopMap::expand_current_instr(0xd687ff1c, 0x4057, 0xfe796000, 0x4, 0xd687fcf4, 0x4057), at 0xfe662384 [13] GenerateOopMap::rewrite_load_or_store(0x2, 0xfe796000, 0x4, 0x2a, 0x11a, 0xd687fd68), at 0xfe6428f8 [14] GenerateOopMap::rewrite_refval_conflicts(0xd687ff1c, 0xfabf9610, 0x111d710, 0xfe796000, 0xfe7d307c, 0xfe7d3b2c), at 0xfe57c3b8 [15] GenerateOopMap::compute_map(0xfe79f720, 0xfa0f36dc, 0xfe796000, 0xffffffff, 0x1, 0x0), at 0xfe5751f0 [16] ResolveOopMapConflicts::do_potential_rewrite (0xd6880018, 0xd6880018, 0xd687ff1c, 0xffffffff, 0xfffffff8, 0xfa0f9a50), at 0xfe574b2c [17] Rewriter::rewrite_method(0xd6880018, 0xfe796000, 0xd688001c, 0x66daa8, 0xfe7d307c, 0xfe7d3b2c), at 0xfe56a940 [18] Rewriter::rewrite(0xfe7d3b28, 0xfe7d3b24, 0x1, 0x4, 0x8, 0xf8e45728), at 0xfe569e94 [19] instanceKlass::link_class_impl(0xf8c00af8, 0x66daa8, 0xd6880238, 0xfe796000, 0x66daa8, 0xd6880154), at 0xfe568d50 [20] instanceKlass::initialize_impl(0xd6880340, 0xfa0f9428, 0xfe796000, 0x66daa8, 0x66daa8, 0xd68802dc), at 0xfe580688 [21] instanceKlass::initialize(0xfa0f9428, 0x66daa8, 0x2815c0, 0xfe796000, 0x66daa8, 0xd688035c), at 0xfe580584 [22] JVM_NewInstance(0xfa0f9428, 0x66daa8, 0x66db2c, 0xfe796000, 0xfe7aa28c, 0x0), at 0xfe59a890 [23] 0xfb106528(0xfa0f95b8, 0xe0ed5848, 0x0, 0xad008, 0xf8c02f08, 0x0), at 0xfb106527 [24] 0xfb106328(0xfa0f95b8, 0xe0ed5848, 0xd6880624, 0xffffffff, 0xd9f70000, 0x0), at 0xfb106327 [25] 0xa4500(0xe0ed39b0, 0xe0ed5848, 0xd688069c, 0xafa48, 0x70, 0x0), at 0xa44ff [26] 0xa4500(0xe0ed39b0, 0xd688072c, 0xd6880730, 0xafa48, 0xf8d01a20, 0x0), at 0xa44ff [27] 0xfb1bd5b4(0xe0ed39b0, 0x1, 0xd68807bc, 0xad234, 0x0, 0x0), at 0xfb1bd5b3 [28] 0xa44bc(0xe0ed39b0, 0x140, 0x0, 0xafa48, 0xd9f70000, 0x0), at 0xa44bb [29] 0xa44bc(0xd94bd8e8, 0xd68808f0, 0xd68808f4, 0xaf998, 0xd9f70000, 0x0), at 0xa44bb [30] 0xa44bc(0xd94bd8e8, 0xa6508, 0xd6880998, 0xafaec, 0x2, 0x0), at 0xa44bb [31] 0xa4764(0xdf029328, 0xd68819c0, 0x66daa8, 0xafc24, 0xb6, 0xfa0edb48), at 0xa4763 [32] 0xa44bc(0xd94b7fa8, 0xd6880b60, 0xd6880b64, 0xad794, 0x10, 0x0), at 0xa44bb [33] 0xa44bc(0xd94b7fa8, 0xd6880bf8, 0xd6880bfc, 0xaf998, 0xd6880b24, 0x0), at 0xa44bb [34] 0xa44bc(0xd94b7fa8, 0xa6508, 0xfe796000, 0xaf998, 0x0, 0x0), at 0xa44bb [35] 0xa4764(0xda032240, 0xd6880d10, 0xd6880d14, 0xafc24, 0x1, 0x0), at 0xa4763 [36] 0xa44bc(0xda032240, 0xdfb7e2b0, 0xdfb7e3a0, 0xaf998, 0xf8d01a20, 0x0), at 0xa44bb [37] 0xfb34421c(0xda032240, 0xdfb7e2b0, 0xdfb7e3a0, 0xad234, 0x0, 0x0), at 0xfb34421b [38] 0xa44bc(0xda032240, 0x140, 0x0, 0xafaec, 0xd9f70000, 0x0), at 0xa44bb [39] 0xa44bc(0xd8d3ca68, 0xd6880f68, 0xd6880f6c, 0xaf998, 0xd9f70000, 0x0), at 0xa44bb [40] 0xa44bc(0xd8d3ca68, 0xa6508, 0xd6880ff8, 0xafaec, 0x2, 0x0), at 0xa44bb [41] 0xa4764(0xd8c268d0, 0xd68819c0, 0x66daa8, 0xafc24, 0xb6, 0xfa0e84c0), at 0xa4763 [42] 0xa44bc(0xd8c268d0, 0xd68819c0, 0x66daa8, 0xad794, 0xb6, 0xfa0e7c60), at 0xa44bb [43] 0xa44bc(0xd8c0c770, 0xd68811f0, 0xd68811f4, 0xad794, 0xd9f70000, 0x0), at 0xa44bb [44] 0xa44bc(0xd8c0c770, 0xa6508, 0xd6881284, 0xaf998, 0xfe79f180, 0x0), at 0xa44bb [45] 0xa44bc(0xd8c0c770, 0xffffffff, 0xffffffff, 0xafa48, 0x8, 0x0), at 0xa44bb [46] 0xa44bc(0xd8c0c770, 0xd68813b0, 0xd68813b4, 0xaf998, 0xd68812dc, 0x0), at 0xa44bb [47] 0xa44bc(0xd8c0c770, 0xa6508, 0xfe796000, 0xaf998, 0x0, 0x0), at 0xa44bb [48] 0xa4764(0xdd556398, 0xd68814c8, 0xd68814cc, 0xafc24, 0x0, 0x0), at 0xa4763 [49] 0xa44bc(0xdd556398, 0xdfb7e2b0, 0xdfb7e3a0, 0xaf998, 0xdd572f28, 0x0), at 0xa44bb [50] 0xfb34421c(0xdd556398, 0xdfb7e2b0, 0xdfb7e3a0, 0xac814, 0x5c3, 0x0), at 0xfb34421b [51] 0xa44bc(0xdd556398, 0xdfb7e2b0, 0xd688167c, 0xafaec, 0x1d, 0x0), at 0xa44bb [52] 0xa44bc(0xdad204c8, 0x3, 0xd688171c, 0xaf998, 0xd9f70000, 0x0), at 0xa44bb [53] 0xa44bc(0xdad204c8, 0xd68817c0, 0xdfb7bd60, 0xafaec, 0xdb025c00, 0x0), at 0xa44bb [54] 0xa44bc(0xdad20e60, 0xdaf61d78, 0xdfb7bd60, 0xaf998, 0x66daa8, 0xfe796000), at 0xa44bb [55] 0xfb1fe4f8(0xdafef310, 0xdfb7bd60, 0xd68819c0, 0xd6881850, 0xdb026370, 0x0), at 0xfb1fe4f7 [56] 0xa4764(0xd8e1c568, 0xa6508, 0xd6881954, 0xafc24, 0x66daa8, 0x0), at 0xa4763 [57] 0xa4764(0x0, 0x1, 0xfe7a2900, 0xafc24, 0x1e, 0xe), at 0xa4763 [58] 0xfe7cb3f4(0xd68819e0, 0xd6881c18, 0xa, 0xf8c16378, 0xa6508, 0xd6881b64), at 0xfe7cb3f3 [59] JavaCalls::call_helper(0xd6881c10, 0xfe796000, 0xd6881b5c, 0x66daa8, 0xa6508, 0xd6881c18), at 0xfe58162c [60] JavaCalls::call_virtual(0xf8c17000, 0xd6881b48, 0xd6881b4c, 0xfe796000, 0xd6881c10, 0xd6881b5c), at 0xfe5902c4 [61] JavaCalls::call_virtual(0xd6881c10, 0xd6881c0c, 0xd6881c08, 0xd6881bfc, 0xd6881bf4, 0x66daa8), at 0xfe590154 [62] thread_entry(0xf8c17000, 0x66daa8, 0xfe796000, 0xd6881d18, 0x1e, 0xe), at 0xfe5900dc [63] JavaThread::run(0xd6802000, 0xfe79fe9c, 0xfe796000, 0x80000, 0x66daa8, 0x80000), at 0xfe58fee8 [64] _start(0xfe796000, 0xfe265d18, 0x0, 0x5, 0x1, 0xfe401000), at 0xfe57fd0c -----Original Message----- From: Aymeric Alibert [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 4:37 PM To: [EMAIL PROTECTED] Subject: RE: TC 4.1 and VM crash: how to report issue? Thanks for the feedback. When I ran my load tests I used -Xmx512m -Xms512m as heap settings. I also tried increasing or decreasing it but it didn't change the results. I am running on Solaris and I have all the recommended patches for JDK1.4.1 installed. I can reproduce the problem: it is always crashing during the test, but it can be after 2 minutes or 20 minutes depending on the run. My problem is that I cannot create a simple test case that will crash the server because of the complexity of our environment ( it includes multiples Oracle databases and LDAP connectivity). I tried to isolate the problem to a single jsp like you recommend it but that didn't work. (I could fine several combinations that would trigger the crash). So I am not sure what I could provide as a test case except our full dev environment. I can deploy the same application on TC4.0.4 and it runs fine. I tried many versions of Tomcat 4.1 (4.1.7, 4.1.12, 4.1.14 and 4.1.16) and are all failing. I attached the VM log. Thanks, Aymeric >>> [EMAIL PROTECTED] 12/10/02 04:48PM >>> Howdy, If your OS requires patches in order to run the JDK (whatever version you're trying to run), make sure those patches are installed. I had this exact issue happen on Solaris, and installing the proper Solaris patches made it go away. You say "The same behavior can be reproduced with both JDK1.4.0 and JDK1.4.1" and yet "I cannot create a test case to reproduce my problem." Which one is it? ;) If you can reproduce it, the full details of how to reproduce it can be posted to Sun's bug parade, and they'll track down whatever tools they need in order to mimic your environment. If you can't reproduce it, there's no bug as far as they're concerned. Finally, I'm not sure I understand this bullet: >- I works fine with TC4.1 So your app works fine on TC 4.1? I thought that was the whole problem? Or did you mean it works fine with TC 4.0 and not 4.1? If it's the latter, as I suspect, perhaps you could start by deploying a very small subset of your app and repeating the test. Then increase the deployed subset and retest. The idea is that a certain feature of tomcat as used by your app is crashing the VM, and to find out which section of your app is causing this. The more you can narrow it down, the better. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: < mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: < mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >
