Date: 2012-06-21 13:02:31 +0200
From: @swingbit
To: Merovingian devs <>
Version: 11.11.5 (Jul2012)

Last updated: 2012-08-23 10:14:38 +0200

Comment 17379

Date: 2012-06-21 13:02:31 +0200
From: @swingbit

User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.39 Safari/536.11
Build Identifier: Apr2012

If mserver5 was killed or had crashed before the SQL log could be flushed, the next startup will first check the log. If one mclient connection wakes up the server after it had died, this works correctly. If two mclient sessions arrive almost at the same time, this fails.

Reproducible: Sometimes

Steps to Reproduce:

1. Source the bash script in attachment after customizing port and database name
2. Occasionally, the test succeeds. Most of the times, though, it fails

Actual Results:

A mixture of the following:

• both mclient sessions succeed
• both mclient sessions fail with "Connection terminated"
• one succeeds, one fails

Expected Results:

Both mclient sessions succeed

$ mserver5 --version
MonetDB 5 server v11.7.10 (64-bit, 64-bit oids)
This is an unreleased version
Copyright (c) 1993-July 2008 CWI
Copyright (c) August 2008-2012 MonetDB B.V., all rights reserved
Visit http://www.monetdb.org/ for further information
Found 35.5GiB available memory, 8 available cpu cores
Libraries:
libpcre: 7.8 2008-09-05 (compiled with 7.8)
openssl: OpenSSL 1.0.0d 8 Feb 2011 (compiled with OpenSSL 1.0.0d-fips 8 Feb 2011)
libxml2: 2.7.7 (compiled with 2.7.7)
Compiled by: roberto@spinque01.ins.cwi.nl (x86_64-unknown-linux-gnu)
Compilation: gcc -g -Werror -Wall -Wextra -W -Werror-implicit-function-declaration -Wpointer-arith -Wdeclaration-after-statement -Wformat=2 -Wno-format-nonliteral -Winit-self -Winvalid-pch -Wmissing-declarations -Wmissing-format-attribute -Wmissing-prototypes -Wold-style-definition -Wpacked -Wunknown-pragmas -Wvariadic-macros -fstack-protector-all -Wstack-protector -Wpacked-bitfield-compat -Wsync-nand -Wmissing-include-dirs -Wp,-D_FORTIFY_SOURCE=2
Linking : /usr/bin/ld -m elf_x86_64

Comment 17380

Date: 2012-06-21 13:03:49 +0200
From: @swingbit

Created attachment 120
Bash script to to reproduce the bug

Attached file: recover_crash.bash (application/octet-stream, 736 bytes)
Description: Bash script to to reproduce the bug

Comment 17383

Date: 2012-06-26 10:34:15 +0200
From: @sjoerdmullender

I cannot reproduce this. Can you try it on an up-to-date release (at least Apr2012 branch)?

Comment 17500

Date: 2012-07-18 11:02:20 +0200
From: @grobian

This is a bug in monetdbd, next to a bug in mserver5 which apparently doesn't protect itself good enough. monetdbd in the first place should know better and make sure it only starts an mserver5 only once at the same time.

Comment 17508

Date: 2012-07-18 16:00:36 +0200
From: @grobian

Changeset fc516173a646 made by Fabian Groffen fabian@cwi.nl in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=fc516173a646

Changeset description:

forkmserver: fix possible race condition when starting mservers

As reported in bug #3107, when multiple clients would trigger monetdbd
to auto-start an mserver at the same time, monetdbd could wrongly start
forking mserver5's for the same database, obviously with failing
behaviour as a result.

This is now resolved by using a global lock for forkmserver when it
figures out it really needs to fork an mserver5 process.  Multiple
concurrent clients would in this case block, and have to re-evaluate
whether they still need to start an mserver5 or not in serial order.

Upside of this fix, is that successive connects to a database should be
slightly faster now, as a shortcut is taken when the database already
appears to be running, avoiding expensive calls which results aren't
used.

Comment 17639

Date: 2012-08-23 10:14:38 +0200
From: @sjoerdmullender

Jul2012-SP1 has been released.