Hi.
I'm currently evaluating MonetDB for an upcoming project, and am having some problems when using date criteria in the where clause.
I have a very simple table:
Create table negs (id varchar(50) not null, xdate date not null, market int, product int, notional double)
Id and xdate form a composite primary key, and I have indices on xdate, market and product.
If I run the following query:
Select * from negs where xdate = current_date
the client crashes. Similarly if I run the same query over a JDBC connection from java, the connection is lost.
Looking in the log file, it says that the database was killed due to a SIGSEGV.
Am I doing something wrong?
I am running on Ubuntu 14.04, and built MonetDB from the latest source tarball, 11.17.21.
Thanks, Nick
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors.
Hi
I can not reconstruct the error on the Jan 2014 Fedora 20
Jan2014> mclient -d demoJan2014 Welcome to mclient, the MonetDB/SQL interactive terminal (unreleased) Database: MonetDB v11.20.0 (unreleased), 'mapi:monetdb://vienna.ins.cwi.nl:50000/demoJan2014' Type \q to quit, ? for a list of available commands auto commit mode: on sql>Create table negs (id varchar(50) not null, xdate date not null, market int, product int, notional double); operation successful (23.827ms) sql>Select * from negs where xdate = current_date; +----+-------+--------+---------+----------+ | id | xdate | market | product | notional | +====+=======+========+=========+==========+ +----+-------+--------+---------+----------+ 0 tuples (2.028ms) sql>
Could it be that your table 'negs' is not empty? More information is needed to track the problem.
regards, Martin
On 16/09/14 15:31, Nick Chadwick wrote:
Hi.
I’m currently evaluating MonetDB for an upcoming project, and am having some problems when using date criteria in the where clause.
I have a very simple table:
Create table negs (id varchar(50) not null, xdate date not null, market int, product int, notional double)
Id and xdate form a composite primary key, and I have indices on xdate, market and product.
If I run the following query:
Select * from negs where xdate = current_date
the client crashes. Similarly if I run the same query over a JDBC connection from java, the connection is lost.
Looking in the log file, it says that the database was killed due to a SIGSEGV.
Am I doing something wrong?
I am running on Ubuntu 14.04, and built MonetDB from the latest source tarball, 11.17.21.
Thanks,
Nick
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors.
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
Thanks for the response.
Ah yes, I should have been more specific - the table is indeed not empty. I have 1.5 million randomly-generated rows loaded into it.
I am able to run all sorts of queries against it, but it is only when I start working with the xdate column in the where clause that it goes wrong.
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Martin Kersten Sent: 16 September 2014 16:48 To: Communication channel for MonetDB users Subject: Re: Crashing when querying on date column
Hi
I can not reconstruct the error on the Jan 2014 Fedora 20
Jan2014> mclient -d demoJan2014 Welcome to mclient, the MonetDB/SQL interactive terminal (unreleased) Database: MonetDB v11.20.0 (unreleased), 'mapi:monetdb://vienna.ins.cwi.nl:50000/demoJan2014' Type \q to quit, ? for a list of available commands auto commit mode: on sql>Create table negs (id varchar(50) not null, xdate date not null, sql>market int, product int, notional double); operation successful (23.827ms) sql>Select * from negs where xdate = current_date; +----+-------+--------+---------+----------+ | id | xdate | market | product | notional | +====+=======+========+=========+==========+ +----+-------+--------+---------+----------+ 0 tuples (2.028ms) sql>
Could it be that your table 'negs' is not empty? More information is needed to track the problem.
regards, Martin
On 16/09/14 15:31, Nick Chadwick wrote:
Hi.
I'm currently evaluating MonetDB for an upcoming project, and am having some problems when using date criteria in the where clause.
I have a very simple table:
Create table negs (id varchar(50) not null, xdate date not null, market int, product int, notional double)
Id and xdate form a composite primary key, and I have indices on xdate, market and product.
If I run the following query:
Select * from negs where xdate = current_date
the client crashes. Similarly if I run the same query over a JDBC connection from java, the connection is lost.
Looking in the log file, it says that the database was killed due to a SIGSEGV.
Am I doing something wrong?
I am running on Ubuntu 14.04, and built MonetDB from the latest source tarball, 11.17.21.
Thanks,
Nick
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors.
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
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors.
On Tue, Sep 16, 2014 at 01:31:34PM +0000, Nick Chadwick wrote:
Hi.
I’m currently evaluating MonetDB for an upcoming project, and am having some problems when using date criteria in the where clause.
I have a very simple table:
Create table negs (id varchar(50) not null, xdate date not null, market int, product int, notional double)
Id and xdate form a composite primary key, and I have indices on xdate, market and product.
Date itself isn't that special (ie used in very many of our tests), I expecte the composite key or indices cause the problem. Could you send the full ddl (or simply using mclients \d negs ).
Niels
If I run the following query:
Select * from negs where xdate = current_date
the client crashes. Similarly if I run the same query over a JDBC connection from java, the connection is lost.
Looking in the log file, it says that the database was killed due to a SIGSEGV.
Am I doing something wrong?
I am running on Ubuntu 14.04, and built MonetDB from the latest source tarball, 11.17.21.
Thanks,
Nick
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors.
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
Hi Niels,
Here's the output from \d negs:
CREATE TABLE "sys"."negs" ( "id" VARCHAR(50) NOT NULL, "xdate" DATE NOT NULL, "market" INTEGER, "product" INTEGER, "notional" DOUBLE, "client" INTEGER, "tier" INTEGER, "status" INTEGER, "dayno" INTEGER, CONSTRAINT "negs_id_xdate_pkey" PRIMARY KEY ("id", "xdate") ); CREATE INDEX "idx_negs_client" ON "sys"."negs" ("client"); CREATE INDEX "idx_negs_market" ON "sys"."negs" ("market"); CREATE INDEX "idx_negs_product" ON "sys"."negs" ("product"); CREATE INDEX "idx_negs_status" ON "sys"."negs" ("status"); CREATE INDEX "idx_negs_tier" ON "sys"."negs" ("tier"); CREATE INDEX "idx_negs_xdate" ON "sys"."negs" ("xdate");
(I have added a few more columns since my original E-mail, but still seeing the same crashing behaviour.)
Cheers, Nick
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Niels Nes Sent: 16 September 2014 19:48 To: Communication channel for MonetDB users Subject: Re: Crashing when querying on date column
On Tue, Sep 16, 2014 at 01:31:34PM +0000, Nick Chadwick wrote:
Hi.
I’m currently evaluating MonetDB for an upcoming project, and am having some problems when using date criteria in the where clause.
I have a very simple table:
Create table negs (id varchar(50) not null, xdate date not null, market int, product int, notional double)
Id and xdate form a composite primary key, and I have indices on xdate, market and product.
Date itself isn't that special (ie used in very many of our tests), I expecte the composite key or indices cause the problem. Could you send the full ddl (or simply using mclients \d negs ).
Niels
If I run the following query:
Select * from negs where xdate = current_date
the client crashes. Similarly if I run the same query over a JDBC connection from java, the connection is lost.
Looking in the log file, it says that the database was killed due to a SIGSEGV.
Am I doing something wrong?
I am running on Ubuntu 14.04, and built MonetDB from the latest source tarball, 11.17.21.
Thanks,
Nick
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors.
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
-- Niels Nes, Centrum Wiskunde & Informatica (CWI) Science Park 123, 1098 XG Amsterdam, The Netherlands room L3.14, phone ++31 20 592-4098 sip:4098@sip.cwi.nl url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors.
On 17/09/14 12:08, Nick Chadwick wrote:
CREATE TABLE "sys"."negs" ( "id" VARCHAR(50) NOT NULL, "xdate" DATE NOT NULL, "market" INTEGER, "product" INTEGER, "notional" DOUBLE, "client" INTEGER, "tier" INTEGER, "status" INTEGER, "dayno" INTEGER, CONSTRAINT "negs_id_xdate_pkey" PRIMARY KEY ("id", "xdate") ); CREATE INDEX "idx_negs_client" ON "sys"."negs" ("client"); CREATE INDEX "idx_negs_market" ON "sys"."negs" ("market"); CREATE INDEX "idx_negs_product" ON "sys"."negs" ("product"); CREATE INDEX "idx_negs_status" ON "sys"."negs" ("status"); CREATE INDEX "idx_negs_tier" ON "sys"."negs" ("tier"); CREATE INDEX "idx_negs_xdate" ON "sys"."negs" ("xdate");
sql>select * from negs; +----+-------+--------+---------+----------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | dayno | +====+=======+========+=========+==========+========+======+========+=======+ +----+-------+--------+---------+----------+--------+------+--------+-------+ 0 tuples (4.456ms) sql>insert into negs values('id',now(),1,1,1.2,1,1,1,1); 1 affected rows (19.534ms) sql>select * from negs; +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | dayno | +======+============+========+=========+==========================+========+======+========+=======+ | id | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ 1 tuple (3.283ms) sql>insert into negs values('id2',now(),1,1,1.2,1,1,1,1); 1 affected rows (16.154ms) sql>select * from negs; +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | dayno | +======+============+========+=========+==========================+========+======+========+=======+ | id | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | | id2 | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ 2 tuples (1.867ms)
we need to dig further. Are you able to work with 'gdb' and produce a stacktrace of the crashed server?
regards, Martin
steps: 1) start mclient 2) other window: ps axl |grep mserver 3) extract the process id of the mserver 4) gdb mserver5 "processid" continue 5) in mclient, activate the malicious query 6) if it crashes, gdb window will say so 7) get stacktrace command: where
Here's the stacktrace:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f474c3f8700 (LWP 1215)] 0x00007f474f3c7274 in ATOMcmp () from /usr/local/lib/libbat.so.10 (gdb) where #0 0x00007f474f3c7274 in ATOMcmp () from /usr/local/lib/libbat.so.10 #1 0x00007f474f2f8a88 in BATsubselect () from /usr/local/lib/libbat.so.10 #2 0x00007f474f9225f4 in ALGsubselect2 () from /usr/local/lib/libmonetdb5.so.16 #3 0x00007f474f8c93f7 in malCommandCall () from /usr/local/lib/libmonetdb5.so.16 #4 0x00007f474f8ca9eb in runMALsequence () from /usr/local/lib/libmonetdb5.so.16 #5 0x00007f474f8cb97f in callMAL () from /usr/local/lib/libmonetdb5.so.16 #6 0x00007f474ce41bc0 in SQLengineIntern () from /usr/local/lib/monetdb5/lib_sql.so #7 0x00007f474f8e5b50 in runScenarioBody () from /usr/local/lib/libmonetdb5.so.16 #8 0x00007f474f8e662d in runScenario () from /usr/local/lib/libmonetdb5.so.16 #9 0x00007f474f8e6700 in MSserveClient () from /usr/local/lib/libmonetdb5.so.16 #10 0x00007f474f439c3b in thread_starter () from /usr/local/lib/libbat.so.10 #11 0x00007f474ed37182 in start_thread (arg=0x7f474c3f8700) at pthread_create.c:312 #12 0x00007f474ea63fbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Does that help, or do you need me to rebuild with debug enabled?
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Martin Kersten Sent: 17 September 2014 12:52 To: users-list@monetdb.org Subject: Re: Crashing when querying on date column
On 17/09/14 12:08, Nick Chadwick wrote:
CREATE TABLE "sys"."negs" ( "id" VARCHAR(50) NOT NULL, "xdate" DATE NOT NULL, "market" INTEGER, "product" INTEGER, "notional" DOUBLE, "client" INTEGER, "tier" INTEGER, "status" INTEGER, "dayno" INTEGER, CONSTRAINT "negs_id_xdate_pkey" PRIMARY KEY ("id", "xdate") ); CREATE INDEX "idx_negs_client" ON "sys"."negs" ("client"); CREATE INDEX "idx_negs_market" ON "sys"."negs" ("market"); CREATE INDEX "idx_negs_product" ON "sys"."negs" ("product"); CREATE INDEX "idx_negs_status" ON "sys"."negs" ("status"); CREATE INDEX "idx_negs_tier" ON "sys"."negs" ("tier"); CREATE INDEX "idx_negs_xdate" ON "sys"."negs" ("xdate");
sql>select * from negs; +----+-------+--------+---------+----------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | | dayno | +====+=======+========+=========+==========+========+======+========+=== +====+ +----+-------+--------+---------+----------+--------+------+--------+-------+ 0 tuples (4.456ms) sql>insert into negs values('id',now(),1,1,1.2,1,1,1,1); 1 affected rows (19.534ms) sql>select * from negs; +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | dayno | +======+============+========+=========+==========================+===== +===+======+========+=======+ | id | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ 1 tuple (3.283ms) sql>insert into negs values('id2',now(),1,1,1.2,1,1,1,1); 1 affected rows (16.154ms) sql>select * from negs; +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | dayno | +======+============+========+=========+==========================+===== +===+======+========+=======+ | id | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | | id2 | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ 2 tuples (1.867ms)
we need to dig further. Are you able to work with 'gdb' and produce a stacktrace of the crashed server?
regards, Martin
steps: 1) start mclient 2) other window: ps axl |grep mserver 3) extract the process id of the mserver 4) gdb mserver5 "processid" continue 5) in mclient, activate the malicious query 6) if it crashes, gdb window will say so 7) get stacktrace command: where
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors.
On 17/09/14 14:56, Nick Chadwick wrote:
Here's the stacktrace:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f474c3f8700 (LWP 1215)] 0x00007f474f3c7274 in ATOMcmp () from /usr/local/lib/libbat.so.10 (gdb) where #0 0x00007f474f3c7274 in ATOMcmp () from /usr/local/lib/libbat.so.10 #1 0x00007f474f2f8a88 in BATsubselect () from /usr/local/lib/libbat.so.10 #2 0x00007f474f9225f4 in ALGsubselect2 () from /usr/local/lib/libmonetdb5.so.16 #3 0x00007f474f8c93f7 in malCommandCall () from /usr/local/lib/libmonetdb5.so.16 #4 0x00007f474f8ca9eb in runMALsequence () from /usr/local/lib/libmonetdb5.so.16 #5 0x00007f474f8cb97f in callMAL () from /usr/local/lib/libmonetdb5.so.16 #6 0x00007f474ce41bc0 in SQLengineIntern () from /usr/local/lib/monetdb5/lib_sql.so #7 0x00007f474f8e5b50 in runScenarioBody () from /usr/local/lib/libmonetdb5.so.16 #8 0x00007f474f8e662d in runScenario () from /usr/local/lib/libmonetdb5.so.16 #9 0x00007f474f8e6700 in MSserveClient () from /usr/local/lib/libmonetdb5.so.16 #10 0x00007f474f439c3b in thread_starter () from /usr/local/lib/libbat.so.10 #11 0x00007f474ed37182 in start_thread (arg=0x7f474c3f8700) at pthread_create.c:312 #12 0x00007f474ea63fbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Does that help, or do you need me to rebuild with debug enabled?
A good firt step. If you are able to build for debugging it could provide more information about the column, types, and precise variable that causes havoc. thanks in advance.
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Martin Kersten Sent: 17 September 2014 12:52 To: users-list@monetdb.org Subject: Re: Crashing when querying on date column
On 17/09/14 12:08, Nick Chadwick wrote:
CREATE TABLE "sys"."negs" ( "id" VARCHAR(50) NOT NULL, "xdate" DATE NOT NULL, "market" INTEGER, "product" INTEGER, "notional" DOUBLE, "client" INTEGER, "tier" INTEGER, "status" INTEGER, "dayno" INTEGER, CONSTRAINT "negs_id_xdate_pkey" PRIMARY KEY ("id", "xdate") ); CREATE INDEX "idx_negs_client" ON "sys"."negs" ("client"); CREATE INDEX "idx_negs_market" ON "sys"."negs" ("market"); CREATE INDEX "idx_negs_product" ON "sys"."negs" ("product"); CREATE INDEX "idx_negs_status" ON "sys"."negs" ("status"); CREATE INDEX "idx_negs_tier" ON "sys"."negs" ("tier"); CREATE INDEX "idx_negs_xdate" ON "sys"."negs" ("xdate");
sql>select * from negs; +----+-------+--------+---------+----------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | | dayno | +====+=======+========+=========+==========+========+======+========+=== +====+ +----+-------+--------+---------+----------+--------+------+--------+-------+ 0 tuples (4.456ms) sql>insert into negs values('id',now(),1,1,1.2,1,1,1,1); 1 affected rows (19.534ms) sql>select * from negs; +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | dayno | +======+============+========+=========+==========================+===== +===+======+========+=======+ | id | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ 1 tuple (3.283ms) sql>insert into negs values('id2',now(),1,1,1.2,1,1,1,1); 1 affected rows (16.154ms) sql>select * from negs; +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | dayno | +======+============+========+=========+==========================+===== +===+======+========+=======+ | id | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | | id2 | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ 2 tuples (1.867ms)
we need to dig further. Are you able to work with 'gdb' and produce a stacktrace of the crashed server?
regards, Martin
steps:
- start mclient
- other window: ps axl |grep mserver
- extract the process id of the mserver
- gdb mserver5 "processid"
continue 5) in mclient, activate the malicious query 6) if it crashes, gdb window will say so 7) get stacktrace command: where
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors. _______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
Here's the same, with debug symbols:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fc5f4508700 (LWP 19909)] 0x00007fc5f783c56f in ATOMcmp (t=1323543, l=0x7fc5e80d36b0, r=0x7fc5ef43d000) at gdk_atoms.c:271 271 switch (ATOMstorage(t)) { (gdb) where #0 0x00007fc5f783c56f in ATOMcmp (t=1323543, l=0x7fc5e80d36b0, r=0x7fc5ef43d000) at gdk_atoms.c:271 #1 0x00007fc5f74d3e5c in BAT_hashselect (b=0x1cd6e28, s=0x7fc5e80c2ec8, bn=0x7fc5e80c2ba0, tl=0x7fc5e80d36b0, maximum=1) at gdk_select.c:139 #2 0x00007fc5f76be872 in BATsubselect (b=0x1cd6e00, s=0x7fc5e80c2ea0, tl=0x7fc5e80d36b0, th=0x7fc5e80d36b0, li=1, hi=1, anti=0) at gdk_select.c:1336 #3 0x00007fc5f7e76d9b in ALGsubselect2 (result=0x7fc5e80d3a10, bid=0x7fc5e80d3620, sid=0x7fc5e80d35f0, low=0x7fc5e80d36b0, high=0x7fc5e80d36b0, li=0x7fc5e80d35d0 "\001\004", hi=0x7fc5e80d35d0 "\001\004", anti=0x7fc5e80d36d0 "") at algebra.c:522 #4 0x00007fc5f7df7468 in malCommandCall (stk=0x7fc5e80d3520, pci=0x7fc5e80d5a00) at mal_interpreter.c:127 #5 0x00007fc5f7df9d45 in runMALsequence (cntxt=0x1cf5548, mb=0x7fc5e80c8820, startpc=1, stoppc=0, stk=0x7fc5e80d3520, env=0x0, pcicaller=0x0) at mal_interpreter.c:654 #6 0x00007fc5f7df8e24 in callMAL (cntxt=0x1cf5548, mb=0x7fc5e80c8820, env=0x7fc5f4507c48, argv=0x7fc5f4507cf0, debug=0 '\000') at mal_interpreter.c:465 #7 0x00007fc5f4f5ea67 in SQLexecutePrepared (c=0x1cf5548, be=0x7fc5e80996b0, q=0x7fc5e80c6560) at sql_scenario.c:2224 #8 0x00007fc5f4f5eef4 in SQLengineIntern (c=0x1cf5548, be=0x7fc5e80996b0) at sql_scenario.c:2286 #9 0x00007fc5f4f5f60e in SQLengine (c=0x1cf5548) at sql_scenario.c:2397 #10 0x00007fc5f7e29497 in runPhase (c=0x1cf5548, phase=4) at mal_scenario.c:528 #11 0x00007fc5f7e296a4 in runScenarioBody (c=0x1cf5548) at mal_scenario.c:572 #12 0x00007fc5f7e29791 in runScenario (c=0x1cf5548) at mal_scenario.c:592 #13 0x00007fc5f7e2aff3 in MSserveClient (dummy=0x1cf5548) at mal_session.c:456 #14 0x00007fc5f7906814 in thread_starter (arg=0x7fc5f0000a20) at gdk_system.c:505 #15 0x00007fc5f7022182 in start_thread (arg=0x7fc5f4508700) at pthread_create.c:312 #16 0x00007fc5f6d4efbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Martin Kersten Sent: 17 September 2014 14:15 To: users-list@monetdb.org Subject: Re: Crashing when querying on date column
On 17/09/14 14:56, Nick Chadwick wrote:
Here's the stacktrace:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f474c3f8700 (LWP 1215)] 0x00007f474f3c7274 in ATOMcmp () from /usr/local/lib/libbat.so.10 (gdb) where #0 0x00007f474f3c7274 in ATOMcmp () from /usr/local/lib/libbat.so.10 #1 0x00007f474f2f8a88 in BATsubselect () from /usr/local/lib/libbat.so.10 #2 0x00007f474f9225f4 in ALGsubselect2 () from /usr/local/lib/libmonetdb5.so.16 #3 0x00007f474f8c93f7 in malCommandCall () from /usr/local/lib/libmonetdb5.so.16 #4 0x00007f474f8ca9eb in runMALsequence () from /usr/local/lib/libmonetdb5.so.16 #5 0x00007f474f8cb97f in callMAL () from /usr/local/lib/libmonetdb5.so.16 #6 0x00007f474ce41bc0 in SQLengineIntern () from /usr/local/lib/monetdb5/lib_sql.so #7 0x00007f474f8e5b50 in runScenarioBody () from /usr/local/lib/libmonetdb5.so.16 #8 0x00007f474f8e662d in runScenario () from /usr/local/lib/libmonetdb5.so.16 #9 0x00007f474f8e6700 in MSserveClient () from /usr/local/lib/libmonetdb5.so.16 #10 0x00007f474f439c3b in thread_starter () from /usr/local/lib/libbat.so.10 #11 0x00007f474ed37182 in start_thread (arg=0x7f474c3f8700) at pthread_create.c:312 #12 0x00007f474ea63fbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Does that help, or do you need me to rebuild with debug enabled?
A good firt step. If you are able to build for debugging it could provide more information about the column, types, and precise variable that causes havoc. thanks in advance.
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Martin Kersten Sent: 17 September 2014 12:52 To: users-list@monetdb.org Subject: Re: Crashing when querying on date column
On 17/09/14 12:08, Nick Chadwick wrote:
CREATE TABLE "sys"."negs" ( "id" VARCHAR(50) NOT NULL, "xdate" DATE NOT NULL, "market" INTEGER, "product" INTEGER, "notional" DOUBLE, "client" INTEGER, "tier" INTEGER, "status" INTEGER, "dayno" INTEGER, CONSTRAINT "negs_id_xdate_pkey" PRIMARY KEY ("id", "xdate") ); CREATE INDEX "idx_negs_client" ON "sys"."negs" ("client"); CREATE INDEX "idx_negs_market" ON "sys"."negs" ("market"); CREATE INDEX "idx_negs_product" ON "sys"."negs" ("product"); CREATE INDEX "idx_negs_status" ON "sys"."negs" ("status"); CREATE INDEX "idx_negs_tier" ON "sys"."negs" ("tier"); CREATE INDEX "idx_negs_xdate" ON "sys"."negs" ("xdate");
sql>select * from negs; +----+-------+--------+---------+----------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | | dayno | +====+=======+========+=========+==========+========+======+========+= +== +====+ +----+-------+--------+---------+----------+--------+------+--------+-------+ 0 tuples (4.456ms) sql>insert into negs values('id',now(),1,1,1.2,1,1,1,1); 1 affected rows (19.534ms) sql>select * from negs; +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | dayno | +======+============+========+=========+==========================+=== +== +===+======+========+=======+ | id | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ 1 tuple (3.283ms) sql>insert into negs values('id2',now(),1,1,1.2,1,1,1,1); 1 affected rows (16.154ms) sql>select * from negs; +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | dayno | +======+============+========+=========+==========================+=== +== +===+======+========+=======+ | id | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | | id2 | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ 2 tuples (1.867ms)
we need to dig further. Are you able to work with 'gdb' and produce a stacktrace of the crashed server?
regards, Martin
steps:
- start mclient
- other window: ps axl |grep mserver
- extract the process id of the mserver
- gdb mserver5 "processid"
continue 5) in mclient, activate the malicious query 6) if it crashes, gdb window will say so 7) get stacktrace command: where
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors. _______________________________________________ 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
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors.
The value of the parameter t of ATOMcmp is clearly wrong. That's what causing the crash.
One level up, in BAT_hashselect, can you print *b->H and *b->H->hash
On 17/09/14 15:39, Nick Chadwick wrote:
Here's the same, with debug symbols:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fc5f4508700 (LWP 19909)] 0x00007fc5f783c56f in ATOMcmp (t=1323543, l=0x7fc5e80d36b0, r=0x7fc5ef43d000) at gdk_atoms.c:271 271 switch (ATOMstorage(t)) { (gdb) where #0 0x00007fc5f783c56f in ATOMcmp (t=1323543, l=0x7fc5e80d36b0, r=0x7fc5ef43d000) at gdk_atoms.c:271 #1 0x00007fc5f74d3e5c in BAT_hashselect (b=0x1cd6e28, s=0x7fc5e80c2ec8, bn=0x7fc5e80c2ba0, tl=0x7fc5e80d36b0, maximum=1) at gdk_select.c:139 #2 0x00007fc5f76be872 in BATsubselect (b=0x1cd6e00, s=0x7fc5e80c2ea0, tl=0x7fc5e80d36b0, th=0x7fc5e80d36b0, li=1, hi=1, anti=0) at gdk_select.c:1336 #3 0x00007fc5f7e76d9b in ALGsubselect2 (result=0x7fc5e80d3a10, bid=0x7fc5e80d3620, sid=0x7fc5e80d35f0, low=0x7fc5e80d36b0, high=0x7fc5e80d36b0, li=0x7fc5e80d35d0 "\001\004", hi=0x7fc5e80d35d0 "\001\004", anti=0x7fc5e80d36d0 "") at algebra.c:522 #4 0x00007fc5f7df7468 in malCommandCall (stk=0x7fc5e80d3520, pci=0x7fc5e80d5a00) at mal_interpreter.c:127 #5 0x00007fc5f7df9d45 in runMALsequence (cntxt=0x1cf5548, mb=0x7fc5e80c8820, startpc=1, stoppc=0, stk=0x7fc5e80d3520, env=0x0, pcicaller=0x0) at mal_interpreter.c:654 #6 0x00007fc5f7df8e24 in callMAL (cntxt=0x1cf5548, mb=0x7fc5e80c8820, env=0x7fc5f4507c48, argv=0x7fc5f4507cf0, debug=0 '\000') at mal_interpreter.c:465 #7 0x00007fc5f4f5ea67 in SQLexecutePrepared (c=0x1cf5548, be=0x7fc5e80996b0, q=0x7fc5e80c6560) at sql_scenario.c:2224 #8 0x00007fc5f4f5eef4 in SQLengineIntern (c=0x1cf5548, be=0x7fc5e80996b0) at sql_scenario.c:2286 #9 0x00007fc5f4f5f60e in SQLengine (c=0x1cf5548) at sql_scenario.c:2397 #10 0x00007fc5f7e29497 in runPhase (c=0x1cf5548, phase=4) at mal_scenario.c:528 #11 0x00007fc5f7e296a4 in runScenarioBody (c=0x1cf5548) at mal_scenario.c:572 #12 0x00007fc5f7e29791 in runScenario (c=0x1cf5548) at mal_scenario.c:592 #13 0x00007fc5f7e2aff3 in MSserveClient (dummy=0x1cf5548) at mal_session.c:456 #14 0x00007fc5f7906814 in thread_starter (arg=0x7fc5f0000a20) at gdk_system.c:505 #15 0x00007fc5f7022182 in start_thread (arg=0x7fc5f4508700) at pthread_create.c:312 #16 0x00007fc5f6d4efbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Martin Kersten Sent: 17 September 2014 14:15 To: users-list@monetdb.org Subject: Re: Crashing when querying on date column
On 17/09/14 14:56, Nick Chadwick wrote:
Here's the stacktrace:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f474c3f8700 (LWP 1215)] 0x00007f474f3c7274 in ATOMcmp () from /usr/local/lib/libbat.so.10 (gdb) where #0 0x00007f474f3c7274 in ATOMcmp () from /usr/local/lib/libbat.so.10 #1 0x00007f474f2f8a88 in BATsubselect () from /usr/local/lib/libbat.so.10 #2 0x00007f474f9225f4 in ALGsubselect2 () from /usr/local/lib/libmonetdb5.so.16 #3 0x00007f474f8c93f7 in malCommandCall () from /usr/local/lib/libmonetdb5.so.16 #4 0x00007f474f8ca9eb in runMALsequence () from /usr/local/lib/libmonetdb5.so.16 #5 0x00007f474f8cb97f in callMAL () from /usr/local/lib/libmonetdb5.so.16 #6 0x00007f474ce41bc0 in SQLengineIntern () from /usr/local/lib/monetdb5/lib_sql.so #7 0x00007f474f8e5b50 in runScenarioBody () from /usr/local/lib/libmonetdb5.so.16 #8 0x00007f474f8e662d in runScenario () from /usr/local/lib/libmonetdb5.so.16 #9 0x00007f474f8e6700 in MSserveClient () from /usr/local/lib/libmonetdb5.so.16 #10 0x00007f474f439c3b in thread_starter () from /usr/local/lib/libbat.so.10 #11 0x00007f474ed37182 in start_thread (arg=0x7f474c3f8700) at pthread_create.c:312 #12 0x00007f474ea63fbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Does that help, or do you need me to rebuild with debug enabled?
A good firt step. If you are able to build for debugging it could provide more information about the column, types, and precise variable that causes havoc. thanks in advance.
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Martin Kersten Sent: 17 September 2014 12:52 To: users-list@monetdb.org Subject: Re: Crashing when querying on date column
On 17/09/14 12:08, Nick Chadwick wrote:
CREATE TABLE "sys"."negs" ( "id" VARCHAR(50) NOT NULL, "xdate" DATE NOT NULL, "market" INTEGER, "product" INTEGER, "notional" DOUBLE, "client" INTEGER, "tier" INTEGER, "status" INTEGER, "dayno" INTEGER, CONSTRAINT "negs_id_xdate_pkey" PRIMARY KEY ("id", "xdate") ); CREATE INDEX "idx_negs_client" ON "sys"."negs" ("client"); CREATE INDEX "idx_negs_market" ON "sys"."negs" ("market"); CREATE INDEX "idx_negs_product" ON "sys"."negs" ("product"); CREATE INDEX "idx_negs_status" ON "sys"."negs" ("status"); CREATE INDEX "idx_negs_tier" ON "sys"."negs" ("tier"); CREATE INDEX "idx_negs_xdate" ON "sys"."negs" ("xdate");
sql>select * from negs; +----+-------+--------+---------+----------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | | dayno | +====+=======+========+=========+==========+========+======+========+= +== +====+ +----+-------+--------+---------+----------+--------+------+--------+-------+ 0 tuples (4.456ms) sql>insert into negs values('id',now(),1,1,1.2,1,1,1,1); 1 affected rows (19.534ms) sql>select * from negs; +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | dayno | +======+============+========+=========+==========================+=== +== +===+======+========+=======+ | id | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ 1 tuple (3.283ms) sql>insert into negs values('id2',now(),1,1,1.2,1,1,1,1); 1 affected rows (16.154ms) sql>select * from negs; +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | dayno | +======+============+========+=========+==========================+=== +== +===+======+========+=======+ | id | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | | id2 | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ 2 tuples (1.867ms)
we need to dig further. Are you able to work with 'gdb' and produce a stacktrace of the crashed server?
regards, Martin
steps:
- start mclient
- other window: ps axl |grep mserver
- extract the process id of the mserver
- gdb mserver5 "processid"
continue 5) in mclient, activate the malicious query 6) if it crashes, gdb window will say so 7) get stacktrace command: where
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors. _______________________________________________ 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
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors. _______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
Here they are:
(gdb) p *b->H $2 = {id = 0x7f25307937db "t", width = 4, type = 21 '\025', shift = 2 '\002', varsized = 0, key = 1, dense = 0, nonil = 1, nil = 0, sorted = 0, revsorted = 0, align = 1622213, nokey = {5, 11}, nosorted = 2, norevsorted = 1, nodense = 0, seq = 0, heap = {free = 6000000, size = 6029312, base = 0x7f252c266000 "\r:\v", filename = 0x7f25200c1e30 "12/1204.tail", copied = 0, hashash = 0, forcemap = 0, storage = STORE_MMAP, newstorage = STORE_MMAP, dirty = 0 '\000', parentid = 0}, vheap = 0x0, hash = 0x7f25200d1f90, imprints = 0x0, props = 0x0} (gdb) p *b->H->hash $3 = {type = 1323543, width = 0, nil = 4294967295, lim = 1507328, mask = 2097151, Hash = 0x7f25166c0000, Link = 0x7f2516100000, heap = 0x7f25200d5830}
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Sjoerd Mullender Sent: 17 September 2014 14:48 To: users-list@monetdb.org Subject: Re: Crashing when querying on date column
The value of the parameter t of ATOMcmp is clearly wrong. That's what causing the crash.
One level up, in BAT_hashselect, can you print *b->H and *b->H->hash
On 17/09/14 15:39, Nick Chadwick wrote:
Here's the same, with debug symbols:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fc5f4508700 (LWP 19909)] 0x00007fc5f783c56f in ATOMcmp (t=1323543, l=0x7fc5e80d36b0, r=0x7fc5ef43d000) at gdk_atoms.c:271 271 switch (ATOMstorage(t)) { (gdb) where #0 0x00007fc5f783c56f in ATOMcmp (t=1323543, l=0x7fc5e80d36b0, r=0x7fc5ef43d000) at gdk_atoms.c:271 #1 0x00007fc5f74d3e5c in BAT_hashselect (b=0x1cd6e28, s=0x7fc5e80c2ec8, bn=0x7fc5e80c2ba0, tl=0x7fc5e80d36b0, maximum=1) at gdk_select.c:139 #2 0x00007fc5f76be872 in BATsubselect (b=0x1cd6e00, s=0x7fc5e80c2ea0, tl=0x7fc5e80d36b0, th=0x7fc5e80d36b0, li=1, hi=1, anti=0) at gdk_select.c:1336 #3 0x00007fc5f7e76d9b in ALGsubselect2 (result=0x7fc5e80d3a10, bid=0x7fc5e80d3620, sid=0x7fc5e80d35f0, low=0x7fc5e80d36b0, high=0x7fc5e80d36b0, li=0x7fc5e80d35d0 "\001\004", hi=0x7fc5e80d35d0 "\001\004", anti=0x7fc5e80d36d0 "") at algebra.c:522 #4 0x00007fc5f7df7468 in malCommandCall (stk=0x7fc5e80d3520, pci=0x7fc5e80d5a00) at mal_interpreter.c:127 #5 0x00007fc5f7df9d45 in runMALsequence (cntxt=0x1cf5548, mb=0x7fc5e80c8820, startpc=1, stoppc=0, stk=0x7fc5e80d3520, env=0x0, pcicaller=0x0) at mal_interpreter.c:654 #6 0x00007fc5f7df8e24 in callMAL (cntxt=0x1cf5548, mb=0x7fc5e80c8820, env=0x7fc5f4507c48, argv=0x7fc5f4507cf0, debug=0 '\000') at mal_interpreter.c:465 #7 0x00007fc5f4f5ea67 in SQLexecutePrepared (c=0x1cf5548, be=0x7fc5e80996b0, q=0x7fc5e80c6560) at sql_scenario.c:2224 #8 0x00007fc5f4f5eef4 in SQLengineIntern (c=0x1cf5548, be=0x7fc5e80996b0) at sql_scenario.c:2286 #9 0x00007fc5f4f5f60e in SQLengine (c=0x1cf5548) at sql_scenario.c:2397 #10 0x00007fc5f7e29497 in runPhase (c=0x1cf5548, phase=4) at mal_scenario.c:528 #11 0x00007fc5f7e296a4 in runScenarioBody (c=0x1cf5548) at mal_scenario.c:572 #12 0x00007fc5f7e29791 in runScenario (c=0x1cf5548) at mal_scenario.c:592 #13 0x00007fc5f7e2aff3 in MSserveClient (dummy=0x1cf5548) at mal_session.c:456 #14 0x00007fc5f7906814 in thread_starter (arg=0x7fc5f0000a20) at gdk_system.c:505 #15 0x00007fc5f7022182 in start_thread (arg=0x7fc5f4508700) at pthread_create.c:312 #16 0x00007fc5f6d4efbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Martin Kersten Sent: 17 September 2014 14:15 To: users-list@monetdb.org Subject: Re: Crashing when querying on date column
On 17/09/14 14:56, Nick Chadwick wrote:
Here's the stacktrace:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f474c3f8700 (LWP 1215)] 0x00007f474f3c7274 in ATOMcmp () from /usr/local/lib/libbat.so.10 (gdb) where #0 0x00007f474f3c7274 in ATOMcmp () from /usr/local/lib/libbat.so.10 #1 0x00007f474f2f8a88 in BATsubselect () from /usr/local/lib/libbat.so.10 #2 0x00007f474f9225f4 in ALGsubselect2 () from /usr/local/lib/libmonetdb5.so.16 #3 0x00007f474f8c93f7 in malCommandCall () from /usr/local/lib/libmonetdb5.so.16 #4 0x00007f474f8ca9eb in runMALsequence () from /usr/local/lib/libmonetdb5.so.16 #5 0x00007f474f8cb97f in callMAL () from /usr/local/lib/libmonetdb5.so.16 #6 0x00007f474ce41bc0 in SQLengineIntern () from /usr/local/lib/monetdb5/lib_sql.so #7 0x00007f474f8e5b50 in runScenarioBody () from /usr/local/lib/libmonetdb5.so.16 #8 0x00007f474f8e662d in runScenario () from /usr/local/lib/libmonetdb5.so.16 #9 0x00007f474f8e6700 in MSserveClient () from /usr/local/lib/libmonetdb5.so.16 #10 0x00007f474f439c3b in thread_starter () from /usr/local/lib/libbat.so.10 #11 0x00007f474ed37182 in start_thread (arg=0x7f474c3f8700) at pthread_create.c:312 #12 0x00007f474ea63fbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Does that help, or do you need me to rebuild with debug enabled?
A good firt step. If you are able to build for debugging it could provide more information about the column, types, and precise variable that causes havoc. thanks in advance.
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Martin Kersten Sent: 17 September 2014 12:52 To: users-list@monetdb.org Subject: Re: Crashing when querying on date column
On 17/09/14 12:08, Nick Chadwick wrote:
CREATE TABLE "sys"."negs" ( "id" VARCHAR(50) NOT NULL, "xdate" DATE NOT NULL, "market" INTEGER, "product" INTEGER, "notional" DOUBLE, "client" INTEGER, "tier" INTEGER, "status" INTEGER, "dayno" INTEGER, CONSTRAINT "negs_id_xdate_pkey" PRIMARY KEY ("id", "xdate") ); CREATE INDEX "idx_negs_client" ON "sys"."negs" ("client"); CREATE INDEX "idx_negs_market" ON "sys"."negs" ("market"); CREATE INDEX "idx_negs_product" ON "sys"."negs" ("product"); CREATE INDEX "idx_negs_status" ON "sys"."negs" ("status"); CREATE INDEX "idx_negs_tier" ON "sys"."negs" ("tier"); CREATE INDEX "idx_negs_xdate" ON "sys"."negs" ("xdate");
sql>select * from negs; +----+-------+--------+---------+----------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | | dayno | +====+=======+========+=========+==========+========+======+========+ += +== +====+ +----+-------+--------+---------+----------+--------+------+--------+-------+ 0 tuples (4.456ms) sql>insert into negs values('id',now(),1,1,1.2,1,1,1,1); 1 affected rows (19.534ms) sql>select * from negs; +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | dayno | +======+============+========+=========+==========================+== += +== +===+======+========+=======+ | id | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ 1 tuple (3.283ms) sql>insert into negs values('id2',now(),1,1,1.2,1,1,1,1); 1 affected rows (16.154ms) sql>select * from negs; +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | dayno | +======+============+========+=========+==========================+== += +== +===+======+========+=======+ | id | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | | id2 | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ 2 tuples (1.867ms)
we need to dig further. Are you able to work with 'gdb' and produce a stacktrace of the crashed server?
regards, Martin
steps:
- start mclient
- other window: ps axl |grep mserver
- extract the process id of the mserver
- gdb mserver5 "processid"
continue 5) in mclient, activate the malicious query 6) if it crashes, gdb window will say so 7) get stacktrace command: where
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors. _______________________________________________ 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
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors. _______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
-- Sjoerd Mullender
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors.
I've also just hit another crash, this time when running the following query:
Select market, sum(notional) from negs where status in (4,5) group by market
Here's the stacktrace for that one:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f4699465700 (LWP 3296)] 0x00007f469c77b941 in fullscan_int (b=0x7f4688003bc0, s=0x0, bn=0x7f4688004380, tl=0x7f468c0dcd00, th=0x7f468c0dcd00, li=1, hi=1, equi=1, anti=0, lval=1, hval=1, r=0, q=375000, cnt=16192, off=1125000, dst=0x7f4688004600, candlist=0x0, maximum=1, use_imprints=0) at gdk_select.c:595 595 scan_sel(fullscan, o = (oid) (p+off), w = (BUN) (q+off)) (gdb) bt #0 0x00007f469c77b941 in fullscan_int (b=0x7f4688003bc0, s=0x0, bn=0x7f4688004380, tl=0x7f468c0dcd00, th=0x7f468c0dcd00, li=1, hi=1, equi=1, anti=0, lval=1, hval=1, r=0, q=375000, cnt=16192, off=1125000, dst=0x7f4688004600, candlist=0x0, maximum=1, use_imprints=0) at gdk_select.c:595 #1 0x00007f469c816a60 in BAT_scanselect (b=0x7f4688003bc0, s=0x0, bn=0x7f4688004380, tl=0x7f468c0dcd00, th=0x7f468c0dcd00, li=1, hi=1, equi=1, anti=0, lval=1, hval=1, maximum=1, use_imprints=0) at gdk_select.c:714 #2 0x00007f469c81c986 in BATsubselect (b=0x7f4688003bc0, s=0x0, tl=0x7f468c0dcd00, th=0x7f468c0dcd00, li=1, hi=1, anti=0) at gdk_select.c:1351 #3 0x00007f469cfd4d9b in ALGsubselect2 (result=0x7f468c0dd430, bid=0x7f468c0dd3f0, sid=0x0, low=0x7f468c0dcd00, high=0x7f468c0dcd00, li=0x7f468c0dcd20 "\001\004", hi=0x7f468c0dcd20 "\001\004", anti=0x7f468c0dcdb0 "") at algebra.c:522 #4 0x00007f469cfd4e61 in ALGsubselect1 (result=0x7f468c0dd430, bid=0x7f468c0dd3f0, low=0x7f468c0dcd00, high=0x7f468c0dcd00, li=0x7f468c0dcd20 "\001\004", hi=0x7f468c0dcd20 "\001\004", anti=0x7f468c0dcdb0 "") at algebra.c:536 #5 0x00007f469cf55359 in malCommandCall (stk=0x7f468c0dcc60, pci=0x7f468c0d6880) at mal_interpreter.c:118 #6 0x00007f469cf57d45 in runMALsequence (cntxt=0xb43248, mb=0x7f468c0d5ce0, startpc=69, stoppc=70, stk=0x7f468c0dcc60, env=0x0, pcicaller=0x0) at mal_interpreter.c:654 #7 0x00007f469cf5c4e9 in DFLOWworker (T=0x7f469d398fc0 <workers>) at mal_dataflow.c:358 #8 0x00007f469c180182 in start_thread (arg=0x7f4699465700) at pthread_create.c:312 #9 0x00007f469beacfbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Thanks for your continuing assistance, and sorry to be a pain!
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Nick Chadwick Sent: 17 September 2014 15:04 To: Communication channel for MonetDB users Subject: RE: Crashing when querying on date column
Here they are:
(gdb) p *b->H $2 = {id = 0x7f25307937db "t", width = 4, type = 21 '\025', shift = 2 '\002', varsized = 0, key = 1, dense = 0, nonil = 1, nil = 0, sorted = 0, revsorted = 0, align = 1622213, nokey = {5, 11}, nosorted = 2, norevsorted = 1, nodense = 0, seq = 0, heap = {free = 6000000, size = 6029312, base = 0x7f252c266000 "\r:\v", filename = 0x7f25200c1e30 "12/1204.tail", copied = 0, hashash = 0, forcemap = 0, storage = STORE_MMAP, newstorage = STORE_MMAP, dirty = 0 '\000', parentid = 0}, vheap = 0x0, hash = 0x7f25200d1f90, imprints = 0x0, props = 0x0} (gdb) p *b->H->hash $3 = {type = 1323543, width = 0, nil = 4294967295, lim = 1507328, mask = 2097151, Hash = 0x7f25166c0000, Link = 0x7f2516100000, heap = 0x7f25200d5830}
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Sjoerd Mullender Sent: 17 September 2014 14:48 To: users-list@monetdb.org Subject: Re: Crashing when querying on date column
The value of the parameter t of ATOMcmp is clearly wrong. That's what causing the crash.
One level up, in BAT_hashselect, can you print *b->H and *b->H->hash
On 17/09/14 15:39, Nick Chadwick wrote:
Here's the same, with debug symbols:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fc5f4508700 (LWP 19909)] 0x00007fc5f783c56f in ATOMcmp (t=1323543, l=0x7fc5e80d36b0, r=0x7fc5ef43d000) at gdk_atoms.c:271 271 switch (ATOMstorage(t)) { (gdb) where #0 0x00007fc5f783c56f in ATOMcmp (t=1323543, l=0x7fc5e80d36b0, r=0x7fc5ef43d000) at gdk_atoms.c:271 #1 0x00007fc5f74d3e5c in BAT_hashselect (b=0x1cd6e28, s=0x7fc5e80c2ec8, bn=0x7fc5e80c2ba0, tl=0x7fc5e80d36b0, maximum=1) at gdk_select.c:139 #2 0x00007fc5f76be872 in BATsubselect (b=0x1cd6e00, s=0x7fc5e80c2ea0, tl=0x7fc5e80d36b0, th=0x7fc5e80d36b0, li=1, hi=1, anti=0) at gdk_select.c:1336 #3 0x00007fc5f7e76d9b in ALGsubselect2 (result=0x7fc5e80d3a10, bid=0x7fc5e80d3620, sid=0x7fc5e80d35f0, low=0x7fc5e80d36b0, high=0x7fc5e80d36b0, li=0x7fc5e80d35d0 "\001\004", hi=0x7fc5e80d35d0 "\001\004", anti=0x7fc5e80d36d0 "") at algebra.c:522 #4 0x00007fc5f7df7468 in malCommandCall (stk=0x7fc5e80d3520, pci=0x7fc5e80d5a00) at mal_interpreter.c:127 #5 0x00007fc5f7df9d45 in runMALsequence (cntxt=0x1cf5548, mb=0x7fc5e80c8820, startpc=1, stoppc=0, stk=0x7fc5e80d3520, env=0x0, pcicaller=0x0) at mal_interpreter.c:654 #6 0x00007fc5f7df8e24 in callMAL (cntxt=0x1cf5548, mb=0x7fc5e80c8820, env=0x7fc5f4507c48, argv=0x7fc5f4507cf0, debug=0 '\000') at mal_interpreter.c:465 #7 0x00007fc5f4f5ea67 in SQLexecutePrepared (c=0x1cf5548, be=0x7fc5e80996b0, q=0x7fc5e80c6560) at sql_scenario.c:2224 #8 0x00007fc5f4f5eef4 in SQLengineIntern (c=0x1cf5548, be=0x7fc5e80996b0) at sql_scenario.c:2286 #9 0x00007fc5f4f5f60e in SQLengine (c=0x1cf5548) at sql_scenario.c:2397 #10 0x00007fc5f7e29497 in runPhase (c=0x1cf5548, phase=4) at mal_scenario.c:528 #11 0x00007fc5f7e296a4 in runScenarioBody (c=0x1cf5548) at mal_scenario.c:572 #12 0x00007fc5f7e29791 in runScenario (c=0x1cf5548) at mal_scenario.c:592 #13 0x00007fc5f7e2aff3 in MSserveClient (dummy=0x1cf5548) at mal_session.c:456 #14 0x00007fc5f7906814 in thread_starter (arg=0x7fc5f0000a20) at gdk_system.c:505 #15 0x00007fc5f7022182 in start_thread (arg=0x7fc5f4508700) at pthread_create.c:312 #16 0x00007fc5f6d4efbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Martin Kersten Sent: 17 September 2014 14:15 To: users-list@monetdb.org Subject: Re: Crashing when querying on date column
On 17/09/14 14:56, Nick Chadwick wrote:
Here's the stacktrace:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f474c3f8700 (LWP 1215)] 0x00007f474f3c7274 in ATOMcmp () from /usr/local/lib/libbat.so.10 (gdb) where #0 0x00007f474f3c7274 in ATOMcmp () from /usr/local/lib/libbat.so.10 #1 0x00007f474f2f8a88 in BATsubselect () from /usr/local/lib/libbat.so.10 #2 0x00007f474f9225f4 in ALGsubselect2 () from /usr/local/lib/libmonetdb5.so.16 #3 0x00007f474f8c93f7 in malCommandCall () from /usr/local/lib/libmonetdb5.so.16 #4 0x00007f474f8ca9eb in runMALsequence () from /usr/local/lib/libmonetdb5.so.16 #5 0x00007f474f8cb97f in callMAL () from /usr/local/lib/libmonetdb5.so.16 #6 0x00007f474ce41bc0 in SQLengineIntern () from /usr/local/lib/monetdb5/lib_sql.so #7 0x00007f474f8e5b50 in runScenarioBody () from /usr/local/lib/libmonetdb5.so.16 #8 0x00007f474f8e662d in runScenario () from /usr/local/lib/libmonetdb5.so.16 #9 0x00007f474f8e6700 in MSserveClient () from /usr/local/lib/libmonetdb5.so.16 #10 0x00007f474f439c3b in thread_starter () from /usr/local/lib/libbat.so.10 #11 0x00007f474ed37182 in start_thread (arg=0x7f474c3f8700) at pthread_create.c:312 #12 0x00007f474ea63fbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Does that help, or do you need me to rebuild with debug enabled?
A good firt step. If you are able to build for debugging it could provide more information about the column, types, and precise variable that causes havoc. thanks in advance.
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Martin Kersten Sent: 17 September 2014 12:52 To: users-list@monetdb.org Subject: Re: Crashing when querying on date column
On 17/09/14 12:08, Nick Chadwick wrote:
CREATE TABLE "sys"."negs" ( "id" VARCHAR(50) NOT NULL, "xdate" DATE NOT NULL, "market" INTEGER, "product" INTEGER, "notional" DOUBLE, "client" INTEGER, "tier" INTEGER, "status" INTEGER, "dayno" INTEGER, CONSTRAINT "negs_id_xdate_pkey" PRIMARY KEY ("id", "xdate") ); CREATE INDEX "idx_negs_client" ON "sys"."negs" ("client"); CREATE INDEX "idx_negs_market" ON "sys"."negs" ("market"); CREATE INDEX "idx_negs_product" ON "sys"."negs" ("product"); CREATE INDEX "idx_negs_status" ON "sys"."negs" ("status"); CREATE INDEX "idx_negs_tier" ON "sys"."negs" ("tier"); CREATE INDEX "idx_negs_xdate" ON "sys"."negs" ("xdate");
sql>select * from negs; +----+-------+--------+---------+----------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | | dayno | +====+=======+========+=========+==========+========+======+========+ += +== +====+ +----+-------+--------+---------+----------+--------+------+--------+-------+ 0 tuples (4.456ms) sql>insert into negs values('id',now(),1,1,1.2,1,1,1,1); 1 affected rows (19.534ms) sql>select * from negs; +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | dayno | +======+============+========+=========+==========================+== += +== +===+======+========+=======+ | id | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ 1 tuple (3.283ms) sql>insert into negs values('id2',now(),1,1,1.2,1,1,1,1); 1 affected rows (16.154ms) sql>select * from negs; +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | dayno | +======+============+========+=========+==========================+== += +== +===+======+========+=======+ | id | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | | id2 | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ 2 tuples (1.867ms)
we need to dig further. Are you able to work with 'gdb' and produce a stacktrace of the crashed server?
regards, Martin
steps:
- start mclient
- other window: ps axl |grep mserver
- extract the process id of the mserver
- gdb mserver5 "processid"
continue 5) in mclient, activate the malicious query 6) if it crashes, gdb window will say so 7) get stacktrace command: where
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors. _______________________________________________ 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
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors. _______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
-- Sjoerd Mullender
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors. _______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors.
Can you run the server with property checking enabled? You can do that by adding the option -d10 (no space) to the invocation of mserver5.
In this crash it looks like the BAT that is selected on is supposed to have unique values. If that is not in fact true, I can easily understand the crash. Property checking checks for that kind of mismatch (at a cost, obviously).
On 17/09/14 17:24, Nick Chadwick wrote:
I've also just hit another crash, this time when running the following query:
Select market, sum(notional) from negs where status in (4,5) group by market
Here's the stacktrace for that one:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f4699465700 (LWP 3296)] 0x00007f469c77b941 in fullscan_int (b=0x7f4688003bc0, s=0x0, bn=0x7f4688004380, tl=0x7f468c0dcd00, th=0x7f468c0dcd00, li=1, hi=1, equi=1, anti=0, lval=1, hval=1, r=0, q=375000, cnt=16192, off=1125000, dst=0x7f4688004600, candlist=0x0, maximum=1, use_imprints=0) at gdk_select.c:595 595 scan_sel(fullscan, o = (oid) (p+off), w = (BUN) (q+off)) (gdb) bt #0 0x00007f469c77b941 in fullscan_int (b=0x7f4688003bc0, s=0x0, bn=0x7f4688004380, tl=0x7f468c0dcd00, th=0x7f468c0dcd00, li=1, hi=1, equi=1, anti=0, lval=1, hval=1, r=0, q=375000, cnt=16192, off=1125000, dst=0x7f4688004600, candlist=0x0, maximum=1, use_imprints=0) at gdk_select.c:595 #1 0x00007f469c816a60 in BAT_scanselect (b=0x7f4688003bc0, s=0x0, bn=0x7f4688004380, tl=0x7f468c0dcd00, th=0x7f468c0dcd00, li=1, hi=1, equi=1, anti=0, lval=1, hval=1, maximum=1, use_imprints=0) at gdk_select.c:714 #2 0x00007f469c81c986 in BATsubselect (b=0x7f4688003bc0, s=0x0, tl=0x7f468c0dcd00, th=0x7f468c0dcd00, li=1, hi=1, anti=0) at gdk_select.c:1351 #3 0x00007f469cfd4d9b in ALGsubselect2 (result=0x7f468c0dd430, bid=0x7f468c0dd3f0, sid=0x0, low=0x7f468c0dcd00, high=0x7f468c0dcd00, li=0x7f468c0dcd20 "\001\004", hi=0x7f468c0dcd20 "\001\004", anti=0x7f468c0dcdb0 "") at algebra.c:522 #4 0x00007f469cfd4e61 in ALGsubselect1 (result=0x7f468c0dd430, bid=0x7f468c0dd3f0, low=0x7f468c0dcd00, high=0x7f468c0dcd00, li=0x7f468c0dcd20 "\001\004", hi=0x7f468c0dcd20 "\001\004", anti=0x7f468c0dcdb0 "") at algebra.c:536 #5 0x00007f469cf55359 in malCommandCall (stk=0x7f468c0dcc60, pci=0x7f468c0d6880) at mal_interpreter.c:118 #6 0x00007f469cf57d45 in runMALsequence (cntxt=0xb43248, mb=0x7f468c0d5ce0, startpc=69, stoppc=70, stk=0x7f468c0dcc60, env=0x0, pcicaller=0x0) at mal_interpreter.c:654 #7 0x00007f469cf5c4e9 in DFLOWworker (T=0x7f469d398fc0 <workers>) at mal_dataflow.c:358 #8 0x00007f469c180182 in start_thread (arg=0x7f4699465700) at pthread_create.c:312 #9 0x00007f469beacfbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Thanks for your continuing assistance, and sorry to be a pain!
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Nick Chadwick Sent: 17 September 2014 15:04 To: Communication channel for MonetDB users Subject: RE: Crashing when querying on date column
Here they are:
(gdb) p *b->H $2 = {id = 0x7f25307937db "t", width = 4, type = 21 '\025', shift = 2 '\002', varsized = 0, key = 1, dense = 0, nonil = 1, nil = 0, sorted = 0, revsorted = 0, align = 1622213, nokey = {5, 11}, nosorted = 2, norevsorted = 1, nodense = 0, seq = 0, heap = {free = 6000000, size = 6029312, base = 0x7f252c266000 "\r:\v", filename = 0x7f25200c1e30 "12/1204.tail", copied = 0, hashash = 0, forcemap = 0, storage = STORE_MMAP, newstorage = STORE_MMAP, dirty = 0 '\000', parentid = 0}, vheap = 0x0, hash = 0x7f25200d1f90, imprints = 0x0, props = 0x0} (gdb) p *b->H->hash $3 = {type = 1323543, width = 0, nil = 4294967295, lim = 1507328, mask = 2097151, Hash = 0x7f25166c0000, Link = 0x7f2516100000, heap = 0x7f25200d5830}
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Sjoerd Mullender Sent: 17 September 2014 14:48 To: users-list@monetdb.org Subject: Re: Crashing when querying on date column
The value of the parameter t of ATOMcmp is clearly wrong. That's what causing the crash.
One level up, in BAT_hashselect, can you print *b->H and *b->H->hash
On 17/09/14 15:39, Nick Chadwick wrote:
Here's the same, with debug symbols:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fc5f4508700 (LWP 19909)] 0x00007fc5f783c56f in ATOMcmp (t=1323543, l=0x7fc5e80d36b0, r=0x7fc5ef43d000) at gdk_atoms.c:271 271 switch (ATOMstorage(t)) { (gdb) where #0 0x00007fc5f783c56f in ATOMcmp (t=1323543, l=0x7fc5e80d36b0, r=0x7fc5ef43d000) at gdk_atoms.c:271 #1 0x00007fc5f74d3e5c in BAT_hashselect (b=0x1cd6e28, s=0x7fc5e80c2ec8, bn=0x7fc5e80c2ba0, tl=0x7fc5e80d36b0, maximum=1) at gdk_select.c:139 #2 0x00007fc5f76be872 in BATsubselect (b=0x1cd6e00, s=0x7fc5e80c2ea0, tl=0x7fc5e80d36b0, th=0x7fc5e80d36b0, li=1, hi=1, anti=0) at gdk_select.c:1336 #3 0x00007fc5f7e76d9b in ALGsubselect2 (result=0x7fc5e80d3a10, bid=0x7fc5e80d3620, sid=0x7fc5e80d35f0, low=0x7fc5e80d36b0, high=0x7fc5e80d36b0, li=0x7fc5e80d35d0 "\001\004", hi=0x7fc5e80d35d0 "\001\004", anti=0x7fc5e80d36d0 "") at algebra.c:522 #4 0x00007fc5f7df7468 in malCommandCall (stk=0x7fc5e80d3520, pci=0x7fc5e80d5a00) at mal_interpreter.c:127 #5 0x00007fc5f7df9d45 in runMALsequence (cntxt=0x1cf5548, mb=0x7fc5e80c8820, startpc=1, stoppc=0, stk=0x7fc5e80d3520, env=0x0, pcicaller=0x0) at mal_interpreter.c:654 #6 0x00007fc5f7df8e24 in callMAL (cntxt=0x1cf5548, mb=0x7fc5e80c8820, env=0x7fc5f4507c48, argv=0x7fc5f4507cf0, debug=0 '\000') at mal_interpreter.c:465 #7 0x00007fc5f4f5ea67 in SQLexecutePrepared (c=0x1cf5548, be=0x7fc5e80996b0, q=0x7fc5e80c6560) at sql_scenario.c:2224 #8 0x00007fc5f4f5eef4 in SQLengineIntern (c=0x1cf5548, be=0x7fc5e80996b0) at sql_scenario.c:2286 #9 0x00007fc5f4f5f60e in SQLengine (c=0x1cf5548) at sql_scenario.c:2397 #10 0x00007fc5f7e29497 in runPhase (c=0x1cf5548, phase=4) at mal_scenario.c:528 #11 0x00007fc5f7e296a4 in runScenarioBody (c=0x1cf5548) at mal_scenario.c:572 #12 0x00007fc5f7e29791 in runScenario (c=0x1cf5548) at mal_scenario.c:592 #13 0x00007fc5f7e2aff3 in MSserveClient (dummy=0x1cf5548) at mal_session.c:456 #14 0x00007fc5f7906814 in thread_starter (arg=0x7fc5f0000a20) at gdk_system.c:505 #15 0x00007fc5f7022182 in start_thread (arg=0x7fc5f4508700) at pthread_create.c:312 #16 0x00007fc5f6d4efbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Martin Kersten Sent: 17 September 2014 14:15 To: users-list@monetdb.org Subject: Re: Crashing when querying on date column
On 17/09/14 14:56, Nick Chadwick wrote:
Here's the stacktrace:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f474c3f8700 (LWP 1215)] 0x00007f474f3c7274 in ATOMcmp () from /usr/local/lib/libbat.so.10 (gdb) where #0 0x00007f474f3c7274 in ATOMcmp () from /usr/local/lib/libbat.so.10 #1 0x00007f474f2f8a88 in BATsubselect () from /usr/local/lib/libbat.so.10 #2 0x00007f474f9225f4 in ALGsubselect2 () from /usr/local/lib/libmonetdb5.so.16 #3 0x00007f474f8c93f7 in malCommandCall () from /usr/local/lib/libmonetdb5.so.16 #4 0x00007f474f8ca9eb in runMALsequence () from /usr/local/lib/libmonetdb5.so.16 #5 0x00007f474f8cb97f in callMAL () from /usr/local/lib/libmonetdb5.so.16 #6 0x00007f474ce41bc0 in SQLengineIntern () from /usr/local/lib/monetdb5/lib_sql.so #7 0x00007f474f8e5b50 in runScenarioBody () from /usr/local/lib/libmonetdb5.so.16 #8 0x00007f474f8e662d in runScenario () from /usr/local/lib/libmonetdb5.so.16 #9 0x00007f474f8e6700 in MSserveClient () from /usr/local/lib/libmonetdb5.so.16 #10 0x00007f474f439c3b in thread_starter () from /usr/local/lib/libbat.so.10 #11 0x00007f474ed37182 in start_thread (arg=0x7f474c3f8700) at pthread_create.c:312 #12 0x00007f474ea63fbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Does that help, or do you need me to rebuild with debug enabled?
A good firt step. If you are able to build for debugging it could provide more information about the column, types, and precise variable that causes havoc. thanks in advance.
-----Original Message----- From: users-list [mailto:users-list-bounces+nickc=digiterre.com@monetdb.org] On Behalf Of Martin Kersten Sent: 17 September 2014 12:52 To: users-list@monetdb.org Subject: Re: Crashing when querying on date column
On 17/09/14 12:08, Nick Chadwick wrote:
CREATE TABLE "sys"."negs" ( "id" VARCHAR(50) NOT NULL, "xdate" DATE NOT NULL, "market" INTEGER, "product" INTEGER, "notional" DOUBLE, "client" INTEGER, "tier" INTEGER, "status" INTEGER, "dayno" INTEGER, CONSTRAINT "negs_id_xdate_pkey" PRIMARY KEY ("id", "xdate") ); CREATE INDEX "idx_negs_client" ON "sys"."negs" ("client"); CREATE INDEX "idx_negs_market" ON "sys"."negs" ("market"); CREATE INDEX "idx_negs_product" ON "sys"."negs" ("product"); CREATE INDEX "idx_negs_status" ON "sys"."negs" ("status"); CREATE INDEX "idx_negs_tier" ON "sys"."negs" ("tier"); CREATE INDEX "idx_negs_xdate" ON "sys"."negs" ("xdate");
sql>select * from negs; +----+-------+--------+---------+----------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | | dayno | +====+=======+========+=========+==========+========+======+========+ += +== +====+ +----+-------+--------+---------+----------+--------+------+--------+-------+ 0 tuples (4.456ms) sql>insert into negs values('id',now(),1,1,1.2,1,1,1,1); 1 affected rows (19.534ms) sql>select * from negs; +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | dayno | +======+============+========+=========+==========================+== += +== +===+======+========+=======+ | id | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ 1 tuple (3.283ms) sql>insert into negs values('id2',now(),1,1,1.2,1,1,1,1); 1 affected rows (16.154ms) sql>select * from negs; +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ | id | xdate | market | product | notional | client | tier | status | dayno | +======+============+========+=========+==========================+== += +== +===+======+========+=======+ | id | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | | id2 | 2014-09-17 | 1 | 1 | 1.2 | 1 | 1 | 1 | 1 | +------+------------+--------+---------+--------------------------+--------+------+--------+-------+ 2 tuples (1.867ms)
we need to dig further. Are you able to work with 'gdb' and produce a stacktrace of the crashed server?
regards, Martin
steps:
- start mclient
- other window: ps axl |grep mserver
- extract the process id of the mserver
- gdb mserver5 "processid"
continue 5) in mclient, activate the malicious query 6) if it crashes, gdb window will say so 7) get stacktrace command: where
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors. _______________________________________________ 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
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors. _______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
-- Sjoerd Mullender
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors. _______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
www.digiterre.com _________________
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Digiterre does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Digiterre does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Digiterre are neither given nor endorsed by the company or its directors. _______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
participants (4)
-
Martin Kersten -
Nick Chadwick -
Niels Nes -
Sjoerd Mullender