Date: 2010-07-09 13:25:36 +0200
From: @skinkie
To: SQL devs <>
Version: 2.38.3 (Jun2010-SP1) [obsolete]
CC: @njnes, @drstmane

Last updated: 2010-08-30 09:18:00 +0200

Comment 14304

Date: 2010-07-09 13:25:36 +0200
From: @skinkie

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.86 Safari/533.4
Build Identifier:

select kvk from kvk where kvk not in (select kvk from kvk_nieuw union select
kvk from kvk_extra union select kvk from kvk_extra_nieuw);

kvk_nieuw does not exist here; sub expression executes as part and results in a proper error:
SELECT: no such table 'kvk_nieuw'

0x00007fffe43eb143 in rel_logical_exp (sql=0x147b068, rel=0x0, sc=0x167c278,
f=1) at ../../../src/server/rel_select.mx:2655
warning: Source file is more recent than executable.
2655 r = rel_value_exp(sql, &rel,
sval, f, ek);
(gdb) bt
0 0x00007fffe43eb143 in rel_logical_exp (sql=0x147b068, rel=0x0,
sc=0x167c278, f=1) at ../../../src/server/rel_select.mx:2655
1 0x00007fffe43f1c8c in rel_select_exp (sql=0x147b068, rel=0xab7ba8,
outer=0x0, sn=0x167c378, ek=...) at ../../../src/server/rel_select.mx:4410
2 0x00007fffe43f3233 in rel_query (sql=0x147b068, rel=0x0, sq=0x167c378,
toplevel=1, ek=...) at ../../../src/server/rel_select.mx:4730
3 0x00007fffe43f46b2 in rel_subquery (sql=0x147b068, rel=0x0, sq=0x167c378,
ek=...) at ../../../src/server/rel_select.mx:5073
4 0x00007fffe43f472c in rel_selects (sql=0x147b068, s=0x167c378) at
../../../src/server/rel_select.mx:5084
5 0x00007fffe43e2ade in rel_semantic (sql=0x147b068, s=0x167c378) at
../../../src/server/rel_semantic.mx:336
6 0x00007fffe43484c3 in sql_symbol2stmt (c=0x147b068, sym=0x167c378) at
../../../../src/backends/monet5/sql.mx:1362
7 0x00007fffe43945f6 in SQLparser (c=0x605878) at
../../../../src/backends/monet5/sql_scenario.mx:1275
8 0x00007ffff7b04fb2 in runPhase (c=0x605878, phase=1) at
../../../src/mal/mal_scenario.mx:604
9 0x00007ffff7b050ea in runScenarioBody (c=0x605878) at
../../../src/mal/mal_scenario.mx:646
10 0x00007ffff7b05371 in runScenario (c=0x605878) at
../../../src/mal/mal_scenario.mx:682
11 0x00007ffff7ab92af in MSserveClient (dummy=0x605878) at
../../../src/mal/mal_session.mx:473
12 0x00007ffff57a9547 in start_thread () from /lib/libpthread.so.0
13 0x00007ffff48db28d in clone () from /lib/libc.so.6
(gdb) q

Reproducible: Always

Comment 14308

Date: 2010-07-09 13:37:21 +0200
From: @drstmane

"warning: Source file is more recent than executable."

Are you sure your build & testing environment is clean and consistent?

Comment 14309

Date: 2010-07-09 13:39:15 +0200
From: @drstmane

While your debugger back-traces reveal the location where the segfault happens,
printing also the values of all variables used by the statement that segfault could help to also locate the actual reason for the segfault.

Comment 14311

Date: 2010-07-09 13:43:26 +0200
From: @drstmane

a much simple way to reproduce the segfault:

create table t1 (a int);
-> operation successful

select * from t1;
-> 0 tuples

select * from t2;
-> SELECT: no such table 't2'

select * from t1 where a in (select b from t2);
-> server segfault

(also with Jun2010)

Comment 14312

Date: 2010-07-09 13:46:37 +0200
From: @drstmane

and here's a gdb log with sources that match the compiled binaries and hence reveals the correct location of the segfault

$ gdb mserver5
GNU gdb (GDB) Fedora (7.0.1-48.fc12)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /net/rig.ins.cwi.nl/export/scratch0/manegold/Monet/HG/Jun2010/prefix.--enable-strict_--disable-optimize_--enable-debug_--enable-assert/bin/mserver5...done.
(gdb) r
Starting program: /net/rig.ins.cwi.nl/export/scratch0/manegold/Monet/HG/Jun2010/prefix.--enable-strict_--disable-optimize_--enable-debug_--enable-assert/bin/mserver5
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffea65b710 (LWP 17587)]
MonetDB server v5.20.3, based on kernel v1.38.2
Serving database 'demo', using 4 threads
Compiled for x86_64-unknown-linux-gnu/64bit with 64bit OIDs dynamically linked
Found 7.751 GiB available main-memory.
Copyright (c) 1993-July 2008 CWI.
Copyright (c) August 2008-2010 MonetDB B.V., all rights reserved
Visit http://monetdb.cwi.nl/ for further information
warning: please don't forget to set your vault key!
(see /ufs/manegold//scratch0/Monet/HG/Jun2010/prefix.--enable-strict--disable-optimize_--enable-debug_--enable-assert/etc/monetdb5.conf)
[New Thread 0x7fffdf89b710 (LWP 17588)]
Listening for connection requests on mapi:monetdb://127.0.0.1:50000/
MonetDB/SQL module v2.38.3 loaded
[New Thread 0x7fffdf69a710 (LWP 17589)]
MonetDB/GIS module v0.18.1 loaded

[New Thread 0x7fffdf499710 (LWP 17591)]
[New Thread 0x7fffdf298710 (LWP 17592)]
[New Thread 0x7fffdf097710 (LWP 17593)]
[New Thread 0x7fffdee96710 (LWP 17594)]
[New Thread 0x7fffdec95710 (LWP 17595)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdf499710 (LWP 17591)]
0x00007fffe03285ff in rel_logical_exp (sql=0x7fffd0005438, rel=0x0, sc=0x7fffd00d60d8, f=1) at /ufs/manegold//scratch0/Monet/HG/Jun2010/source/sql/src/server/rel_select.mx:2657
2657 if (!is_project(rel->op)) {
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.5-6.fc12.x86_64 cyrus-sasl-lib-2.1.23-9.fc12.x86_64 geos-3.2.1-1.fc12.x86_64 glibc-2.11.2-1.x86_64 keyutils-libs-1.2-6.fc12.x86_64 krb5-libs-1.7.1-9.fc12.x86_64 libcom_err-1.41.9-7.fc12.x86_64 libcurl-7.19.7-10.fc12.x86_64 libgcc-4.4.4-10.fc12.x86_64 libidn-1.9-5.x86_64 libselinux-2.0.90-5.fc12.x86_64 libssh2-1.2.4-1.fc12.x86_64 libstdc++-4.4.4-10.fc12.x86_64 libuuid-2.16.2-9.fc12.x86_64 libxml2-2.7.6-2.fc12.x86_64 libxslt-1.1.26-1.fc12.x86_64 ncurses-libs-5.7-3.20090207.fc12.x86_64 nspr-4.8.4-2.fc12.x86_64 nss-3.12.6-7.fc12.x86_64 nss-softokn-freebl-3.12.6-2.fc12.1.x86_64 nss-util-3.12.6-1.fc12.x86_64 openldap-2.4.19-4.fc12.x86_64 openssl-1.0.0a-1.fc12.x86_64 pcre-7.8-3.fc12.x86_64 raptor-1.4.18-5.fc12.x86_64 readline-6.0-3.fc12.x86_64 zlib-1.2.3-23.fc12.x86_64
(gdb) bt
0 0x00007fffe03285ff in rel_logical_exp (sql=0x7fffd0005438, rel=0x0, sc=0x7fffd00d60d8, f=1) at /ufs/manegold//scratch0/Monet/HG/Jun2010/source/sql/src/server/rel_select.mx:2657
1 0x00007fffe032f203 in rel_select_exp (sql=0x7fffd0005438, rel=0x7fffd008a568, outer=0x0, sn=0x7fffd00d61d8, ek=...) at /ufs/manegold//scratch0/Monet/HG/Jun2010/source/sql/src/server/rel_select.mx:4425
2 0x00007fffe03307a9 in rel_query (sql=0x7fffd0005438, rel=0x0, sq=0x7fffd00d61d8, toplevel=1, ek=...) at /ufs/manegold//scratch0/Monet/HG/Jun2010/source/sql/src/server/rel_select.mx:4745
3 0x00007fffe0331c28 in rel_subquery (sql=0x7fffd0005438, rel=0x0, sq=0x7fffd00d61d8, ek=...) at /ufs/manegold//scratch0/Monet/HG/Jun2010/source/sql/src/server/rel_select.mx:5088
4 0x00007fffe0331ca2 in rel_selects (sql=0x7fffd0005438, s=0x7fffd00d61d8) at /ufs/manegold//scratch0/Monet/HG/Jun2010/source/sql/src/server/rel_select.mx:5099
5 0x00007fffe031ff5d in rel_semantic (sql=0x7fffd0005438, s=0x7fffd00d61d8) at /ufs/manegold//scratch0/Monet/HG/Jun2010/source/sql/src/server/rel_semantic.mx:336
6 0x00007fffe028545f in sql_symbol2stmt (c=0x7fffd0005438, sym=0x7fffd00d61d8) at /ufs/manegold//scratch0/Monet/HG/Jun2010/source/sql/src/backends/monet5/sql.mx:1340
7 0x00007fffe02d1856 in SQLparser (c=0x605b38) at /ufs/manegold//scratch0/Monet/HG/Jun2010/source/sql/src/backends/monet5/sql_scenario.mx:1203
8 0x00007ffff7d22c92 in runPhase (c=0x605b38, phase=1) at /ufs/manegold//scratch0/Monet/HG/Jun2010/source/MonetDB5/src/mal/mal_scenario.mx:604
9 0x00007ffff7d22dca in runScenarioBody (c=0x605b38) at /ufs/manegold//scratch0/Monet/HG/Jun2010/source/MonetDB5/src/mal/mal_scenario.mx:646
10 0x00007ffff7d23051 in runScenario (c=0x605b38) at /ufs/manegold//scratch0/Monet/HG/Jun2010/source/MonetDB5/src/mal/mal_scenario.mx:682
11 0x00007ffff7cd6f0d in MSserveClient (dummy=0x605b38) at /ufs/manegold/_/scratch0/Monet/HG/Jun2010/source/MonetDB5/src/mal/mal_session.mx:473
12 0x000000347c406a3a in start_thread () from /lib64/libpthread.so.0
13 0x000000347b8de77d in clone () from /lib64/libc.so.6
14 0x0000000000000000 in ?? ()
(gdb) li
2652 sql->errstr[0] = 0;
2653
2654 /* TODO remove null checking (not needed in correlated case because of the semi/anti join) ! */
2655 rel = left = rel_dup(left);
2656 r = rel_value_exp(sql, &rel, sval, f, ek);
2657 if (!is_project(rel->op)) {
2658 rel = rel_project(rel, NULL);
2659 rel_project_add_exp(sql, rel, r);
2660 }
2661 z = rel;
(gdb) p rel
$1 = (sql_rel *) 0x0
(gdb)

Comment 14314

Date: 2010-07-09 13:59:23 +0200
From: @skinkie

(In reply to comment 1)

"warning: Source file is more recent than executable."

Are you sure your build & testing environment is clean and consistent?

Since the only thing since I touched the openkvk machine today was replying and showing errors. And the request in the unixODBC-bug of a month ago required a recompilation without my fix, it is pretty obvious that I don't have n-trees on my machine for each bug that I submit.

(In reply to comment 2)

While your debugger back-traces reveal the location where the segfault happens,
printing also the values of all variables used by the statement that segfault
could help to also locate the actual reason for the segfault.

Could you elaborate what values /can/, /should/ and /must/ be shown and how this can be achieved from within gdb? It would be a great addition to the debugging and monetdb-internals documentation.

I'm not talking about randomly type print <> present in the list for that stackdepth.

Comment 14317

Date: 2010-07-09 14:40:47 +0200
From: @drstmane

There is no need to have "n-trees" on your machine and I surely did not ask for that. However, debugger traces do not make any sense if the source code available when running the debugger is not the very same version of the source code that the binaries that the debugger runs are compiled from. Basically, the compiled code contains references to the original source code that allow the debugger to show the code that is executed. If the source code has been changed between compiling it and running the compiled binaries in the debugger, these references might/will not point to the correct lines any more. Consequently, debugger traces are useless in that case. That's why the debugger warns you if your source are new then the binaries and hence potentially modified since compilation. If you compare your trace to mine, you'll notice that the reported location of the segfault differs. I'm pretty sure, though, the segfault in you case happened in the statement as in my case; however, since your source seems to have been modified since their compilation, the debugger points to a wrong line/statement. --- This is not critique, just a hint. To locate and fix bugs, we need sufficient and accurate information. Incorrect information is misleading and delays/prevents bug fixing.

Most frequent candidates for segfault are, e.g., null-pointer dereferences;
hence looking for pointer dereferences in the very statement where the segfault occurs --- provided the configuration is clean and sound, i.e., source code matches binaries; see above --- and printing the pointers values is a good starting point.
E.g., in my log the segfault is reported in the statement
2657 if (!is_project(rel->op)) {
Obviously, rel is a pointer that is dereferenced here; hence
(gdb) p rel
$1 = (sql_rel *) 0x0
reveals that indeed rel being a null-pointer causes the segfault, here.
(Now it's our task to find out why rel is null, and whether we either need to prevent that or correctly deal with it ...)

Comment 14671

Date: 2010-08-13 02:21:00 +0200
From: @skinkie

Can do something like this?

diff -r 65a029afacb5 sql/src/server/rel_select.mx
--- a/sql/src/server/rel_select.mx Thu Aug 12 12:44:23 2010 +0200
+++ b/sql/src/server/rel_select.mx Fri Aug 13 02:20:16 2010 +0200
@@ -2656,12 +2656,14 @@
/* TODO remove null checking (not needed in correlated case because of the semi/anti join) ! */
rel = left = rel_dup(left);
r = rel_value_exp(sql, &rel, sval, f, ek);

•                                   if (!is_project(rel->op)) {
  

•                                           rel = rel_project(rel, NULL);
  

•                                           rel_project_add_exp(sql, rel, r);
  

•                                   if (r) {
  

•                                           if (!is_project(rel->op)) {
  

•                                                   rel = rel_project(rel, NULL);
  

•                                                   rel_project_add_exp(sql, rel, r);
  

•                                           }
  

•                                           z = rel;
  

•                                           correlated = 1;
                                    }
  

•                                   z = rel;
  

•                                   correlated = 1;
                            }
                            if (!r || !(r=rel_check_type(sql, st, r, type_equal))) {
                                    exp_destroy(r);
  

Comment 14739

Date: 2010-08-19 18:28:03 +0200
From: @njnes

Changeset 2565be77974c made by Niels Nes niels@cwi.nl in the MonetDB repo, refers to this bug.

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

Changeset description:

check for return values properly (should solve bug #2604)

Comment 14740

Date: 2010-08-19 18:33:20 +0200
From: @njnes

Changeset f63520ed7cb9 made by Niels Nes niels@cwi.nl in the MonetDB repo, refers to this bug.

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

Changeset description:

added test for Bug #2604

Comment 14794

Date: 2010-08-30 09:18:00 +0200
From: @sjoerdmullender

The Jun2010-SP2 version has been released.