getBoksMacs is sometimes, but not always, segfaulting and we need some hints about debugging.
From getBoksMacs.log it seems that i it crashes early, right after reading the
database:
Jun 10 11:03:35 2009 getBoksData null-5-INIT ============ getBoksData starting ============ Jun 10 11:03:35 2009 getBoksData null-5-INIT Running with 12 threads. Could not read watchMacs.conf Dumping data from tables... netboxmac...15514 ms. boks...154 ms. swport...300 ms. swportblocked...1194 ms. vlan...560 ms. swp_boks...27 ms. OID db...363 ms. # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x000000080102edc6, pid=446, tid=0x1832780 # # Java VM: Diablo Java HotSpot(TM) 64-Bit Server VM (10.0-b23 mixed mode bsd-amd64) # Problematic frame: # V [libjvm.so+0x52edc6] # # An error report file with more information is saved as: # /usr/local/nav/lib/java/getBoksMacs/hs_err_pid446.log
Sometimes it also manage to write the line "cam... XXXms."
The error report is attached.
If the script gets past this point without crashing it runs without problems. We have tried to vary the number of threads without seeing any difference.
OS: FreeBSD 7.1-RELEASE-p5 amd64 Java: diablo-jdk-1.6.0.07.02_5 Java Development Kit 1.6.0_07.02
--Ingeborg
On Wed, 10 Jun 2009 11:18:47 +0200 Ingeborg Hellemo Ingeborg.Hellemo@uit.no wrote:
getBoksMacs is sometimes, but not always, segfaulting and we need some hints about debugging.
From getBoksMacs.log it seems that i it crashes early, right after reading the database:
[snip]
This is the native JVM crashing. I really have no idea why, but it appears to be segfaulting during garbage collection.
The JVM seems to be running in server mode by default (I assume because of the machine having multiple cores or CPUs) - you could try running it explicitly in client mode to see if it makes any difference. Alter JVM_OPTS_GETBOKSMACS in nav.conf to include the "-client" option.
Nonetheless, this problem should be reported to your JVM vendor.
-
Ingeborg Hellemo -
Morten Brekkevold