Hi!
We are facing a problem with MERGE Tables.
We have a process in php which connects to the DB using the mapi ( https://www.monetdb.org/Documentation/Manuals/SQLreference/Programming/MAPI https://www.google.com/url?q=https%3A%2F%2Fwww.monetdb.org%2FDocumentation%2FManuals%2FSQLreference%2FProgramming%2FMAPI&sa=D&sntz=1&usg=AFQjCNGpR9jSaQKxbmqRuVF8krphUQBn1g )
The process creates a new table everyday as follows: CREATE TABLE cub8_20160717 AS (SELECT * FROM cub8) WITH NO DATA;
Then, attaches that new table to the MERGE table called cub8_cubo as follows: ALTER TABLE cub8_cubo ADD TABLE cub8_20160717 ;
Once all this is created, it start inserting data.
Everything works fine, with NO errors. BUT if I run a query against cub8_cubo I dont see cub8_20160717 data.
So I run this query in order to check if the new table was attached to the merge: SELECT a.name, b.name, s.name FROM sys.tables as a JOIN sys.dependencies d ON a.id = d.depend_id JOIN sys.tables as b ON b.id= d.id JOIN sys.schemas as s ON a.schema_id = s.id WHERE a.type= 3 AND a.name ILIKE '%cub8%' ORDER BY 1,2;
+-----------+---------------+ | name | name | +===========+===============+ | cub8_cubo | cub8_20160710 | | cub8_cubo | cub8_20160711 | | cub8_cubo | cub8_20160712 | | cub8_cubo | cub8_20160713 | | cub8_cubo | cub8_20160714 | | cub8_cubo | cub8_20160715 | | cub8_cubo | cub8_20160716 | | cub8_cubo | cub8_20160717 |
So I try to detached from cub8_cubo, with the command: ALTER TABLE cub8_cubo DROP TABLE cub8_20160717;
ALTER TABLE: table 'sb_traf.cub8_20160717' isn't part of the MERGE TABLE 'sb_traf.cub8_cubo'
So I ADD it again: ALTER TABLE cub8_cubo ADD TABLE cub8_20160717;
and now yes... I can see the data. If I need to detach that table, I need to run ALTER ... DROP twice or three times to get it done.
It seems to be a bug?, are we doing something wrong ??
Thks in advance!
*PS.:We are using * *MonetDB Database Server v1.7 (Jun2016)*
*Welcome to mclient, the MonetDB/SQL interactive terminal (Jun2016)*
We are having a serious problem. Every time the DB starts doing crazy things with the MERGE tables (as described in the email attached). The DB crashes for ever.
2016-07-17 23:51:29 MSG merovingian[10151]: database 'trafico' (10165) was killed by signal SIGSEGV 2016-07-17 23:51:29 ERR control[10151]: (local): failed to fork mserver: database 'trafico' appears to shut itself down after starting, check monetdbd's logfile for possible hints 2016-07-17 23:52:16 MSG merovingian[10151]: caught SIGTERM, starting shutdown sequence 2016-07-17 23:52:19 MSG merovingian[10151]: Merovingian 1.7 stopped 2016-07-17 23:52:19 MSG control[10151]: control channel closed
The only way to recover is creating a newly fresh DBFARM.
If anyone knows something please help me!. We are creating the DB every week :(
*Ariel Abadi* Direct: +54 11 5279.2054 Mobile:+54 9 11 6050.0101 Email: aabadi@starconnecting.com Web: www.starconnecting.com
On Sun, Jul 17, 2016 at 8:09 PM, Ariel Abadi aabadi@starconnecting.com wrote:
Hi!
We are facing a problem with MERGE Tables.
We have a process in php which connects to the DB using the mapi ( https://www.monetdb.org/Documentation/Manuals/SQLreference/Programming/MAPI https://www.google.com/url?q=https%3A%2F%2Fwww.monetdb.org%2FDocumentation%2FManuals%2FSQLreference%2FProgramming%2FMAPI&sa=D&sntz=1&usg=AFQjCNGpR9jSaQKxbmqRuVF8krphUQBn1g )
The process creates a new table everyday as follows: CREATE TABLE cub8_20160717 AS (SELECT * FROM cub8) WITH NO DATA;
Then, attaches that new table to the MERGE table called cub8_cubo as follows: ALTER TABLE cub8_cubo ADD TABLE cub8_20160717 ;
Once all this is created, it start inserting data.
Everything works fine, with NO errors. BUT if I run a query against cub8_cubo I dont see cub8_20160717 data.
So I run this query in order to check if the new table was attached to the merge: SELECT a.name, b.name, s.name FROM sys.tables as a JOIN sys.dependencies d ON a.id = d.depend_id JOIN sys.tables as b ON b.id= d.id JOIN sys.schemas as s ON a.schema_id = s.id WHERE a.type= 3 AND a.name ILIKE '%cub8%' ORDER BY 1,2;
+-----------+---------------+ | name | name | +===========+===============+ | cub8_cubo | cub8_20160710 | | cub8_cubo | cub8_20160711 | | cub8_cubo | cub8_20160712 | | cub8_cubo | cub8_20160713 | | cub8_cubo | cub8_20160714 | | cub8_cubo | cub8_20160715 | | cub8_cubo | cub8_20160716 | | cub8_cubo | cub8_20160717 |
So I try to detached from cub8_cubo, with the command: ALTER TABLE cub8_cubo DROP TABLE cub8_20160717;
ALTER TABLE: table 'sb_traf.cub8_20160717' isn't part of the MERGE TABLE 'sb_traf.cub8_cubo'
So I ADD it again: ALTER TABLE cub8_cubo ADD TABLE cub8_20160717;
and now yes... I can see the data. If I need to detach that table, I need to run ALTER ... DROP twice or three times to get it done.
It seems to be a bug?, are we doing something wrong ??
Thks in advance!
*PS.:We are using * *MonetDB Database Server v1.7 (Jun2016)*
*Welcome to mclient, the MonetDB/SQL interactive terminal (Jun2016)*
Can you run a server built from source with debugging enabled? When I was having problems with MERGE tables, that was the only way to figure out what was going wrong. It sounds like you have a reproducible test case.
From: users-list [mailto:users-list-bounces+david.b.anderson=citi.com@monetdb.org] On Behalf Of Ariel Abadi Sent: Sunday, July 17, 2016 11:22 PM To: Communication channel for MonetDB users Subject: Re: MERGE TABLE ERROR
We are having a serious problem. Every time the DB starts doing crazy things with the MERGE tables (as described in the email attached). The DB crashes for ever.
2016-07-17 23:51:29 MSG merovingian[10151]: database 'trafico' (10165) was killed by signal SIGSEGV 2016-07-17 23:51:29 ERR control[10151]: (local): failed to fork mserver: database 'trafico' appears to shut itself down after starting, check monetdbd's logfile for possible hints 2016-07-17 23:52:16 MSG merovingian[10151]: caught SIGTERM, starting shutdown sequence 2016-07-17 23:52:19 MSG merovingian[10151]: Merovingian 1.7 stopped 2016-07-17 23:52:19 MSG control[10151]: control channel closed
The only way to recover is creating a newly fresh DBFARM.
If anyone knows something please help me!. We are creating the DB every week :(
Ariel Abadi Direct: +54 11 5279.2054 Mobile:+54 9 11 6050.0101 Email: aabadi@starconnecting.commailto:aabadi@starconnecting.com Web: www.starconnecting.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__www.starconnecting.com&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=F97qUo-qi7nXgmnzI_zs_JPUY1_Gdbuxk73xGr75Kik&e=
On Sun, Jul 17, 2016 at 8:09 PM, Ariel Abadi <aabadi@starconnecting.commailto:aabadi@starconnecting.com> wrote: Hi!
We are facing a problem with MERGE Tables.
We have a process in php which connects to the DB using the mapi (https://www.monetdb.org/Documentation/Manuals/SQLreference/Programming/MAPIhttps://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_url-3Fq-3Dhttps-253A-252F-252Fwww.monetdb.org-252FDocumentation-252FManuals-252FSQLreference-252FProgramming-252FMAPI-26sa-3DD-26sntz-3D1-26usg-3DAFQjCNGpR9jSaQKxbmqRuVF8krphUQBn1g&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=TCBRhMVJpBqohBAbnbUVvgYKPiKFqjtu1E5YpbJopNU&e=)
The process creates a new table everyday as follows: CREATE TABLE cub8_20160717 AS (SELECT * FROM cub8) WITH NO DATA;
Then, attaches that new table to the MERGE table called cub8_cubo as follows: ALTER TABLE cub8_cubo ADD TABLE cub8_20160717 ;
Once all this is created, it start inserting data.
Everything works fine, with NO errors. BUT if I run a query against cub8_cubo I dont see cub8_20160717 data.
So I run this query in order to check if the new table was attached to the merge: SELECT a.namehttps://urldefense.proofpoint.com/v2/url?u=http-3A__a.name&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=ZnIDaE5j_yUr6kSrOOE4Cq3warOfS07K_mIaeOwegkM&e=, b.namehttps://urldefense.proofpoint.com/v2/url?u=http-3A__b.name&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=_JclMJpcqhsINlwHeS8ktjB0_9RuNyYUbZ-cWZjugP0&e=, s.namehttps://urldefense.proofpoint.com/v2/url?u=http-3A__s.name&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=8ilEeDdElFocGAbnSPq-W29d3JFq16BYH0toUBKbg7E&e= FROM sys.tables as a JOIN sys.dependencies d ON a.idhttps://urldefense.proofpoint.com/v2/url?u=http-3A__a.id&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=1_-oTcb5B--YfIwGbvdu9ZiQDpG7hiPmu0AT4pTkvCA&e= = d.depend_id JOIN sys.tables as b ON b.idhttps://urldefense.proofpoint.com/v2/url?u=http-3A__b.id&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=ys7CybxwWMK332gjlTpc32DRDwp5s0jYgVCOHCCqKJU&e== d.idhttps://urldefense.proofpoint.com/v2/url?u=http-3A__d.id&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=N4PPkvTlKUfkg02qExjB4obAPJlr8-MBAEY0eFDAD10&e= JOIN sys.schemas as s ON a.schema_id = s.idhttps://urldefense.proofpoint.com/v2/url?u=http-3A__s.id&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=6dEMFdZ5wFejqBuipNcFWMuLaLfKkE5ifGCPSlIcC9o&e= WHERE a.type= 3 AND a.namehttps://urldefense.proofpoint.com/v2/url?u=http-3A__a.name&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=ZnIDaE5j_yUr6kSrOOE4Cq3warOfS07K_mIaeOwegkM&e= ILIKE '%cub8%' ORDER BY 1,2;
+-----------+---------------+ | name | name | +===========+===============+ | cub8_cubo | cub8_20160710 | | cub8_cubo | cub8_20160711 | | cub8_cubo | cub8_20160712 | | cub8_cubo | cub8_20160713 | | cub8_cubo | cub8_20160714 | | cub8_cubo | cub8_20160715 | | cub8_cubo | cub8_20160716 | | cub8_cubo | cub8_20160717 |
So I try to detached from cub8_cubo, with the command: ALTER TABLE cub8_cubo DROP TABLE cub8_20160717;
ALTER TABLE: table 'sb_traf.cub8_20160717' isn't part of the MERGE TABLE 'sb_traf.cub8_cubo'
So I ADD it again: ALTER TABLE cub8_cubo ADD TABLE cub8_20160717;
and now yes... I can see the data. If I need to detach that table, I need to run ALTER ... DROP twice or three times to get it done.
It seems to be a bug?, are we doing something wrong ??
Thks in advance!
PS.:We are using MonetDB Database Server v1.7 (Jun2016) Welcome to mclient, the MonetDB/SQL interactive terminal (Jun2016)
Finally I make it to start it on debugger...
Here is the trace... Can someone help us ? Thks in advance!
gdb --args /usr/local/bin/mserver5 --dbpath=/opt/monetdb/db_error/sb_traf --set merovingian_uri=mapi:monetdb://monetbd-test:54321/sb_traf --set mapi_open=false --set mapi_port=0 --set mapi_usock=/opt/monetdb/db_error/sb_traf/.mapi.sock --set monet_vault_key=/opt/monetdb/db_error/sb_traf/.vaultkey --set gdk_nr_threads=8 --set max_clients=64 --set sql_optimizer=default_pipe --set monet_daemon=yes --dbinit="sql.start();" GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/local/bin/mserver5...done. *(gdb) r* Starting program: /usr/local/bin/mserver5 --dbpath=/opt/monetdb/db_error/sb_traf --set merovingian_uri=mapi:monetdb://monetbd-test:54321/sb_traf --set mapi_open=false --set mapi_port=0 --set mapi_usock=/opt/monetdb/db_error/sb_traf/.mapi.sock --set monet_vault_key=/opt/monetdb/db_error/sb_traf/.vaultkey --set gdk_nr_threads=8 --set max_clients=64 --set sql_optimizer=default_pipe --set monet_daemon=yes --dbinit=sql.start(); [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". # MonetDB 5 server v11.23.3 "Jun2016" # Serving database 'sb_traf', using 8 threads # Compiled for x86_64-unknown-linux-gnu/64bit with 64bit OIDs and 128bit integers dynamically linked # Found 30.000 GiB available main-memory. # Copyright (c) 1993-July 2008 CWI. # Copyright (c) August 2008-2016 MonetDB B.V., all rights reserved # Visit http://www.monetdb.org/ for further information [New Thread 0x7fffeb66b700 (LWP 23533)] [New Thread 0x7fffea7eb700 (LWP 23534)] # Listening for UNIX domain connection requests on mapi:monetdb:///opt/monetdb/db_error/sb_traf/.mapi.sock
Program received signal SIGSEGV, Segmentation fault. 0x00007fffeb155e97 in load_table_parts (tr=0x4e59780, t=0x4ff02c0, rid=44) at ../../../MonetDB-11.23.3/sql/storage/store.c:565 565 tp->p = t; *(gdb) tp* Tracepoint 1 at 0x7fffeb155e97: file ../../../MonetDB-11.23.3/sql/storage/store.c, line 565. *(gdb) p* The history is empty. *(gdb) where* #0 0x00007fffeb155e97 in load_table_parts (tr=0x4e59780, t=0x4ff02c0, rid=44) at ../../../MonetDB-11.23.3/sql/storage/store.c:565 #1 0x00007fffeb155ffa in load_tables_of_tables (tr=0x4e59780, s=0x4fd1790) at ../../../MonetDB-11.23.3/sql/storage/store.c:587 #2 0x00007fffeb158088 in load_schema (tr=0x4e59780, id=2155, rid=9223372036854775808) at ../../../MonetDB-11.23.3/sql/storage/store.c:934 #3 0x00007fffeb15863f in load_trans (tr=0x4e59780, id=2155) at ../../../MonetDB-11.23.3/sql/storage/store.c:1003 #4 0x00007fffeb15acd0 in store_load () at ../../../MonetDB-11.23.3/sql/storage/store.c:1552 #5 0x00007fffeb15af07 in store_init (debug=0, store=store_bat, readonly=0, singleuser=0, log_settings=0x7fffffffd300, stk=0) at ../../../MonetDB-11.23.3/sql/storage/store.c:1615 #6 0x00007fffeb0d7a24 in mvc_init (debug=0, store=store_bat, ro=0, su=0, stk=0) at ../../../MonetDB-11.23.3/sql/server/sql_mvc.c:60 #7 0x00007fffeb04cdce in SQLinit () at ../../../../MonetDB-11.23.3/sql/backends/monet5/sql_scenario.c:252 #8 0x00007fffeb04cb0e in SQLprelude (ret=0x4cf6840) at ../../../../MonetDB-11.23.3/sql/backends/monet5/sql_scenario.c:178 #9 0x00007ffff79d1403 in malCommandCall (stk=0x4cf6630, pci=0x4bca750) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:77 #10 0x00007ffff79d3a29 in runMALsequence (cntxt=0x7fffeb66c020, mb=0x609660, startpc=1, stoppc=0, stk=0x4cf6630, env=0x0, pcicaller=0x0) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:658 #11 0x00007ffff79d2c3c in runMAL (cntxt=0x7fffeb66c020, mb=0x609660, mbcaller=0x0, env=0x0) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:354 #12 0x00007ffff79f23cb in MALengine (c=0x7fffeb66c020) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_session.c:650 #13 0x00007ffff79f0a8c in malBootstrap () at ../../../MonetDB-11.23.3/monetdb5/mal/mal_session.c:62 #14 0x00007ffff79b7ff9 in mal_init () at ../../../MonetDB-11.23.3/monetdb5/mal/mal.c:103 #15 0x00000000004036c8 in main (argc=21, av=0x7fffffffe478) at ../../../MonetDB-11.23.3/tools/mserver/mserver5.c:658
*(gdb) l* 560 void *v = table_funcs.column_find_value(tr, find_sql_column(objects, "name"), rid); 561 sql_table *tp = find_sql_table(t->s, v); _DELETE(v); 562 563 assert(tp); 564 cs_add(&t->tables, tp, TR_OLD); 565 tp->p = t; 566 } 567 568 static void 569 load_tables_of_tables(sql_trans *tr, sql_schema *s)
*(gdb) p tp* $1 = (sql_table *) 0x0 *(gdb) p &t* $2 = (sql_table **) 0x7fffffffcfd0
On Mon, Jul 18, 2016 at 9:01 AM, Anderson, David B < david.b.anderson@citi.com> wrote:
Can you run a server built from source with debugging enabled? When I was having problems with MERGE tables, that was the only way to figure out what was going wrong. It sounds like you have a reproducible test case.
*From:* users-list [mailto:users-list-bounces+david.b.anderson= citi.com@monetdb.org] *On Behalf Of *Ariel Abadi *Sent:* Sunday, July 17, 2016 11:22 PM *To:* Communication channel for MonetDB users *Subject:* Re: MERGE TABLE ERROR
We are having a serious problem. Every time the DB starts doing crazy things with the MERGE tables (as described in the email attached). The DB crashes for ever.
2016-07-17 23:51:29 MSG merovingian[10151]: database 'trafico' (10165) was killed by signal SIGSEGV
2016-07-17 23:51:29 ERR control[10151]: (local): failed to fork mserver: database 'trafico' appears to shut itself down after starting, check monetdbd's logfile for possible hints
2016-07-17 23:52:16 MSG merovingian[10151]: caught SIGTERM, starting shutdown sequence
2016-07-17 23:52:19 MSG merovingian[10151]: Merovingian 1.7 stopped
2016-07-17 23:52:19 MSG control[10151]: control channel closed
The only way to recover is creating a newly fresh DBFARM.
If anyone knows something please help me!. We are creating the DB every week :(
On Sun, Jul 17, 2016 at 8:09 PM, Ariel Abadi aabadi@starconnecting.com wrote:
Hi!
We are facing a problem with MERGE Tables.
We have a process in php which connects to the DB using the mapi ( https://www.monetdb.org/Documentation/Manuals/SQLreference/Programming/MAPI https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_url-3Fq-3Dhttps-253A-252F-252Fwww.monetdb.org-252FDocumentation-252FManuals-252FSQLreference-252FProgramming-252FMAPI-26sa-3DD-26sntz-3D1-26usg-3DAFQjCNGpR9jSaQKxbmqRuVF8krphUQBn1g&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=TCBRhMVJpBqohBAbnbUVvgYKPiKFqjtu1E5YpbJopNU&e= )
The process creates a new table everyday as follows:
CREATE TABLE cub8_20160717 AS (SELECT * FROM cub8) WITH NO DATA;
Then, attaches that new table to the MERGE table called cub8_cubo as follows:
ALTER TABLE cub8_cubo ADD TABLE cub8_20160717 ;
Once all this is created, it start inserting data.
Everything works fine, with NO errors. BUT if I run a query against cub8_cubo I dont see cub8_20160717 data.
So I run this query in order to check if the new table was attached to the merge:
SELECT a.name https://urldefense.proofpoint.com/v2/url?u=http-3A__a.name&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=ZnIDaE5j_yUr6kSrOOE4Cq3warOfS07K_mIaeOwegkM&e=, b.name https://urldefense.proofpoint.com/v2/url?u=http-3A__b.name&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=_JclMJpcqhsINlwHeS8ktjB0_9RuNyYUbZ-cWZjugP0&e=, s.name https://urldefense.proofpoint.com/v2/url?u=http-3A__s.name&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=8ilEeDdElFocGAbnSPq-W29d3JFq16BYH0toUBKbg7E&e= FROM sys.tables as a JOIN sys.dependencies d ON a.id https://urldefense.proofpoint.com/v2/url?u=http-3A__a.id&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=1_-oTcb5B--YfIwGbvdu9ZiQDpG7hiPmu0AT4pTkvCA&e= = d.depend_id JOIN sys.tables as b ON b.id https://urldefense.proofpoint.com/v2/url?u=http-3A__b.id&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=ys7CybxwWMK332gjlTpc32DRDwp5s0jYgVCOHCCqKJU&e== d.id https://urldefense.proofpoint.com/v2/url?u=http-3A__d.id&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=N4PPkvTlKUfkg02qExjB4obAPJlr8-MBAEY0eFDAD10&e= JOIN sys.schemas as s ON a.schema_id = s.id https://urldefense.proofpoint.com/v2/url?u=http-3A__s.id&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=6dEMFdZ5wFejqBuipNcFWMuLaLfKkE5ifGCPSlIcC9o&e= WHERE a.type= 3 AND a.name https://urldefense.proofpoint.com/v2/url?u=http-3A__a.name&d=CwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=8_GYjk1edsyLJlNaxMxYxBJsviF3JXYvwDK42uy5KWU&m=KRZtgsAHenCyBgFZm9GAQBp03krybbhwPad-dLGK_cQ&s=ZnIDaE5j_yUr6kSrOOE4Cq3warOfS07K_mIaeOwegkM&e= ILIKE '%cub8%' ORDER BY 1,2;
+-----------+---------------+
| name | name |
+===========+===============+
| cub8_cubo | cub8_20160710 |
| cub8_cubo | cub8_20160711 |
| cub8_cubo | cub8_20160712 |
| cub8_cubo | cub8_20160713 |
| cub8_cubo | cub8_20160714 |
| cub8_cubo | cub8_20160715 |
| cub8_cubo | cub8_20160716 |
| cub8_cubo | cub8_20160717 |
So I try to detached from cub8_cubo, with the command:
ALTER TABLE cub8_cubo DROP TABLE cub8_20160717;
ALTER TABLE: table 'sb_traf.cub8_20160717' isn't part of the MERGE TABLE 'sb_traf.cub8_cubo'
So I ADD it again:
ALTER TABLE cub8_cubo ADD TABLE cub8_20160717;
and now yes... I can see the data. If I need to detach that table, I need to run ALTER ... DROP twice or three times to get it done.
It seems to be a bug?, are we doing something wrong ??
Thks in advance!
*PS.:We are using *
*MonetDB Database Server v1.7 (Jun2016)*
*Welcome to mclient, the MonetDB/SQL interactive terminal (Jun2016)*
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
(Re-submitting/formatting to get under the 40K message size limit)
The coredump @565 is due to tp being NULL. Since it just got past the assertion @563, the problem has to be down in cs_add().
563 assert(tp); 564 cs_add(&t->tables, tp, TR_OLD); 565 tp->p = t;
I've dug down into cs_add(), but it isn't obvious to me where tp is getting set to NULL. Since it looks like you have a fairly straightforward test case, I would submit a bug report.
From: users-list [mailto:users-list-bounces+david.b.anderson=citi.com@monetdb.org] On Behalf Of Ariel Abadi Sent: Monday, July 18, 2016 1:25 PM To: Communication channel for MonetDB users Subject: Re: MERGE TABLE ERROR
Finally I make it to start it on debugger...
Here is the trace... Can someone help us ? Thks in advance!
gdb --args /usr/local/bin/mserver5 --dbpath=/opt/monetdb/db_error/sb_traf --set merovingian_uri=mapi:monetdb://monetbd-test:54321/sb_traf --set mapi_open=false --set mapi_port=0 --set mapi_usock=/opt/monetdb/db_error/sb_traf/.mapi.sock --set monet_vault_key=/opt/monetdb/db_error/sb_traf/.vaultkey --set gdk_nr_threads=8 --set max_clients=64 --set sql_optimizer=default_pipe --set monet_daemon=yes --dbinit="sql.start();" GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/local/bin/mserver5...done. (gdb) r Starting program: /usr/local/bin/mserver5 --dbpath=/opt/monetdb/db_error/sb_traf --set merovingian_uri=mapi:monetdb://monetbd-test:54321/sb_traf --set mapi_open=false --set mapi_port=0 --set mapi_usock=/opt/monetdb/db_error/sb_traf/.mapi.sock --set monet_vault_key=/opt/monetdb/db_error/sb_traf/.vaultkey --set gdk_nr_threads=8 --set max_clients=64 --set sql_optimizer=default_pipe --set monet_daemon=yes --dbinit=sql.start(); [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". # MonetDB 5 server v11.23.3 "Jun2016" # Serving database 'sb_traf', using 8 threads # Compiled for x86_64-unknown-linux-gnu/64bit with 64bit OIDs and 128bit integers dynamically linked # Found 30.000 GiB available main-memory. # Copyright (c) 1993-July 2008 CWI. # Copyright (c) August 2008-2016 MonetDB B.V., all rights reserved # Visit http://www.monetdb.org/ for further information [New Thread 0x7fffeb66b700 (LWP 23533)] [New Thread 0x7fffea7eb700 (LWP 23534)] # Listening for UNIX domain connection requests on mapi:monetdb:///opt/monetdb/db_error/sb_traf/.mapi.sock
Program received signal SIGSEGV, Segmentation fault. 0x00007fffeb155e97 in load_table_parts (tr=0x4e59780, t=0x4ff02c0, rid=44) at ../../../MonetDB-11.23.3/sql/storage/store.c:565 565 tp->p = t; (gdb) where #0 0x00007fffeb155e97 in load_table_parts (tr=0x4e59780, t=0x4ff02c0, rid=44) at ../../../MonetDB-11.23.3/sql/storage/store.c:565 #1 0x00007fffeb155ffa in load_tables_of_tables (tr=0x4e59780, s=0x4fd1790) at ../../../MonetDB-11.23.3/sql/storage/store.c:587 #2 0x00007fffeb158088 in load_schema (tr=0x4e59780, id=2155, rid=9223372036854775808) at ../../../MonetDB-11.23.3/sql/storage/store.c:934 #3 0x00007fffeb15863f in load_trans (tr=0x4e59780, id=2155) at ../../../MonetDB-11.23.3/sql/storage/store.c:1003 #4 0x00007fffeb15acd0 in store_load () at ../../../MonetDB-11.23.3/sql/storage/store.c:1552 #5 0x00007fffeb15af07 in store_init (debug=0, store=store_bat, readonly=0, singleuser=0, log_settings=0x7fffffffd300, stk=0) at ../../../MonetDB-11.23.3/sql/storage/store.c:1615 #6 0x00007fffeb0d7a24 in mvc_init (debug=0, store=store_bat, ro=0, su=0, stk=0) at ../../../MonetDB-11.23.3/sql/server/sql_mvc.c:60 #7 0x00007fffeb04cdce in SQLinit () at ../../../../MonetDB-11.23.3/sql/backends/monet5/sql_scenario.c:252 #8 0x00007fffeb04cb0e in SQLprelude (ret=0x4cf6840) at ../../../../MonetDB-11.23.3/sql/backends/monet5/sql_scenario.c:178 #9 0x00007ffff79d1403 in malCommandCall (stk=0x4cf6630, pci=0x4bca750) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:77 #10 0x00007ffff79d3a29 in runMALsequence (cntxt=0x7fffeb66c020, mb=0x609660, startpc=1, stoppc=0, stk=0x4cf6630, env=0x0, pcicaller=0x0) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:658 #11 0x00007ffff79d2c3c in runMAL (cntxt=0x7fffeb66c020, mb=0x609660, mbcaller=0x0, env=0x0) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:354 #12 0x00007ffff79f23cb in MALengine (c=0x7fffeb66c020) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_session.c:650 #13 0x00007ffff79f0a8c in malBootstrap () at ../../../MonetDB-11.23.3/monetdb5/mal/mal_session.c:62 #14 0x00007ffff79b7ff9 in mal_init () at ../../../MonetDB-11.23.3/monetdb5/mal/mal.c:103 #15 0x00000000004036c8 in main (argc=21, av=0x7fffffffe478) at ../../../MonetDB-11.23.3/tools/mserver/mserver5.c:658
(gdb) l 560 void *v = table_funcs.column_find_value(tr, find_sql_column(objects, "name"), rid); 561 sql_table *tp = find_sql_table(t->s, v); _DELETE(v); 562 563 assert(tp); 564 cs_add(&t->tables, tp, TR_OLD); 565 tp->p = t; 566 } 567 568 static void 569 load_tables_of_tables(sql_trans *tr, sql_schema *s)
(gdb) p tp $1 = (sql_table *) 0x0 (gdb) p &t $2 = (sql_table **) 0x7fffffffcfd0
David THANK YOU VERY MUCH FOR YOUR HELP!!!!
On Tue, Jul 19, 2016 at 10:29 AM, Anderson, David B < david.b.anderson@citi.com> wrote:
(Re-submitting/formatting to get under the 40K message size limit)
The coredump @565 is due to tp being NULL. Since it just got past the assertion @563, the problem has to be down in cs_add().
563 assert(tp); 564 cs_add(&t->tables, tp, TR_OLD); 565 tp->p = t;
I've dug down into cs_add(), but it isn't obvious to me where tp is getting set to NULL. Since it looks like you have a fairly straightforward test case, I would submit a bug report.
From: users-list [mailto:users-list-bounces+david.b.anderson= citi.com@monetdb.org] On Behalf Of Ariel Abadi Sent: Monday, July 18, 2016 1:25 PM To: Communication channel for MonetDB users Subject: Re: MERGE TABLE ERROR
Finally I make it to start it on debugger...
Here is the trace... Can someone help us ? Thks in advance!
gdb --args /usr/local/bin/mserver5 --dbpath=/opt/monetdb/db_error/sb_traf --set merovingian_uri=mapi:monetdb://monetbd-test:54321/sb_traf --set mapi_open=false --set mapi_port=0 --set mapi_usock=/opt/monetdb/db_error/sb_traf/.mapi.sock --set monet_vault_key=/opt/monetdb/db_error/sb_traf/.vaultkey --set gdk_nr_threads=8 --set max_clients=64 --set sql_optimizer=default_pipe --set monet_daemon=yes --dbinit="sql.start();" GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later < http://gnu.org/licenses/gpl.html%3E This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/local/bin/mserver5...done. (gdb) r Starting program: /usr/local/bin/mserver5 --dbpath=/opt/monetdb/db_error/sb_traf --set merovingian_uri=mapi:monetdb://monetbd-test:54321/sb_traf --set mapi_open=false --set mapi_port=0 --set mapi_usock=/opt/monetdb/db_error/sb_traf/.mapi.sock --set monet_vault_key=/opt/monetdb/db_error/sb_traf/.vaultkey --set gdk_nr_threads=8 --set max_clients=64 --set sql_optimizer=default_pipe --set monet_daemon=yes --dbinit=sql.start(); [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". # MonetDB 5 server v11.23.3 "Jun2016" # Serving database 'sb_traf', using 8 threads # Compiled for x86_64-unknown-linux-gnu/64bit with 64bit OIDs and 128bit integers dynamically linked # Found 30.000 GiB available main-memory. # Copyright (c) 1993-July 2008 CWI. # Copyright (c) August 2008-2016 MonetDB B.V., all rights reserved # Visit http://www.monetdb.org/ for further information [New Thread 0x7fffeb66b700 (LWP 23533)] [New Thread 0x7fffea7eb700 (LWP 23534)] # Listening for UNIX domain connection requests on mapi:monetdb:///opt/monetdb/db_error/sb_traf/.mapi.sock
Program received signal SIGSEGV, Segmentation fault. 0x00007fffeb155e97 in load_table_parts (tr=0x4e59780, t=0x4ff02c0, rid=44) at ../../../MonetDB-11.23.3/sql/storage/store.c:565 565 tp->p = t; (gdb) where #0 0x00007fffeb155e97 in load_table_parts (tr=0x4e59780, t=0x4ff02c0, rid=44) at ../../../MonetDB-11.23.3/sql/storage/store.c:565 #1 0x00007fffeb155ffa in load_tables_of_tables (tr=0x4e59780, s=0x4fd1790) at ../../../MonetDB-11.23.3/sql/storage/store.c:587 #2 0x00007fffeb158088 in load_schema (tr=0x4e59780, id=2155, rid=9223372036854775808) at ../../../MonetDB-11.23.3/sql/storage/store.c:934 #3 0x00007fffeb15863f in load_trans (tr=0x4e59780, id=2155) at ../../../MonetDB-11.23.3/sql/storage/store.c:1003 #4 0x00007fffeb15acd0 in store_load () at ../../../MonetDB-11.23.3/sql/storage/store.c:1552 #5 0x00007fffeb15af07 in store_init (debug=0, store=store_bat, readonly=0, singleuser=0, log_settings=0x7fffffffd300, stk=0) at ../../../MonetDB-11.23.3/sql/storage/store.c:1615 #6 0x00007fffeb0d7a24 in mvc_init (debug=0, store=store_bat, ro=0, su=0, stk=0) at ../../../MonetDB-11.23.3/sql/server/sql_mvc.c:60 #7 0x00007fffeb04cdce in SQLinit () at ../../../../MonetDB-11.23.3/sql/backends/monet5/sql_scenario.c:252 #8 0x00007fffeb04cb0e in SQLprelude (ret=0x4cf6840) at ../../../../MonetDB-11.23.3/sql/backends/monet5/sql_scenario.c:178 #9 0x00007ffff79d1403 in malCommandCall (stk=0x4cf6630, pci=0x4bca750) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:77 #10 0x00007ffff79d3a29 in runMALsequence (cntxt=0x7fffeb66c020, mb=0x609660, startpc=1, stoppc=0, stk=0x4cf6630, env=0x0, pcicaller=0x0) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:658 #11 0x00007ffff79d2c3c in runMAL (cntxt=0x7fffeb66c020, mb=0x609660, mbcaller=0x0, env=0x0) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:354 #12 0x00007ffff79f23cb in MALengine (c=0x7fffeb66c020) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_session.c:650 #13 0x00007ffff79f0a8c in malBootstrap () at ../../../MonetDB-11.23.3/monetdb5/mal/mal_session.c:62 #14 0x00007ffff79b7ff9 in mal_init () at ../../../MonetDB-11.23.3/monetdb5/mal/mal.c:103 #15 0x00000000004036c8 in main (argc=21, av=0x7fffffffe478) at ../../../MonetDB-11.23.3/tools/mserver/mserver5.c:658
(gdb) l 560 void *v = table_funcs.column_find_value(tr, find_sql_column(objects, "name"), rid); 561 sql_table *tp = find_sql_table(t->s, v); _DELETE(v); 562 563 assert(tp); 564 cs_add(&t->tables, tp, TR_OLD); 565 tp->p = t; 566 } 567 568 static void 569 load_tables_of_tables(sql_trans *tr, sql_schema *s)
(gdb) p tp $1 = (sql_table *) 0x0 (gdb) p &t $2 = (sql_table **) 0x7fffffffcfd0
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 19/07/16 15:29, Anderson, David B wrote:
(Re-submitting/formatting to get under the 40K message size limit)
The coredump @565 is due to tp being NULL. Since it just got past the assertion @563, the problem has to be down in cs_add().
563 assert(tp); 564 cs_add(&t->tables, tp, TR_OLD); 565 tp->p = t;
I've dug down into cs_add(), but it isn't obvious to me where tp is getting set to NULL. Since it looks like you have a fairly straightforward test case, I would submit a bug report.
Since this is C (not C++) and since cs_add is a function (not a macro), cs_add cannot possibly change the value of tp in the calling function. The only alternative here is that assertions are disabled during configure.
In other words, find_sql_table() must return a NULL pointer for whatever reason.
From: users-list [mailto:users-list-bounces+david.b.anderson=citi.com@monetdb.org] On Behalf Of Ariel Abadi Sent: Monday, July 18, 2016 1:25 PM To: Communication channel for MonetDB users Subject: Re: MERGE TABLE ERROR
Finally I make it to start it on debugger...
Here is the trace... Can someone help us ? Thks in advance!
gdb --args /usr/local/bin/mserver5 --dbpath=/opt/monetdb/db_error/sb_traf --set merovingian_uri=mapi:monetdb://monetbd-test:54321/sb_traf --set mapi_open=false --set mapi_port=0 --set mapi_usock=/opt/monetdb/db_error/sb_traf/.mapi.sock --set monet_vault_key=/opt/monetdb/db_error/sb_traf/.vaultkey --set gdk_nr_threads=8 --set max_clients=64 --set sql_optimizer=default_pipe --set monet_daemon=yes --dbinit="sql.start();" GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/local/bin/mserver5...done. (gdb) r Starting program: /usr/local/bin/mserver5 --dbpath=/opt/monetdb/db_error/sb_traf --set merovingian_uri=mapi:monetdb://monetbd-test:54321/sb_traf --set mapi_open=false --set mapi_port=0 --set mapi_usock=/opt/monetdb/db_error/sb_traf/.mapi.sock --set monet_vault_key=/opt/monetdb/db_error/sb_traf/.vaultkey --set gdk_nr_threads=8 --set max_clients=64 --set sql_optimizer=default_pipe --set monet_daemon=yes --dbinit=sql.start(); [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". # MonetDB 5 server v11.23.3 "Jun2016" # Serving database 'sb_traf', using 8 threads # Compiled for x86_64-unknown-linux-gnu/64bit with 64bit OIDs and 128bit integers dynamically linked # Found 30.000 GiB available main-memory. # Copyright (c) 1993-July 2008 CWI. # Copyright (c) August 2008-2016 MonetDB B.V., all rights reserved # Visit http://www.monetdb.org/ for further information [New Thread 0x7fffeb66b700 (LWP 23533)] [New Thread 0x7fffea7eb700 (LWP 23534)] # Listening for UNIX domain connection requests on mapi:monetdb:///opt/monetdb/db_error/sb_traf/.mapi.sock
Program received signal SIGSEGV, Segmentation fault. 0x00007fffeb155e97 in load_table_parts (tr=0x4e59780, t=0x4ff02c0, rid=44) at ../../../MonetDB-11.23.3/sql/storage/store.c:565 565 tp->p = t; (gdb) where #0 0x00007fffeb155e97 in load_table_parts (tr=0x4e59780, t=0x4ff02c0, rid=44) at ../../../MonetDB-11.23.3/sql/storage/store.c:565 #1 0x00007fffeb155ffa in load_tables_of_tables (tr=0x4e59780, s=0x4fd1790) at ../../../MonetDB-11.23.3/sql/storage/store.c:587 #2 0x00007fffeb158088 in load_schema (tr=0x4e59780, id=2155, rid=9223372036854775808) at ../../../MonetDB-11.23.3/sql/storage/store.c:934 #3 0x00007fffeb15863f in load_trans (tr=0x4e59780, id=2155) at ../../../MonetDB-11.23.3/sql/storage/store.c:1003 #4 0x00007fffeb15acd0 in store_load () at ../../../MonetDB-11.23.3/sql/storage/store.c:1552 #5 0x00007fffeb15af07 in store_init (debug=0, store=store_bat, readonly=0, singleuser=0, log_settings=0x7fffffffd300, stk=0) at ../../../MonetDB-11.23.3/sql/storage/store.c:1615 #6 0x00007fffeb0d7a24 in mvc_init (debug=0, store=store_bat, ro=0, su=0, stk=0) at ../../../MonetDB-11.23.3/sql/server/sql_mvc.c:60 #7 0x00007fffeb04cdce in SQLinit () at ../../../../MonetDB-11.23.3/sql/backends/monet5/sql_scenario.c:252 #8 0x00007fffeb04cb0e in SQLprelude (ret=0x4cf6840) at ../../../../MonetDB-11.23.3/sql/backends/monet5/sql_scenario.c:178 #9 0x00007ffff79d1403 in malCommandCall (stk=0x4cf6630, pci=0x4bca750) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:77 #10 0x00007ffff79d3a29 in runMALsequence (cntxt=0x7fffeb66c020, mb=0x609660, startpc=1, stoppc=0, stk=0x4cf6630, env=0x0, pcicaller=0x0) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:658 #11 0x00007ffff79d2c3c in runMAL (cntxt=0x7fffeb66c020, mb=0x609660, mbcaller=0x0, env=0x0) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:354 #12 0x00007ffff79f23cb in MALengine (c=0x7fffeb66c020) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_session.c:650 #13 0x00007ffff79f0a8c in malBootstrap () at ../../../MonetDB-11.23.3/monetdb5/mal/mal_session.c:62 #14 0x00007ffff79b7ff9 in mal_init () at ../../../MonetDB-11.23.3/monetdb5/mal/mal.c:103 #15 0x00000000004036c8 in main (argc=21, av=0x7fffffffe478) at ../../../MonetDB-11.23.3/tools/mserver/mserver5.c:658
(gdb) l 560 void *v = table_funcs.column_find_value(tr, find_sql_column(objects, "name"), rid); 561 sql_table *tp = find_sql_table(t->s, v); _DELETE(v); 562 563 assert(tp); 564 cs_add(&t->tables, tp, TR_OLD); 565 tp->p = t; 566 } 567 568 static void 569 load_tables_of_tables(sql_trans *tr, sql_schema *s)
(gdb) p tp $1 = (sql_table *) 0x0 (gdb) p &t $2 = (sql_table **) 0x7fffffffcfd0
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
- -- Sjoerd Mullender
My mistake, I assumed assertions would be enabled in debug mode, but now that I look closely at the configure script, I see an explicit enable_assert option.
Couldn't a memory bug overwrite the contents of tp?
-----Original Message----- From: users-list [mailto:users-list-bounces+david.b.anderson=citi.com@monetdb.org] On Behalf Of Sjoerd Mullender Sent: Tuesday, July 19, 2016 10:58 AM To: users-list@monetdb.org Subject: Re: MERGE TABLE ERROR
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 19/07/16 15:29, Anderson, David B wrote:
(Re-submitting/formatting to get under the 40K message size limit)
The coredump @565 is due to tp being NULL. Since it just got past the assertion @563, the problem has to be down in cs_add().
563 assert(tp); 564 cs_add(&t->tables, tp, TR_OLD); 565 tp->p = t;
I've dug down into cs_add(), but it isn't obvious to me where tp is getting set to NULL. Since it looks like you have a fairly straightforward test case, I would submit a bug report.
Since this is C (not C++) and since cs_add is a function (not a macro), cs_add cannot possibly change the value of tp in the calling function. The only alternative here is that assertions are disabled during configure.
In other words, find_sql_table() must return a NULL pointer for whatever reason.
From: users-list [mailto:users-list-bounces+david.b.anderson=citi.com@monetdb.org] On Behalf Of Ariel Abadi Sent: Monday, July 18, 2016 1:25 PM To: Communication channel for MonetDB users Subject: Re: MERGE TABLE ERROR
Finally I make it to start it on debugger...
Here is the trace... Can someone help us ? Thks in advance!
gdb --args /usr/local/bin/mserver5 --dbpath=/opt/monetdb/db_error/sb_traf --set merovingian_uri=mapi:monetdb://monetbd-test:54321/sb_traf --set mapi_open=false --set mapi_port=0 --set mapi_usock=/opt/monetdb/db_error/sb_traf/.mapi.sock --set monet_vault_key=/opt/monetdb/db_error/sb_traf/.vaultkey --set gdk_nr_threads=8 --set max_clients=64 --set sql_optimizer=default_pipe --set monet_daemon=yes --dbinit="sql.start();" GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/local/bin/mserver5...done. (gdb) r Starting program: /usr/local/bin/mserver5 --dbpath=/opt/monetdb/db_error/sb_traf --set merovingian_uri=mapi:monetdb://monetbd-test:54321/sb_traf --set mapi_open=false --set mapi_port=0 --set mapi_usock=/opt/monetdb/db_error/sb_traf/.mapi.sock --set monet_vault_key=/opt/monetdb/db_error/sb_traf/.vaultkey --set gdk_nr_threads=8 --set max_clients=64 --set sql_optimizer=default_pipe --set monet_daemon=yes --dbinit=sql.start(); [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". # MonetDB 5 server v11.23.3 "Jun2016" # Serving database 'sb_traf', using 8 threads # Compiled for x86_64-unknown-linux-gnu/64bit with 64bit OIDs and 128bit integers dynamically linked # Found 30.000 GiB available main-memory. # Copyright (c) 1993-July 2008 CWI. # Copyright (c) August 2008-2016 MonetDB B.V., all rights reserved # Visit http://www.monetdb.org/ for further information [New Thread 0x7fffeb66b700 (LWP 23533)] [New Thread 0x7fffea7eb700 (LWP 23534)] # Listening for UNIX domain connection requests on mapi:monetdb:///opt/monetdb/db_error/sb_traf/.mapi.sock
Program received signal SIGSEGV, Segmentation fault. 0x00007fffeb155e97 in load_table_parts (tr=0x4e59780, t=0x4ff02c0, rid=44) at ../../../MonetDB-11.23.3/sql/storage/store.c:565 565 tp->p = t; (gdb) where #0 0x00007fffeb155e97 in load_table_parts (tr=0x4e59780, t=0x4ff02c0, rid=44) at ../../../MonetDB-11.23.3/sql/storage/store.c:565 #1 0x00007fffeb155ffa in load_tables_of_tables (tr=0x4e59780, s=0x4fd1790) at ../../../MonetDB-11.23.3/sql/storage/store.c:587 #2 0x00007fffeb158088 in load_schema (tr=0x4e59780, id=2155, rid=9223372036854775808) at ../../../MonetDB-11.23.3/sql/storage/store.c:934 #3 0x00007fffeb15863f in load_trans (tr=0x4e59780, id=2155) at ../../../MonetDB-11.23.3/sql/storage/store.c:1003 #4 0x00007fffeb15acd0 in store_load () at ../../../MonetDB-11.23.3/sql/storage/store.c:1552 #5 0x00007fffeb15af07 in store_init (debug=0, store=store_bat, readonly=0, singleuser=0, log_settings=0x7fffffffd300, stk=0) at ../../../MonetDB-11.23.3/sql/storage/store.c:1615 #6 0x00007fffeb0d7a24 in mvc_init (debug=0, store=store_bat, ro=0, su=0, stk=0) at ../../../MonetDB-11.23.3/sql/server/sql_mvc.c:60 #7 0x00007fffeb04cdce in SQLinit () at ../../../../MonetDB-11.23.3/sql/backends/monet5/sql_scenario.c:252 #8 0x00007fffeb04cb0e in SQLprelude (ret=0x4cf6840) at ../../../../MonetDB-11.23.3/sql/backends/monet5/sql_scenario.c:178 #9 0x00007ffff79d1403 in malCommandCall (stk=0x4cf6630, pci=0x4bca750) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:77 #10 0x00007ffff79d3a29 in runMALsequence (cntxt=0x7fffeb66c020, mb=0x609660, startpc=1, stoppc=0, stk=0x4cf6630, env=0x0, pcicaller=0x0) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:658 #11 0x00007ffff79d2c3c in runMAL (cntxt=0x7fffeb66c020, mb=0x609660, mbcaller=0x0, env=0x0) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:354 #12 0x00007ffff79f23cb in MALengine (c=0x7fffeb66c020) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_session.c:650 #13 0x00007ffff79f0a8c in malBootstrap () at ../../../MonetDB-11.23.3/monetdb5/mal/mal_session.c:62 #14 0x00007ffff79b7ff9 in mal_init () at ../../../MonetDB-11.23.3/monetdb5/mal/mal.c:103 #15 0x00000000004036c8 in main (argc=21, av=0x7fffffffe478) at ../../../MonetDB-11.23.3/tools/mserver/mserver5.c:658
(gdb) l 560 void *v = table_funcs.column_find_value(tr, find_sql_column(objects, "name"), rid); 561 sql_table *tp = find_sql_table(t->s, v); _DELETE(v); 562 563 assert(tp); 564 cs_add(&t->tables, tp, TR_OLD); 565 tp->p = t; 566 } 567 568 static void 569 load_tables_of_tables(sql_trans *tr, sql_schema *s)
(gdb) p tp $1 = (sql_table *) 0x0 (gdb) p &t $2 = (sql_table **) 0x7fffffffcfd0
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
- -- Sjoerd Mullender
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 19/07/16 17:53, Anderson, David B wrote:
My mistake, I assumed assertions would be enabled in debug mode, but now that I look closely at the configure script, I see an explicit enable_assert option.
Couldn't a memory bug overwrite the contents of tp?
Theoretically, yes. But highly unlikely.
-----Original Message----- From: users-list [mailto:users-list-bounces+david.b.anderson=citi.com@monetdb.org] On Behalf Of Sjoerd Mullender Sent: Tuesday, July 19, 2016 10:58 AM To: users-list@monetdb.org Subject: Re: MERGE TABLE ERROR
On 19/07/16 15:29, Anderson, David B wrote:
(Re-submitting/formatting to get under the 40K message size limit)
The coredump @565 is due to tp being NULL. Since it just got past the assertion @563, the problem has to be down in cs_add().
563 assert(tp); 564 cs_add(&t->tables, tp, TR_OLD); 565 tp->p = t;
I've dug down into cs_add(), but it isn't obvious to me where tp is getting set to NULL. Since it looks like you have a fairly straightforward test case, I would submit a bug report.
Since this is C (not C++) and since cs_add is a function (not a macro), cs_add cannot possibly change the value of tp in the calling function. The only alternative here is that assertions are disabled during configure.
In other words, find_sql_table() must return a NULL pointer for whatever reason.
From: users-list [mailto:users-list-bounces+david.b.anderson=citi.com@monetdb.org]
On Behalf Of Ariel Abadi Sent: Monday, July 18, 2016 1:25 PM To:
Communication channel for MonetDB users Subject: Re: MERGE TABLE ERROR
Finally I make it to start it on debugger...
Here is the trace... Can someone help us ? Thks in advance!
gdb --args /usr/local/bin/mserver5 --dbpath=/opt/monetdb/db_error/sb_traf --set merovingian_uri=mapi:monetdb://monetbd-test:54321/sb_traf --set mapi_open=false --set mapi_port=0 --set mapi_usock=/opt/monetdb/db_error/sb_traf/.mapi.sock --set monet_vault_key=/opt/monetdb/db_error/sb_traf/.vaultkey --set gdk_nr_threads=8 --set max_clients=64 --set sql_optimizer=default_pipe --set monet_daemon=yes --dbinit="sql.start();" GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/local/bin/mserver5...done. (gdb) r Starting program: /usr/local/bin/mserver5 --dbpath=/opt/monetdb/db_error/sb_traf --set merovingian_uri=mapi:monetdb://monetbd-test:54321/sb_traf --set mapi_open=false --set mapi_port=0 --set mapi_usock=/opt/monetdb/db_error/sb_traf/.mapi.sock --set monet_vault_key=/opt/monetdb/db_error/sb_traf/.vaultkey --set gdk_nr_threads=8 --set max_clients=64 --set sql_optimizer=default_pipe --set monet_daemon=yes --dbinit=sql.start(); [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". # MonetDB 5 server v11.23.3 "Jun2016" # Serving database 'sb_traf', using 8 threads # Compiled for x86_64-unknown-linux-gnu/64bit with 64bit OIDs and 128bit integers dynamically linked # Found 30.000 GiB available main-memory. # Copyright (c) 1993-July 2008 CWI. # Copyright (c) August 2008-2016 MonetDB B.V., all rights reserved # Visit http://www.monetdb.org/ for further information [New Thread 0x7fffeb66b700 (LWP 23533)] [New Thread 0x7fffea7eb700 (LWP 23534)] # Listening for UNIX domain connection requests on mapi:monetdb:///opt/monetdb/db_error/sb_traf/.mapi.sock
Program received signal SIGSEGV, Segmentation fault. 0x00007fffeb155e97 in load_table_parts (tr=0x4e59780, t=0x4ff02c0, rid=44) at ../../../MonetDB-11.23.3/sql/storage/store.c:565 565 tp->p = t; (gdb) where #0 0x00007fffeb155e97 in load_table_parts (tr=0x4e59780, t=0x4ff02c0, rid=44) at ../../../MonetDB-11.23.3/sql/storage/store.c:565 #1 0x00007fffeb155ffa in load_tables_of_tables (tr=0x4e59780, s=0x4fd1790) at ../../../MonetDB-11.23.3/sql/storage/store.c:587 #2 0x00007fffeb158088 in load_schema (tr=0x4e59780, id=2155, rid=9223372036854775808) at ../../../MonetDB-11.23.3/sql/storage/store.c:934 #3 0x00007fffeb15863f in load_trans (tr=0x4e59780, id=2155) at ../../../MonetDB-11.23.3/sql/storage/store.c:1003 #4 0x00007fffeb15acd0 in store_load () at ../../../MonetDB-11.23.3/sql/storage/store.c:1552 #5 0x00007fffeb15af07 in store_init (debug=0, store=store_bat, readonly=0, singleuser=0, log_settings=0x7fffffffd300, stk=0) at ../../../MonetDB-11.23.3/sql/storage/store.c:1615 #6 0x00007fffeb0d7a24 in mvc_init (debug=0, store=store_bat, ro=0, su=0, stk=0) at ../../../MonetDB-11.23.3/sql/server/sql_mvc.c:60 #7 0x00007fffeb04cdce in SQLinit () at ../../../../MonetDB-11.23.3/sql/backends/monet5/sql_scenario.c:252
#8 0x00007fffeb04cb0e in SQLprelude (ret=0x4cf6840) at
../../../../MonetDB-11.23.3/sql/backends/monet5/sql_scenario.c:178
#9 0x00007ffff79d1403 in malCommandCall (stk=0x4cf6630,
pci=0x4bca750) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:77 #10 0x00007ffff79d3a29 in runMALsequence (cntxt=0x7fffeb66c020, mb=0x609660, startpc=1, stoppc=0, stk=0x4cf6630, env=0x0, pcicaller=0x0) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:658 #11 0x00007ffff79d2c3c in runMAL (cntxt=0x7fffeb66c020, mb=0x609660, mbcaller=0x0, env=0x0) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_interpreter.c:354 #12 0x00007ffff79f23cb in MALengine (c=0x7fffeb66c020) at ../../../MonetDB-11.23.3/monetdb5/mal/mal_session.c:650 #13 0x00007ffff79f0a8c in malBootstrap () at ../../../MonetDB-11.23.3/monetdb5/mal/mal_session.c:62 #14 0x00007ffff79b7ff9 in mal_init () at ../../../MonetDB-11.23.3/monetdb5/mal/mal.c:103 #15 0x00000000004036c8 in main (argc=21, av=0x7fffffffe478) at ../../../MonetDB-11.23.3/tools/mserver/mserver5.c:658
(gdb) l 560 void *v = table_funcs.column_find_value(tr, find_sql_column(objects, "name"), rid); 561 sql_table *tp = find_sql_table(t->s, v); _DELETE(v); 562 563 assert(tp); 564 cs_add(&t->tables, tp, TR_OLD); 565 tp->p = t; 566 } 567 568 static void 569 load_tables_of_tables(sql_trans *tr, sql_schema *s)
(gdb) p tp $1 = (sql_table *) 0x0 (gdb) p &t $2 = (sql_table **) 0x7fffffffcfd0
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list _______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
- -- Sjoerd Mullender
participants (3)
-
Anderson, David B -
Ariel Abadi -
Sjoerd Mullender