You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier:
The attach00.mal test generates
!FATAL: BATpropcheck: BAT tmp_365(245) has inconsistent descriptor 65536 (200000)
The reason seems that the BAT descriptor in BBP.dir contains the initial
capacity 256 after BAT.save, while the file itself has only size equal
to the number of entries stored (GDKsave does not look at capacity, only
the free pointer)
A retrofitting patch in attach could avoid it, but it may be indicative for
a more serious error. Being triggered in other circumstances as well.
Probably the main cause of errors for this bug was that there weren't enough consistency checks. For instance, a call to lstat wasn't checked (it failed) but the "result" (the struct stat buffer) was used anyway.
I think the test should be reconsidered. As is, the BAT being attached was not saved to disk at the time of the attach. This now causes the attach to fail, but that may not be the purpose of the test.
Date: 2010-12-12 19:51:53 +0100
From: @mlkersten
To: MonetDB5 devs <>
Version: 11.9.7 (Apr2012-SP2) [obsolete]
Last updated: 2012-07-17 14:53:01 +0200
Comment 15337
Date: 2010-12-12 19:51:53 +0100
From: @mlkersten
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier:
The attach00.mal test generates
!FATAL: BATpropcheck: BAT tmp_365(245) has inconsistent descriptor 65536 (200000)
The reason seems that the BAT descriptor in BBP.dir contains the initial
capacity 256 after BAT.save, while the file itself has only size equal
to the number of entries stored (GDKsave does not look at capacity, only
the free pointer)
A retrofitting patch in attach could avoid it, but it may be indicative for
a more serious error. Being triggered in other circumstances as well.
print *b->T
$14 = {id = 0x7ffff68471db "t", width = 4, type = 6 '\006', shift = 2 '\002', sorted = 0 '\000', varsized = 0 '\000', key = 0 '\000', dense = 0 '\000', nonil = 1 '\001', nil = 0 '\000', unused = 0 '\000',
align = 1001234, nosorted_rev = 0, nokey = {2, 3}, nosorted = 3, nodense = 0, seq = 0, heap = {maxsize = 8, free = 8, size = 8, base = 0xd534d8 "\001", filename = 0xac66c8 "03/365.tail",
storage = 0 '\000', copied = 0 '\000', hashash = 0 '\000', forcemap = 0 '\000', newstorage = 0 '\000', dirty = 0 '\000', parentid = 0}, vheap = 0x0, hash = 0x0, props = 0x0}
(gdb) print *b->U
$15 = {deleted = 0, first = 0, inserted = 0, count = 21, capacity = 256}
Upon reload this triggers the fatal.
Reproducible: Always
Comment 15884
Date: 2011-07-04 15:26:14 +0200
From: @sjoerdmullender
Changeset 1ed011aa3aec made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.
For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=1ed011aa3aec
Changeset description:
Comment 15885
Date: 2011-07-04 15:29:25 +0200
From: @sjoerdmullender
Probably the main cause of errors for this bug was that there weren't enough consistency checks. For instance, a call to lstat wasn't checked (it failed) but the "result" (the struct stat buffer) was used anyway.
I think the test should be reconsidered. As is, the BAT being attached was not saved to disk at the time of the attach. This now causes the attach to fail, but that may not be the purpose of the test.
Comment 16019
Date: 2011-07-29 10:58:42 +0200
From: @sjoerdmullender
Apr2011-SP2 has been released.
Comment 16074
Date: 2011-08-05 14:00:45 +0200
From: @sjoerdmullender
This is now a MonetDB5 problem: the test is not correct.
Comment 16264
Date: 2011-09-16 15:09:13 +0200
From: @sjoerdmullender
The Aug2011 version has been released.
Comment 17492
Date: 2012-07-17 14:53:01 +0200
From: @grobian
this sounds like fixed to me
The text was updated successfully, but these errors were encountered: