Related
I have a Linux server with 48 CPU and, from time to time, some of them starts hitting almost 100% of usage. And when that happens, the usage doesn't go down and that's affecting some services performance.
When I reboot this server, everything goes ok for several days when some starts hitting almost 100% of usage again. This is like a cycle.
The problem is that the usage of some CUP, when hits 100%, doesn't change, unless I reboot server, and there is a service that's performing badly when that occurs.
When I use the htop command, I can see some process ksoftirq/0, ksoftirq/1, ksoftirq/2 ... is the responsible for this usage. I don't know what to do.
One approach that I tried was: I observed that the number of CPU where that occurs tends to be in the first half (0-23). I tried to change the affinity of those process (ksoftirq) to another CPU in the second half (24-47), but without any success.
What I want is: how to low this ksoftirq process usage or, at least, how to distribute them in order to keep CPU with a usage lower?
I'm not sure if the solution is about changing the affinity or changing some other attribute. I'm really clueless in this situation.
This is a physical server. Some info about it:
output of lsb_release -a:
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye
output of uname -a:
Linux tiamat-dc 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) x86_64 GNU/Linux
output of lscpu:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 44 bits physical, 48 bits virtual
CPU(s): 48
On-line CPU(s) list: 0-47
Thread(s) per core: 2
Core(s) per socket: 6
Socket(s): 4
NUMA node(s): 4
Vendor ID: GenuineIntel
CPU family: 6
Model: 46
Model name: Intel(R) Xeon(R) CPU E7530 # 1.87GHz
Stepping: 6
CPU MHz: 1239.565
BogoMIPS: 3723.93
Virtualization: VT-x
L1d cache: 768 KiB
L1i cache: 768 KiB
L2 cache: 6 MiB
L3 cache: 48 MiB
NUMA node0 CPU(s): 0,4,8,12,16,20,24,28,32,36,40,44
NUMA node1 CPU(s): 1,5,9,13,17,21,25,29,33,37,41,45
NUMA node2 CPU(s): 2,6,10,14,18,22,26,30,34,38,42,46
NUMA node3 CPU(s): 3,7,11,15,19,23,27,31,35,39,43,47
Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled
Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
Vulnerability Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable
Vulnerability Meltdown: Mitigation; PTI
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP conditional, RSB filling
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx rdtscp l
m constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx
16 xtpr pdcm dca sse4_1 sse4_2 x2apic popcnt lahf_lm pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid dtherm ida flush_l1d
I wanted to make my own wiki for my own personal use and carry it around on an external drive. I am using Windows 10.
I installed XAMPP portable to my external drive and set up MediaWiki yesterday and everything was fine. I turned off my computer without shutting down apache and mysql and woke up to this morning to continue working on it but mysql cannot start. I have no backup yet since I recently just made it yesterday night so I won't be too upset losing the very few articles I written.
InnoDB: using atomic writes.
2020-04-10 15:05:25 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2020-04-10 15:05:25 0 [Note] InnoDB: Uses event mutexes
2020-04-10 15:05:25 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2020-04-10 15:05:25 0 [Note] InnoDB: Number of pools: 1
2020-04-10 15:05:25 0 [Note] InnoDB: Using SSE2 crc32 instructions
2020-04-10 15:05:25 0 [Note] InnoDB: Initializing buffer pool, total size = 16M, instances = 1, chunk size = 16M
2020-04-10 15:05:25 0 [Note] InnoDB: Completed initialization of buffer pool
2020-04-10 15:05:25 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=300288
2020-04-10 15:05:25 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2020-04-10 15:05:25 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2020-04-10 15:05:25 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2020-04-10 15:05:25 0 [Note] InnoDB: Setting file 'D:\xampp\mysql\data\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2020-04-10 15:05:25 0 [Note] InnoDB: File 'D:\xampp\mysql\data\ibtmp1' size is now 12 MB.
2020-04-10 15:05:25 0 [Note] InnoDB: Waiting for purge to start
2020-04-10 15:05:25 0 [Note] InnoDB: 10.4.11 started; log sequence number 300297; transaction id 171
2020-04-10 15:05:25 0 [Note] InnoDB: Loading buffer pool(s) from D:\xampp\mysql\data\ib_buffer_pool
2020-04-10 15:05:25 0 [Note] Plugin 'FEEDBACK' is disabled.
2020-04-10 15:05:25 0 [Note] Server socket created on IP: '::'.
2020-04-10 15:12:20 0 [Note] mysqld: Aria engine: starting recovery
recovered pages: 0% 26% 38% 54% 64% 74% 84% 94% 100% (0.0 seconds); tables to flush: 2 1 0
(0.1 seconds);
2020-04-10 15:12:20 0 [Note] mysqld: Aria engine: recovery done
InnoDB: using atomic writes.
2020-04-10 15:12:20 0 [ERROR] InnoDB: The innodb_system data file 'ibdata1' must be writable
2020-04-10 15:12:20 0 [ERROR] InnoDB: The innodb_system data file 'ibdata1' must be writable
2020-04-10 15:12:20 0 [ERROR] Plugin 'InnoDB' init function returned error.
2020-04-10 15:12:20 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2020-04-10 15:12:20 0 [Note] Plugin 'FEEDBACK' is disabled.
2020-04-10 15:12:20 0 [ERROR] Unknown/unsupported storage engine: InnoDB
2020-04-10 15:12:20 0 [ERROR] Aborting
I tried looking at ibdata1, I as administrator should have complete control over it so I'm not sure why I'm getting this error.
What are my options on how to fix this?
Maybe you have existing mysql process is runing, go to task manager to disable it.
I had a similar problem when I was trying to reset my password to MySQL. I am using a Windows computer. I went into Administrative Tools -> Services and then stopped the MySQL task. Then I didn't receive the error message: " 'ibdata1' must be writable"
I have WAWMP installed on Win 7. It was working well but since I restarted my system and I ran into a problem.
Problem is that MySQL is not starting but Apache is running as usual. When I Test Port 80 it says Apache is running.
I have tried to change ports in my.ini of MySQL but still MySQL does not start.
Here is latest Log when I attempted to start MySQL
2014-06-18 08:15:23 4496 [Note] Plugin 'FEDERATED' is disabled.
2014-06-18 08:15:23 4496 [Note] InnoDB: The InnoDB memory heap is disabled
2014-06-18 08:15:23 4496 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2014-06-18 08:15:23 4496 [Note] InnoDB: Compressed tables use zlib 1.2.3
2014-06-18 08:15:23 4496 [Note] InnoDB: Not using CPU crc32 instructions
2014-06-18 08:15:23 4496 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2014-06-18 08:15:23 4496 [Note] InnoDB: Completed initialization of buffer pool
2014-06-18 08:15:23 4496 [Note] InnoDB: Highest supported file format is Barracuda.
2014-06-18 08:15:24 4496 [Note] InnoDB: The log sequence numbers 1625977 and 1625977 in ibdata files do not match the log sequence number 22262437 in the ib_logfiles!
2014-06-18 08:15:24 4496 [Note] InnoDB: Database was not shutdown normally!
2014-06-18 08:15:24 4496 [Note] InnoDB: Starting crash recovery.
2014-06-18 08:15:24 4496 [Note] InnoDB: Reading tablespace information from the .ibd files...
2014-06-18 08:15:24 4496 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace joomla_web/intern_extensions uses space ID: 104 at filepath: .\joomla_web\intern_extensions.ibd. Cannot open tablespace test/joomla_assets which uses space ID: 104 at filepath: .\test\joomla_assets.ibd
InnoDB: Error: could not open single-table tablespace file .\test\joomla_assets.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.
try to goto control panel, administrative tool, services or run services.msc (shortcut) try to start and stop and restart MYSQL services.
Ok I solved my problem by deleting the ibdata1 file in C:\WAMP\mysql\data
For those who dont know what is What is stored in ibdata1
Read this answer
We reproducibly experience errors when attempting to checkout or update working copies.
Environment
Our environment is as follows:-
svn 1.8.9 (r1591380) client and server running on the same server (also happens with client on another server, but less often)
Server runs Windows Server 2008 (64 bit)
Apache httpd server
We are running the svn checkout from QuickBuild.
Client Error
This error is reported from the checkout:-
svn checkout http://qvsvn101/PayWay/PayWay/Branches/2014.R1/ D:\quickbuild_workspace\PayWay\Application\PointRelease\Release --non-interactive --username SrvAcc --password ****** -r 11523
Command return code: -1073741819
Command error output: This application has halted due to an unexpected error.
A crash report and minidump file were saved to disk, you can find them here:
C:\Users\SrvAcc\AppData\Local\Temp\svn-crash-log20140527164109.log
C:\Users\SrvAcc\AppData\Local\Temp\svn-crash-log20140527164109.dmp
Please send the log file to users_at_subversion.apache.org to help us analyze
and solve this problem.
NOTE: The crash report and minidump files can contain some sensitive information
(filenames, partial file content, usernames and passwords etc.)
Apache httpd error log
At the same time, the Apache error.log contains this:
[Tue May 27 16:41:12 2014] [error] [client 192.168.40.47] Provider encountered an error while streaming a REPORT response. [500, #0]
[Tue May 27 16:41:12 2014] [error] [client 192.168.40.47] A failure occurred while driving the update report editor [500, #106]
Subversion Crash Log File
Subversion writes out a log file as follows:
Process info:
Cmd line: svn checkout http://qvsvn101/PayWay/PayWay/Branches/2014.R1/ D:\quickbuild_workspace\PayWay\Application\PointRelease\Release --non-interactive --username SrvAcc --password ****** -r 11523
Working Dir: D:\quickbuild_workspace\PayWay\Application\PointRelease\Release
Version: 1.8.9 (r1591380), compiled May 8 2014, 04:25:41
Platform: Windows OS version 6.1 build 7601 Service Pack 1
Exception: ACCESS_VIOLATION
Registers:
eax=7259a7c0 ebx=00000000 ecx=01e5e138 edx=72746e65 esi=01e5e138 edi=61006469
eip=7259a7cf esp=003cf44c ebp=003cf458 efl=00010202
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b
Stacktrace:
#1 0x7259a7cf in svn_wc_add_repos_file4()
#2 0x732396b7 in svn_ra_svn_init()
#3 0x7323470b in svn_ra_svn_init()
#4 0x73234abe in svn_ra_svn_init()
#5 0x731f3110 in (unknown function)
Loaded modules:
0x00020000 D:\SubversionServer\svn.exe (1.8.9.18516, 241664 bytes)
0x77a20000 C:\Windows\SysWOW64\ntdll.dll (6.1.7601.18247, 1572864 bytes)
0x75f00000 C:\Windows\SysWOW64\kernel32.dll (6.1.7601.18229, 1114112 bytes)
0x75e00000 C:\Windows\SysWOW64\KERNELBASE.dll (6.1.7601.18229, 290816 bytes)
0x73600000 D:\SubversionServer\libapr-1.dll (1.5.1.0, 163840 bytes)
0x764a0000 C:\Windows\SysWOW64\ws2_32.dll (6.1.7601.17514, 217088 bytes)
0x75800000 C:\Windows\SysWOW64\msvcrt.dll (7.0.7601.17744, 704512 bytes)
0x75350000 C:\Windows\SysWOW64\rpcrt4.dll (6.1.7601.18205, 983040 bytes)
0x75100000 C:\Windows\SysWOW64\sspicli.dll (6.1.7601.18270, 393216 bytes)
0x750f0000 C:\Windows\SysWOW64\CRYPTBASE.dll (6.1.7600.16385, 49152 bytes)
0x75ee0000 C:\Windows\SysWOW64\sechost.dll (6.1.7600.16385, 102400 bytes)
0x75950000 C:\Windows\SysWOW64\nsi.dll (6.1.7600.16385, 24576 bytes)
0x74510000 C:\Windows\System32\mswsock.dll (6.1.7601.18254, 245760 bytes)
0x76010000 C:\Windows\SysWOW64\user32.dll (6.1.7601.17514, 1048576 bytes)
0x75960000 C:\Windows\SysWOW64\gdi32.dll (6.1.7601.18275, 589824 bytes)
0x779f0000 C:\Windows\SysWOW64\lpk.dll (6.1.7601.18177, 40960 bytes)
0x758b0000 C:\Windows\SysWOW64\usp10.dll (1.626.7601.18009, 643072 bytes)
0x759f0000 C:\Windows\SysWOW64\advapi32.dll (6.1.7601.18247, 655360 bytes)
0x76510000 C:\Windows\SysWOW64\shell32.dll (6.1.7601.18222, 12886016 bytes)
0x75e70000 C:\Windows\SysWOW64\shlwapi.dll (6.1.7601.17514, 356352 bytes)
0x73260000 D:\SubversionServer\MSVCR100.DLL (10.0.30319.1, 778240 bytes)
0x73580000 D:\SubversionServer\libsvn_client-1.dll (1.8.9.18516, 319488 bytes)
0x74010000 D:\SubversionServer\libsvn_delta-1.dll (1.8.9.18516, 122880 bytes)
0x733e0000 D:\SubversionServer\libaprutil-1.dll (1.5.3.0, 204800 bytes)
0x73ee0000 D:\SubversionServer\libapriconv-1.dll (1.2.1.0, 36864 bytes)
0x72a80000 D:\SubversionServer\libsvn_subr-1.dll (1.8.9.18516, 1077248 bytes)
0x73670000 C:\Windows\System32\shfolder.dll (6.1.7600.16385, 20480 bytes)
0x755c0000 C:\Windows\SysWOW64\ole32.dll (6.1.7601.17514, 1425408 bytes)
0x75230000 C:\Windows\SysWOW64\crypt32.dll (6.1.7601.18277, 1179648 bytes)
0x75ed0000 C:\Windows\SysWOW64\msasn1.dll (6.1.7601.17514, 49152 bytes)
0x74a30000 C:\Windows\System32\version.dll (6.1.7600.16385, 36864 bytes)
0x73cc0000 D:\SubversionServer\libsvn_diff-1.dll (1.8.9.18516, 86016 bytes)
0x731f0000 D:\SubversionServer\libsvn_ra-1.dll (1.8.9.18516, 454656 bytes)
0x738f0000 D:\SubversionServer\libsasl.dll (2.1.23.0, 81920 bytes)
0x73f10000 D:\SubversionServer\libsvn_fs-1.dll (1.8.9.18516, 225280 bytes)
0x73f60000 D:\SubversionServer\libsvn_repos-1.dll (1.8.9.18516, 180224 bytes)
0x735d0000 C:\Windows\System32\secur32.dll (6.1.7601.18270, 32768 bytes)
0x731a0000 D:\SubversionServer\ssleay32.dll (1.0.1.7, 286720 bytes)
0x72940000 D:\SubversionServer\libeay32.dll (1.0.1.7, 1306624 bytes)
0x72550000 D:\SubversionServer\libsvn_wc-1.dll (1.8.9.18516, 544768 bytes)
0x76340000 C:\Windows\System32\imm32.dll (6.1.7601.17514, 393216 bytes)
0x75160000 C:\Windows\SysWOW64\msctf.dll (6.1.7600.16385, 835584 bytes)
0x74960000 C:\Windows\System32\profapi.dll (6.1.7600.16385, 45056 bytes)
0x744f0000 C:\Windows\System32\nlaapi.dll (6.1.7601.17761, 65536 bytes)
0x744e0000 C:\Windows\System32\NapiNSP.dll (6.1.7600.16385, 65536 bytes)
0x742c0000 C:\Windows\System32\dnsapi.dll (6.1.7601.17570, 278528 bytes)
0x744d0000 C:\Windows\System32\winrnr.dll (6.1.7600.16385, 32768 bytes)
0x742a0000 C:\Windows\System32\IPHLPAPI.DLL (6.1.7601.17514, 114688 bytes)
0x74290000 C:\Windows\System32\winnsi.dll (6.1.7600.16385, 28672 bytes)
0x74250000 C:\Windows\System32\FWPUCLNT.DLL (6.1.7601.18283, 229376 bytes)
0x74240000 C:\Windows\System32\rasadhlp.dll (6.1.7600.16385, 24576 bytes)
0x74500000 C:\Windows\System32\WSHTCPIP.DLL (6.1.7600.16385, 20480 bytes)
0x74ae0000 C:\Windows\System32\dbghelp.dll (6.1.7601.17514, 962560 bytes)
0x73170000 C:\Windows\System32\powrprof.dll (6.1.7600.16385, 151552 bytes)
0x76110000 C:\Windows\SysWOW64\setupapi.dll (6.1.7601.17514, 1691648 bytes)
0x75470000 C:\Windows\SysWOW64\cfgmgr32.dll (6.1.7601.17621, 159744 bytes)
0x763a0000 C:\Windows\SysWOW64\oleaut32.dll (6.1.7601.17676, 585728 bytes)
0x75e50000 C:\Windows\SysWOW64\devobj.dll (6.1.7601.17621, 73728 bytes)
Here is the related thread in dev# Subversion mailing list.
It looks like your server interrupts the connection and Subversion 1.8 client built with serf 1.3.5 library crashes on this failure. That's why you see the error with older Subversion client but the client built with serf 1.3.5 crashes.
Serf 1.3.5 fails to process the error and thus crash on the client occurs. There is a great chance that the crash is caused by the bug in Serf library (on client side) which is fixed in the version 1.3.6:
Revert r2319 from serf 1.3.5: this change was making serf call
handle_response multiple times in case of an error response, leading
to unexpected behavior.
I suggest trying Subversion command-line client which is built against Serf 1.3.6. Subversion 1.8.x binaries built with serf 1.3.6 are going to be available soon.
I posted the same dump file to the users#subversion.apache.org mailing list but have had no reply in 2 weeks. To get around this issue, I switched QuickBuild to use jsvn.bat from the pure Java distribution of SVNKit and the issue seems to be resolved. Jsvn has the same command-line interface as the Apache svn binary, so it's a simple drop-in replacement.
I initially had an authentication issue because we use NTLM to authenticate with our active directory. The error was "svn: E170001: Authentication required for repsoitory" The solution was to add the following to svnkit\bin\jsvn.bat after the existing EXTRA_JVM_ARGUMENTS environment variable:
rem Adding this to resolve authentication issue as per http://subversion.1072662.n5.nabble.com/SVN-authentication-problem-td1560.html
set EXTRA_JVM_ARGUMENTS=%EXTRA_JVM_ARGUMENTS% "-Dsvnkit.http.methods=Basic,Digest,Negotiate,NTLM"
The only thing worked for me is to install the previous version of Tortoise svn(TortoiseSVN-1.8.6.25419-x64-svn-1.8.8) which runs with the pervious version of svn client 1.8.8 and then use the old version of the svn.exe. That worked against the newer version of the server (1.8.9) too.
(I had the same issue. I upgraded yesterday my collabnet subversion to the latest (svn version 1.8.9-3871.129) and both the command prompt svn checkout or the latest tortoise svn (1.8.7) fails. I have the same ACCESS_VIOLATION error in the dump log. And my computer is Windows 7 64 bit.)
I am getting this error when writer.optimize() called I have caugh all exceptions but hopeless .writer is an instance of apache lucene Indexwriter and tomcat collapse when optimizing the indexwriter.I am trying to index a large number of file its works for a few number of file but when number of files increase it cause to tomcat fail.
logger.info("Optimizing optimazing...");
this.writer.optimize();
logger.info("Optimizing closing...");
this.writer.close();
logger.info("Optimazide and closed succesfully...");
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fe6f8c38e90, pid=10316, tid=140629887768320
#
# JRE version: 6.0_20-b20
# Java VM: OpenJDK 64-Bit Server VM (19.0-b09 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea6 1.9.7
# Distribution: Ubuntu 10.10, package 6b20-1.9.7-0ubuntu1
# Problematic frame:
# V [libjvm.so+0x54ae90]
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
# https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
#
--------------- T H R E A D ---------------
Current thread (0x00000000023e0000): JavaThread "CompilerThread0" daemon [_thread_in_native, id=10333, stack(0x00007fe6f2715000,0x00007fe6f2816000)]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000008
Registers:
RAX=0x0000000000000000, RBX=0x00007fe6f2812930, RCX=0x00007fe6ec03e9e0, RDX=0x0000000000002000
RSP=0x00007fe6f2811150, RBP=0x00007fe6f2811190, RSI=0x00007fe6e43a20f0, RDI=0x0000000000000000
R8 =0x00007fe6e43f5a70, R9 =0x00007fe6f2812930, R10=0x00007fe6ec6f7948, R11=0x0000000000000000
R12=0x00007fe6edd326b0, R13=0x00007fe6ec6f7948, R14=0x00007fe6f2812950, R15=0x00007fe6ec068990
RIP=0x00007fe6f8c38e90, EFL=0x0000000000010206, CSGSFS=0x0000000000000033, ERR=0x0000000000000004
TRAPNO=0x000000000000000e
Register to memory mapping:
RAX=0x0000000000000000
0x0000000000000000 is pointing to unknown location
RBX=0x00007fe6f2812930
0x00007fe6f2812930 is pointing into the stack for thread: 0x00000000023e0000
"CompilerThread0" daemon prio=10 tid=0x00000000023e0000 nid=0x285d runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
RCX=0x00007fe6ec03e9e0
0x00007fe6ec03e9e0 is pointing to unknown location
RDX=0x0000000000002000
0x0000000000002000 is pointing to unknown location
RSP=0x00007fe6f2811150
0x00007fe6f2811150 is pointing into the stack for thread: 0x00000000023e0000
"CompilerThread0" daemon prio=10 tid=0x00000000023e0000 nid=0x285d runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
RBP=0x00007fe6f2811190
0x00007fe6f2811190 is pointing into the stack for thread: 0x00000000023e0000
"CompilerThread0" daemon prio=10 tid=0x00000000023e0000 nid=0x285d runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
RSI=0x00007fe6e43a20f0
0x00007fe6e43a20f0 is pointing to unknown location
RDI=0x0000000000000000
0x0000000000000000 is pointing to unknown location
R8 =0x00007fe6e43f5a70
0x00007fe6e43f5a70 is pointing to unknown location
R9 =0x00007fe6f2812930
0x00007fe6f2812930 is pointing into the stack for thread: 0x00000000023e0000
"CompilerThread0" daemon prio=10 tid=0x00000000023e0000 nid=0x285d runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
R10=0x00007fe6ec6f7948
0x00007fe6ec6f7948 is pointing to unknown location
R11=0x0000000000000000
0x0000000000000000 is pointing to unknown location
R12=0x00007fe6edd326b0
0x00007fe6edd326b0 is pointing to unknown location
R13=0x00007fe6ec6f7948
0x00007fe6ec6f7948 is pointing to unknown location
R14=0x00007fe6f2812950
0x00007fe6f2812950 is pointing into the stack for thread: 0x00000000023e0000
"CompilerThread0" daemon prio=10 tid=0x00000000023e0000 nid=0x285d runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
R15=0x00007fe6ec068990
0x00007fe6ec068990 is pointing to unknown location
Top of Stack: (sp=0x00007fe6f2811150)
0x00007fe6f2811150: 00007fe6e4522cd0 00007fe6f2811420
0x00007fe6f2811160: 00007fe6f2811190 00007fe6f2812930
0x00007fe6f2811170: 0000000000000002 00007fe6edd326b0
0x00007fe6f2811180: 00007fe6ec5d6430 00007fe6f2811420
0x00007fe6f2811190: 00007fe6f2811200 00007fe6f8c3941b
0x00007fe6f28111a0: 0000000000000002 00007fe600000100
0x00007fe6f28111b0: 00007fe600000001 00007fe6f28132d0
w-p 00021000 08:01 17301749 /lib/ld-2.12.1.so
7fe6fa020000-7fe6fa021000 rw-p 00000000 00:00 0
7fffd5558000-7fffd5579000 rw-p 00000000 00:00 0 [stack]
7fffd55ff000-7fffd5600000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
VM Arguments:
jvm_args: -Djava.util.logging.config.file=/home/murat/Desktop/servers/apache-tomcat-6.0.24/conf/logging.properties -Dhttp.nonProxyHosts=localhost|127.0.0.1|expertPC -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -agentlib:jdwp=transport=dt_socket,address=11550,server=y,suspend=n -Djava.endorsed.dirs=/home/murat/Desktop/servers/apache-tomcat-6.0.24/endorsed -Dcatalina.base=/home/murat/Desktop/servers/apache-tomcat-6.0.24 -Dcatalina.home=/home/murat/Desktop/servers/apache-tomcat-6.0.24 -Djava.io.tmpdir=/home/murat/Desktop/servers/apache-tomcat-6.0.24/temp
java_command: org.apache.catalina.startup.Bootstrap start
Launcher Type: SUN_STANDARD
Environment Variables:
JAVA_HOME=/usr/lib/jvm/java-6-openjdk
JRE_HOME=/usr/lib/jvm/java-6-openjdk
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
USERNAME=murat
LD_LIBRARY_PATH=/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64
SHELL=/bin/bash
DISPLAY=:0.0
Signal Handlers:
SIGSEGV: [libjvm.so+0x723630], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x723630], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x5e0000], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: SIG_IGN, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGXFSZ: [libjvm.so+0x5e0000], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x5e0000], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x5df710], sa_mask[0]=0x00000004, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x5e2180], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: SIG_IGN, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGTERM: [libjvm.so+0x5e2180], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x5e2180], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
--------------- S Y S T E M ---------------
OS:Ubuntu 10.10 (maverick)
uname:Linux 2.6.35-28-generic #50-Ubuntu SMP Fri Mar 18 18:42:20 UTC 2011 x86_64
libc:glibc 2.12.1 NPTL 2.12.1
rlimit: STACK 8192k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity
load average:0.77 0.30 0.14
/proc/meminfo:
MemTotal: 4054828 kB
MemFree: 176928 kB
Buffers: 207640 kB
Cached: 1332820 kB
SwapCached: 17608 kB
Active: 2419624 kB
Inactive: 1004992 kB
Active(anon): 1834536 kB
Inactive(anon): 67792 kB
Active(file): 585088 kB
Inactive(file): 937200 kB
Unevictable: 16 kB
Mlocked: 16 kB
SwapTotal: 11876348 kB
SwapFree: 11687616 kB
Dirty: 3508 kB
Writeback: 32 kB
AnonPages: 1873148 kB
Mapped: 197036 kB
Shmem: 18240 kB
Slab: 157916 kB
SReclaimable: 131452 kB
SUnreclaim: 26464 kB
KernelStack: 3928 kB
PageTables: 32140 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 13903760 kB
Committed_AS: 3427468 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 323536 kB
VmallocChunk: 34359412360 kB
HardwareCorrupted: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 272384 kB
DirectMap2M: 3919872 kB
CPU:total 2 (2 cores per cpu, 1 threads per core) family 6 model 23 stepping 10, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1
Memory: 4k page, physical 4054828k(176928k free), swap 11876348k(11687616k free)
vm_info: OpenJDK 64-Bit Server VM (19.0-b09) for linux-amd64 JRE (1.6.0_20-b20), built on Feb 23 2011 09:05:53 by "buildd" with gcc 4.4.5
time: Mon Jun 6 22:24:11 2011
elapsed time: 2076 seconds
As Stéphane says, try different JREs to see if you can get a different error message. There's a chance (but hard to quantify) that this is related to reaching a memory limit, but it'll be hard to be sure unless you do get an error saying which one!
Use sun/oracle java jdk, not the open jdk...
Regards,
Stéphane
Since it is most likely a bug in the JVM, the first thing I would try is updating your JVM to Java 6 update 25. You could try the Sun/Oracle JVM, but it likely to be the same.
I am assuming you are not using an JNI libraries?