Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MT_msync failed with "Cannot allocate memory" #6191

monetdb-team opened this issue Nov 30, 2020 · 0 comments

MT_msync failed with "Cannot allocate memory" #6191

monetdb-team opened this issue Nov 30, 2020 · 0 comments


Copy link

@monetdb-team monetdb-team commented Nov 30, 2020

Date: 2017-01-23 14:52:23 +0100
From: @yzchang
To: GDK devs <>
Version: 11.25.3 (Dec2016)

Last updated: 2017-03-03 10:24:29 +0100

Comment 24902

Date: 2017-01-23 14:52:23 +0100
From: @yzchang

With the following queries:

create table bug1 (hit uuid, has_contributed boolean, parent_hit uuid);
insert into bug1 (hit, has_contributed, parent_hit) values ('16caf284-7fa2-4402-8e8a-5e89c644d23a', true, '16caf284-7fa2-4402-8e8a-5e89c644d23a');
insert into bug1 (hit, has_contributed, parent_hit) select * from bug1;

If one repeats the last INSERT INTO query several times to insert more tuples into "bug1", at some moment (after ~8K tuples have been inserted), mserver5 will report:

!ERROR: MT_msync: msync failed
!OS: Cannot allocate memory

after the transaction has succeeded.

The error seems to have been caused by that a point, which is not memory-mapped, was past to MY_msync.
The msync() call returns ENOMEM.

Comment 24903

Date: 2017-01-23 15:26:38 +0100
From: MonetDB Mercurial Repository <>

Changeset 6e108baf7828 made by Sjoerd Mullender in the MonetDB repo, refers to this bug.

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

Changeset description:

Don't call msync with a length argument that is too long.
In fact, don't do all this complicated stuff to calculate start
address and length, just pass the unaltered heap base as start
address, and the occupied size of the heap as the length.
This should fix bug #6191.

Comment 24904

Date: 2017-01-23 15:30:18 +0100
From: @sjoerdmullender

This was a fairly benign bug. The msync was sometimes called with a "length" parameter which was too large. This resulted in the system call returning an error (ENOMEM) after it had done the work for the valid area. The fix was to not try to round the values for the arguments but to just pass the actual values for the start and size of heap.

Comment 25118

Date: 2017-03-03 10:24:29 +0100
From: @sjoerdmullender

Dec2016-SP2 has been released, incorporating the fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant