Date: 2018-04-11 17:57:27 +0200
From: @PedroTadim
To: SQL devs <>
Version: -- development
CC: @kutsurak, @njnes

Last updated: 2018-08-31 13:23:13 +0200

Comment 26359

Date: 2018-04-11 17:57:27 +0200
From: @PedroTadim

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

On default branch, run the query bellow for an assertion error. My guess is that the MAL generation is not correct, thus generating a function call with a bulk implementation.

Reproducible: Always

Steps to Reproduce:

1. CREATE TABLE tab1(col0 INTEGER, col1 INTEGER, col2 INTEGER);
2. INSERT INTO tab1 VALUES(22,6,8), (28,57,45), (82,44,71);
3. SELECT ALL - 52 * + COALESCE ( + col2, + 47 / + 25 ) FROM tab1 AS cor0 GROUP BY cor0.col2, cor0.col2;

Actual Results:

Assertion error in mserver5: mal_scenario.c:552: runScenarioBody: Assertion `c->curprg->def->errors == NULL' failed.

Expected Results:

A single row with results -2340, -3692, -416

Log:
WARNING To speedup calc./ a bulk operator implementation is needed
X_290:bat[:bte] := mal.multiplex("calc":str, "/":str, 47:bte, 25:bte, X_288:bat[:oid]);
mserver5: mal_scenario.c:552: runScenarioBody: Assertion `c->curprg->def->errors == NULL' failed.

Backtrace:
0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
1 0x00007ffff4781c41 in __GI_abort () at abort.c:79
2 0x00007ffff4778f7a in __assert_fail_base (fmt=0x7ffff48c9260 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7ffff7b644e8 "c->curprg->def->errors == NULL",
file=file@entry=0x7ffff7b644d5 "mal_scenario.c", line=line@entry=552, function=function@entry=0x7ffff7b64560 <PRETTY_FUNCTION.11456> "runScenarioBody") at assert.c:92
3 0x00007ffff4778ff2 in __GI___assert_fail (assertion=0x7ffff7b644e8 "c->curprg->def->errors == NULL", file=0x7ffff7b644d5 "mal_scenario.c", line=552,
function=0x7ffff7b64560 <PRETTY_FUNCTION.11456> "runScenarioBody") at assert.c:101
4 0x00007ffff7a0dcc2 in runScenarioBody (c=0x7fffe973c368, once=0) at mal_scenario.c:552
5 0x00007ffff7a0ddad in runScenario (c=0x7fffe973c368, once=0) at mal_scenario.c:569
6 0x00007ffff7a0fcdf in MSserveClient (dummy=0x7fffe973c368) at mal_session.c:519
7 0x00007ffff7a0f7d4 in MSscheduleClient (command=0x7fffb0000b30 "0", challenge=0x7fffc72e1d9b "wd3NDp6N", fin=0x181ab40, fout=0x7fffc0002d90, protocol=PROTOCOL_9, blocksize=8190, compute_column_widths=0)
at mal_session.c:397
8 0x00007ffff7ab150e in doChallenge (data=0x181ab50) at mal_mapi.c:279
9 0x00007ffff7697240 in thread_starter (arg=0x9c8710) at gdk_system.c:476
10 0x00007ffff4b0950b in start_thread (arg=0x7fffc72e2700) at pthread_create.c:465
11 0x00007ffff484116f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Comment 26360

Date: 2018-04-11 17:58:39 +0200
From: MonetDB Mercurial Repository <>

Changeset 9f73e7e8a96b made by Pedro Ferreira pedro.ferreira@monetdbsolutions.com in the MonetDB repo, refers to this bug.

For complete details, see https//devmonetdborg/hg/MonetDB?cmd=changeset;node=9f73e7e8a96b

Changeset description:

Added test for bug #6575

Comment 26367

Date: 2018-04-14 18:56:06 +0200
From: MonetDB Mercurial Repository <>

Changeset 0e4c696bd1fe made by Niels Nes niels@cwi.nl in the MonetDB repo, refers to this bug.

For complete details, see https//devmonetdborg/hg/MonetDB?cmd=changeset;node=0e4c696bd1fe

Changeset description:

fixes for bug #6575