kernel: pid 74733 (netxmsd), uid 0: exited on signal 11 (core dumped)
Nothing else....
I have a corefile for you if you want but it's 122MB so you might not want it here.....
Try to get a stack backtrace from core (bt command in gdb).
Best regards,
Victor
never done this before so tell me if I did anything wrong.
Ran this:
Quotegdb /usr/local/netxms/bin/netxmsd /usr/local/netxms/share/netxms/netxmsd.core
bunch of text scrolls by..
Then did this and got following output:
Quote(gdb) bt
#0 0x288933cc in mysql_stmt_data_seek () from /usr/local/lib/mysql/libmysqlclient.so.18
#1 0x2825db80 in DrvGetField (hResult=0x28f04280, iRow=3, iColumn=0, pBuffer=0x29feb400, nBufSize=256) at mysql.cpp:661
#2 0x281b41b0 in DBGetFieldA (hResult=0x2d962870, iRow=3, iColumn=0, pszBuffer=0xbd7db970 "4683", nBufLen=256) at session.cpp:420
#3 0x281b4329 in DBGetField (hResult=0x2d962870, iRow=3, iColumn=0, pszBuffer=0xbd7db970 "4683", nBufLen=256) at session.cpp:407
#4 0x281b4571 in DBGetFieldULong (hResult=0x2d962870, iRow=3, iColumn=0) at session.cpp:470
#5 0x2813244a in ClientSession::getCollectedDataFromDB (this=0x2d830c00, request=0x2a1fccc0, response=0xbd7dbf64, dcTarget=0x28c6a000, dciType=1)
at session.cpp:3695
#6 0x28132c10 in ClientSession::getCollectedData (this=0x2d830c00, request=0x2a1fccc0) at session.cpp:3774
#7 0x28132c6e in ClientSession::ThreadStarter_getCollectedData (pArg=0x2e6f7be8) at session.cpp:138
#8 0x286e1f3a in pthread_getprio () from /lib/libthr.so.3
#9 0xb7175fec in ?? ()
Is this all you need?
oh and it's not incidental...
It happened 3 times today already..
trying to find the time to build a script to automaticly restart netxmsd because it keeps crashing.
Are all stack traces identical?
Best regards,
Victor
yes, mostly.
This is another one:
(gdb) bt
Quote#0 0x28892b56 in mysql_stmt_param_metadata () from /usr/local/lib/mysql/libmysqlclient.so.18
#1 0x28893222 in mysql_stmt_fetch () from /usr/local/lib/mysql/libmysqlclient.so.18
#2 0x2825db8b in DrvGetField (hResult=0x2c9d8b60, iRow=1, iColumn=0, pBuffer=0x2a496800, nBufSize=256) at mysql.cpp:662
#3 0x281b41b0 in DBGetFieldA (hResult=0x2b74f970, iRow=1, iColumn=0, pszBuffer=0xb7276970 "4235", nBufLen=256) at session.cpp:420
#4 0x281b4329 in DBGetField (hResult=0x2b74f970, iRow=1, iColumn=0, pszBuffer=0xb7276970 "4235", nBufLen=256) at session.cpp:407
#5 0x281b4571 in DBGetFieldULong (hResult=0x2b74f970, iRow=1, iColumn=0) at session.cpp:470
#6 0x2813244a in ClientSession::getCollectedDataFromDB (this=0x2ef70c00, request=0x2bbef200, response=0xb7276f64, dcTarget=0x28cca800, dciType=1) at session.cpp:3695
#7 0x28132c10 in ClientSession::getCollectedData (this=0x2ef70c00, request=0x2bbef200) at session.cpp:3774
#8 0x28132c6e in ClientSession::ThreadStarter_getCollectedData (pArg=0x29e9c078) at session.cpp:138
#9 0x286e1f3a in pthread_getprio () from /lib/libthr.so.3
#10 0xb6a6efec in ?? ()
It seems the server only crashes when I'm connected to it with the Windows Management Console.
Any suggestions on this?
Anything I can add to figure out what's wrong?
Hi!
There was another installation crashing in very similar way, on console connect, but on Windows. There problem was solved by replacing MySQL client library with latest version. Is there any updates for MySQL client?
Best regards,
Victor
no..
Using Mysql 5.6.16 server and client.
Nu updates on FreeBSD available
I could try a different version of MySQL.. 5.5 for instance...
My current DB is screwed because of the many crashes anyway..
Yes, please try MySQL 5.5. Also, I'll prepare test update later today - I've found some potentially problematic places in our MySQL driver.
Best regards,
Victor
Please try this version: https://www.dropbox.com/s/rft98tv0ahnekv6/netxms-1.2.12.tar.gz (https://www.dropbox.com/s/rft98tv0ahnekv6/netxms-1.2.12.tar.gz). Note that it will upgrade your database, you won't be able to go back to 1.2.11, so do backup first.
Best regards,
Victor
Building it right now..
I'll let you know,
Still on MySQL-5.6 btw.
Just in case it's helpfull:
Quote---------------------------------------------------------------------
Configure results
---------------------------------------------------------------------
Prefix : /usr/local/netxms
Platform : FreeBSD
Shared library suffix : .so
Build Server : YES
Server libs : -lssl -ltermcap -lreadline
XMPP support : YES
Encryption enabled : YES
Build DB-Drivers : mysql
Build Clients : NO
Build Agent : YES
Subagents list : freebsd netsvc
Build Static Agent : NO
UNICODE build : NO
Use internal libexpat : NO
Use internal libtre : YES
Use internal zlib : NO
Force 32bit build : NO
C compiler : gcc
C++ compiler : g++
CPPFLAGS : -D_THREAD_SAFE -DTRE_WCHAR=1 -I/usr/local/mysql/include -I/usr/include/mysql -I/usr/mysql/include -I/usr/local/include/mysql -I/usr/local/mysql/include/mysql -I/usr/mysql/include/mysql -I/opt/openssl/include -Wformat -I/usr/local/include -DPREFIX=\"${prefix}\" -DDATADIR=\"${pkgdatadir}\" -DBINDIR=\"${bindir}\" -DLIBDIR=\"${libdir}\" -DPKGLIBDIR=\"${pkglibdir}\"
CXXFLAGS : -g -O2 -fno-rtti -fno-exceptions
CFLAGS : -g -O2
LDFLAGS : -L/usr/local/mysql/lib -L/usr/lib64/mysql -L/usr/lib/mysql -L/usr/mysql/lib -L/usr/local/lib/mysql -L/usr/local/mysql/lib/mysql -L/usr/mysql/lib/mysql -L/usr/local/lib -L/opt/openssl/lib -L/usr/local/lib
LIBS : -lkvm -lexpat -lz -pthread -lcrypto -liconv
MySQL libs : -lmysqlclient
So far so good, normally it would have crashed a few times by now..
Still using the 1.2.11 client btw. I do not have the knowledge and resources to compile the client for windows.
The build error on SQLite is gone too, great job :)
[Update]
I don't know what you fixed exactly but it did the job! Not a single crash anymore since I installed 1.2.12!
Nice to hear! This crash was one of the strangest problems I had to debug with NetXMS - different platforms, crashes differently, only one thing in common - MySQL backend...
As for what I've fixed - I add a mutex around calls to mysql_stmt_data_seek and mysql_stmt_fetch. Under some conditions two threads call them on different statements, but same MySQL connection. I was thinking that because I'm using mysql_stmt_store_result to cache statement result locally, they are independent, but seems they are not.
Best regards,
Victor