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.