Last updated: 2013-03-07 12:41:23 +0100
Date: 2013-02-21 13:25:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17
Unfortunately it is not easy to make this issue reproducible.
I got the issue on a query that looks like this:
CREATE TABLE "_attributesString" (
SELECT subject, attribute, value, MAX(prob) as prob FROM "_attributesString" GROUP BY subject, attribute, value;
However, the failure is data-dependent and the data that triggers the failure is produced inside an iterative process.
I got two types of error, depending on the data at hand:
An assertion: gdk/gdk_group.c:482: BATgroup_internal: Assertion `hs->link[hb] == ((BUN) 9223372036854775807LL) || hs->link[hb] < hb' failed.
And a SEGFAULT (I am relatively sure this happens when evaluating the same query):
Program received signal SIGSEGV, Segmentation fault.
MonetDB 5 server v11.15.2 (64-bit, 64-bit oids)
Date: 2013-02-21 14:13:17 +0100
This is the assertion that our hashes link backwards. Apparently they don't always.
Roberto, when this happens in the debugger, can you print both hb and hs->link[hb]?
Date: 2013-02-21 14:37:54 +0100
(gdb) p hb
A bit more context:
0 0x0000003598c328f5 in raise () from /lib64/libc.so.6
Date: 2013-02-21 14:56:05 +0100
It would be interesting to know how the bat (the first argument to the MAL function) got its hash table. Do you know?
The simple solution would be to not depend on the supposed fact that the linked list in the hash table always point towards lower BUNs. But it would be interesting where in the code that supposition is broken.
Date: 2013-02-21 15:06:02 +0100
Unfortunately I have difficulties getting the MAL plan of the failing transaction.
Date: 2013-02-22 11:06:56 +0100
For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=88acc1bec9c7
Date: 2013-02-22 11:07:20 +0100
Roberto, can you test please.
Date: 2013-02-22 13:35:41 +0100
The problem seems indeed solved, thanks!
Date: 2013-02-22 15:31:59 +0100
The SEGFAULT mentioned in the initial bug report is apparently not (directly) related to the bug fix, as it still occurs (changing the bug title accordingly).
Date: 2013-02-22 15:49:43 +0100
Can you then submit a fresh bug report for the segfault?
Date: 2013-02-23 00:06:32 +0100
Does that segfault also occur with assertions enabled?
Date: 2013-02-25 10:07:44 +0100
Stefan, I will try that.
What I found so far is that the SEGFAULT does not seem to be related to grouping at all.
I have reduced it now to a simple selection on a view with an user function that does string processing (pcre). But again, it seems data-dependent, so I will file a bug report as soon as I can make it somewhat reproducible (unfortunately I am not allowed to share the whole data as they are).
Date: 2013-02-25 10:17:53 +0100
Now that I think about it, I am compiling as developer, so assertions are enabled:
--enable-strict --enable-assert --enable-debug --disable-optimize
Date: 2013-03-07 12:41:23 +0100
Feb2013-SP1 has been released.
The text was updated successfully, but these errors were encountered: