In most cases, the system produces informative error messages. However, there are situations where MonetDB enters an area not covered by the test suite or previous use and a segmentation fault occurs. These cases are hard to analyze outside the development lab. To isolate and resolve the issue we need at least the following information.
Sent us the result of the command mserver5 --version --dbname=<databasename> or the equivalent using monetdb --version <databasename>
Is the error reproducible with a small (5-10 line) script/query/program? Trim your experiment to the minimal size that demonstrates the erroneous behavior. Such a script is the best we can hope for, because it will end up in the nightly testing.
In addition, follow the steps, assuming that you are logged onto the same Linux (!) machine as where the server will run:
- Sent the tail of the merovingian log (100 lines) located in the dbfarm directory.
- Start the database server either with monetdb or as a full command line mserver --dbinit="..." .
- Lookup the process id for this server using the command ps -al |grep mserver5
- Attach the debugger with gdb mserver5 <processid>
- Run your experiment again until it hits the segmentation fault, which you see emerging in window.
- Then obtain a stack trace with the command where. It shows of the context of the crash using the list command and the variables used in the context of the crash.
- Collect the status of all threads using the command thr app all bt.