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

Prepared statement rel_bin.c:2378: rel2bin_project: Assertion `0' failed. #3974

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


Copy link

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

Date: 2016-04-05 14:43:20 +0200
From: Richard Hughes <<richard.monetdb>>
To: SQL devs <>
Version: 11.21.17 (Jul2015-SP3)
CC: @njnes

Last updated: 2016-06-23 10:24:43 +0200

Comment 22011

Date: 2016-04-05 14:43:20 +0200
From: Richard Hughes <<richard.monetdb>>

Build is Jul2015 5126d5e2f869

To reproduce:

sql>create table foo (a int, b int);
sql>prepare select count(b) from (select a,b from foo union all select null,null from foo) t;

Expected result:

A preparation response.

Actual result (from a debug build):

could not find L1.L1
mserver5: rel_bin.c:2378: rel2bin_project: Assertion `0' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffee59f700 (LWP 6905)]
0x00007ffff5a32067 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
0 0x00007ffff5a32067 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
1 0x00007ffff5a33448 in __GI_abort () at abort.c:89
2 0x00007ffff5a2b266 in _assert_fail_base (
fmt=0x7ffff5b64528 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x7fffefe48485 "0",
file=file@entry=0x7fffefe4847b "rel_bin.c", line=line@entry=2378,
function=function@entry=0x7fffefe48b20 <PRETTY_FUNCTION.13373> "rel2bin

project") at assert.c:92
3 0x00007ffff5a2b312 in __GI___assert_fail (assertion=0x7fffefe48485 "0",
file=0x7fffefe4847b "rel_bin.c", line=2378,
function=0x7fffefe48b20 <PRETTY_FUNCTION.13373> "rel2bin_project")
at assert.c:101
4 0x00007fffefcd63c9 in rel2bin_project (sql=0x7fffe400ec10,
rel=0x7fffe40cc510, refs=0x7fffe40cec30, topn=0x0) at rel_bin.c:2378
5 0x00007fffefce0a8b in subrel_bin (sql=0x7fffe400ec10, rel=0x7fffe40cc510,
refs=0x7fffe40cec30) at rel_bin.c:4580
6 0x00007fffefcd72ba in rel2bin_groupby (sql=0x7fffe400ec10,
rel=0x7fffe40ce1d0, refs=0x7fffe40cec30) at rel_bin.c:2573
7 0x00007fffefce0ae7 in subrel_bin (sql=0x7fffe400ec10, rel=0x7fffe40ce1d0,
refs=0x7fffe40cec30) at rel_bin.c:4588
8 0x00007fffefcd4906 in rel2bin_union (sql=0x7fffe400ec10,
rel=0x7fffe40ce4b0, refs=0x7fffe40cec30) at rel_bin.c:2053
9 0x00007fffefce09ff in subrel_bin (sql=0x7fffe400ec10, rel=0x7fffe40ce4b0,
refs=0x7fffe40cec30) at rel_bin.c:4568
10 0x00007fffefcd72ba in rel2bin_groupby (sql=0x7fffe400ec10,
rel=0x7fffe40cc8a0, refs=0x7fffe40cec30) at rel_bin.c:2573
11 0x00007fffefce0ae7 in subrel_bin (sql=0x7fffe400ec10, rel=0x7fffe40cc8a0,
refs=0x7fffe40cec30) at rel_bin.c:4588
12 0x00007fffefcd62bb in rel2bin_project (sql=0x7fffe400ec10,
rel=0x7fffe40cca20, refs=0x7fffe40cec30, topn=0x0) at rel_bin.c:2363
13 0x00007fffefce0a8b in subrel_bin (sql=0x7fffe400ec10, rel=0x7fffe40cca20,
refs=0x7fffe40cec30) at rel_bin.c:4580
14 0x00007fffefce0dc7 in output_rel_bin (sql=0x7fffe400ec10,
rel=0x7fffe40cca20) at rel_bin.c:4648
15 0x00007fffefc9989f in sql_relation2stmt (c=0x7fffe400ec10,
r=0x7fffe40cca20) at sql.c:134
16 0x00007fffefcc09f4 in SQLparser (c=0x7ffff0fd7328) at sql_scenario.c:1184
17 0x00007ffff792856a in runPhase (c=0x7ffff0fd7328, phase=1)
at mal_scenario.c:515
18 0x00007ffff7928705 in runScenarioBody (c=0x7ffff0fd7328)
at mal_scenario.c:550
19 0x00007ffff79288a8 in runScenario (c=0x7ffff0fd7328) at mal_scenario.c:579
20 0x00007ffff792a353 in MSserveClient (dummy=0x7ffff0fd7328)
at mal_session.c:439
21 0x00007ffff7929d4e in MSscheduleClient (command=0x7fffe40008d0 "0",
challenge=0x7fffee59ee70 "uKYg5NLETOO", fin=0x7fffe4006b40,
fout=0x7fffe40049c0) at mal_session.c:319
22 0x00007ffff7a1b6f7 in doChallenge (data=0x7fffe00008d0) at mal_mapi.c:184
23 0x00007ffff732f363 in thread_starter (arg=0x7fffe0000a50)
at gdk_system.c:458
24 0x00007ffff5db00a4 in start_thread (arg=0x7fffee59f700)
at pthread_create.c:309
25 0x00007ffff5ae587d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

A release build silently gives no result to the query. The query works fine when executed in a non-prepared way, producing the expected zero cell.

Comment 22016

Date: 2016-04-06 12:31:20 +0200
From: @njnes

fixed, the relational optimizer renamed expressions incorrectly.

Comment 22017

Date: 2016-04-06 12:32:35 +0200
From: MonetDB Mercurial Repository <>

Changeset dca3d2f676ed made by Niels Nes in the MonetDB repo, refers to this bug.

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

Changeset description:

fixed bug #3974, ie rename expression properly
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