Finally I make it to start it on debugger...
Here is the trace... Can someone help us ?
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.
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:
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
[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:
We are facing a problem with MERGE Tables.
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;
+-----------+---------------+
+===========+===============+
| 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'
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 ??
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