When the server goes astray, causing a crash, then it becomes time to run the system in debugging mode or dive into a possible core file left behind.
The minimal information to be provided in the first report are:
To inspect the system yourself, make sure you have compiled the system with --DEBUGGING=ON. This way gives you more information when the server is run under control of say Linux GDB debugger.
To make it work, go to the 'dbfarm' directory and select the database you want to monitor, say 'demo'. Make sure there is no server running for 'demo', e.g. apply 'monetdb stop demo'. Thereafter we can start the server identifying the database directory, the vault for authentication, and the port it should listens to.
gdb --args mserver5 --dbpath=`pwd`/demo --set monet-vault-key=demo/.vaultkey --set mapi-port=51000
Subsequently you can run your JDBC or ODBC application or directly try out the malicious queries with mclient. Turn off the MonetDB daemon process if you are relying on the default port 50000 to access the server.
A repeatable crash on the released code should be shared with the developers.