Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

segmentation fault when a select query (with group by) is run on server with "--single-user" option #2821

Closed
monetdb-team opened this issue Nov 30, 2020 · 0 comments
Labels
bug Something isn't working normal SQL

Comments

@monetdb-team
Copy link

Date: 2011-06-13 07:46:53 +0200
From: ramaK <<ramakumar_rk>>
To: SQL devs <>
Version: 11.3.3 (Apr2011-SP1) [obsolete]
CC: @njnes, @drstmane

Last updated: 2011-07-29 10:52:39 +0200

Comment 15843

Date: 2011-06-13 07:46:53 +0200
From: ramaK <<ramakumar_rk>>

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110422 Ubuntu/10.10 (maverick) Firefox/3.6.17
Build Identifier:

On a server started with "--single-user" option, trying to run any select query with group by on Multiple columns crashes the server (segmentation fault). Observed similar behaviour while trying to create Index on a table.

Reproducible: Always

Steps to Reproduce:

1.Start server with "sudo mserver5 --dbfarm='/home/user/work/tmp/data/test' --single-user"
2.start mclient
3.create a simple table and fire a select query with group by on multiple columns

create table test ( market_size int not null, market int not null, state int not null);
select count(*) from test group by market_size, state;

Actual Results:

server crashes (segmentation fault)

Expected Results:

The select query should fetch the results without crashing the server

  1. Same query works properly when "--single-user" option is not used while starting the server
  2. Bug exists both in Linux and Windows (did not try on any other OS)
  3. complete version information
    MonetDB 5 server v11.3.3 "Apr2011-SP1" (64-bit, 64-bit oids)
    Copyright (c) 1993-July 2008 CWI
    Copyright (c) August 2008-2011 MonetDB B.V., all rights reserved
    Visit http://monetdb.cwi.nl/ for further information
    Found 3.9GiB available memory, 2 available cpu cores
    Libraries:
    libpcre: 8.02 2010-03-19 (compiled with 8.02)
    openssl: OpenSSL 0.9.8o 01 Jun 2010 (compiled with OpenSSL 0.9.8o 01 Jun 2010)
    libxml2: 2.7.7 (compiled with 2.7.7)
    Compiled by: root@ottar.ins.cwi.nl (x86_64-pc-linux-gnu)
    Compilation: gcc -Wall -O6 -fomit-frame-pointer -finline-functions -falign-loops=4 -falign-jumps=4 -falign-functions=4 -fexpensive-optimizations -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -ftree-vectorize
    Linking : /usr/bin/ld -m elf_x86_64 -Wl,-Bsymbolic-functions

Comment 15844

Date: 2011-06-13 10:12:14 +0200
From: @drstmane

The problem appears to be a not (correcly) initialized store_funcs.sorted_col .

sql_trans_is_sorted() tries to call store_funcs.sorted_col(), but that is NULL
(see below).

I haven't found, yet, where / why store_funcs.sorted_col is not (correctly) initialized in --single-user mode (only) ...

========
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe7ba8700 (LWP 6422)]
0x0000000000000000 in ?? ()
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-1.fc14.1.x86_64 cfitsio-3.250-5.fc14.x86_64 cyrus-sasl-lib-2.1.23-12.fc14.x86_64 geos-3.2.1-3.fc14.x86_64 glibc-2.12.90-21.x86_64 keyutils-libs-1.2-6.fc12.x86_64 krb5-libs-1.8.2-10.fc14.x86_64 libcom_err-1.41.12-6.fc14.x86_64 libcurl-7.21.0-6.fc14.x86_64 libgcc-4.5.1-4.fc14.x86_64 libidn-1.18-1.fc14.x86_64 libselinux-2.0.96-6.fc14.1.x86_64 libssh2-1.2.4-1.fc14.x86_64 libstdc++-4.5.1-4.fc14.x86_64 libxml2-2.7.7-3.fc14.x86_64 ncurses-libs-5.7-9.20100703.fc14.x86_64 nspr-4.8.8-1.fc14.x86_64 nss-3.12.10-1.fc14.x86_64 nss-softokn-freebl-3.12.10-1.fc14.x86_64 nss-util-3.12.10-1.fc14.x86_64 openldap-2.4.23-4.fc14.x86_64 openssl-1.0.0d-1.fc14.x86_64 pcre-8.10-1.fc14.x86_64 readline-6.1-2.fc14.x86_64 zlib-1.2.5-2.fc14.x86_64
(gdb) bt
0 0x0000000000000000 in ?? ()
1 0x00007fffe868615c in sql_trans_is_sorted (tr=0x7fffd8018208, col=0x7fffd806cb68) at /ufs/manegold//scratch0/Monet/HG/Apr2011/source/MonetDB/sql/storage/store.c:4153
2 0x00007fffe861545e in mvc_is_sorted (m=0x7fffd8005468, col=0x7fffd806cb68) at /ufs/manegold/
/scratch0/Monet/HG/Apr2011/source/MonetDB/sql/server/sql_mvc.c:1210
3 0x00007fffe8649cb2 in score_gbe (sql=0x7fffd8005468, rel=0x7fffd80f7cc8, e=0x7fffd80f7b88) at /ufs/manegold//scratch0/Monet/HG/Apr2011/source/MonetDB/sql/server/rel_optimizer.c:2619
4 0x00007fffe8649eec in rel_groupby_order (changes=0x7fffe7ba7acc, sql=0x7fffd8005468, rel=0x7fffd80f7cc8) at /ufs/manegold/
/scratch0/Monet/HG/Apr2011/source/MonetDB/sql/server/rel_optimizer.c:2647
5 0x00007fffe864d75c in rewrite (sql=0x7fffd8005468, rel=0x7fffd80f7cc8, rewriter=0x7fffe8649de5 <rel_groupby_order>, has_changes=0x7fffe7ba7bbc) at /ufs/manegold//scratch0/Monet/HG/Apr2011/source/MonetDB/sql/server/rel_optimizer.c:3880
6 0x00007fffe864d693 in rewrite (sql=0x7fffd8005468, rel=0x7fffd80f7d78, rewriter=0x7fffe8649de5 <rel_groupby_order>, has_changes=0x7fffe7ba7bbc) at /ufs/manegold/
/scratch0/Monet/HG/Apr2011/source/MonetDB/sql/server/rel_optimizer.c:3865
7 0x00007fffe864dd18 in rel_optimizer (sql=0x7fffd8005468, rel=0x7fffd80f7d78, level=0) at /ufs/manegold//scratch0/Monet/HG/Apr2011/source/MonetDB/sql/server/rel_optimizer.c:4024
8 0x00007fffe864de93 in rel_optimizer (sql=0x7fffd8005468, rel=0x7fffd80f7d78) at /ufs/manegold//scratch0/Monet/HG/Apr2011/source/MonetDB/sql/server/rel_optimizer.c:4059
9 0x00007fffe85845d1 in sql_symbol2stmt (c=0x7fffd8005468, sym=0x7fffd80f77b8) at /ufs/manegold/
/scratch0/Monet/HG/Apr2011/source/MonetDB/sql/backends/monet5/sql.mx:1500
10 0x00007fffe85e5e8c in SQLparser (c=0x606098) at /ufs/manegold//scratch0/Monet/HG/Apr2011/source/MonetDB/sql/backends/monet5/sql_scenario.mx:1316
11 0x00007ffff6d35a45 in runPhase (c=0x606098, phase=1) at /ufs/manegold/
/scratch0/Monet/HG/Apr2011/source/MonetDB/monetdb5/mal/mal_scenario.mx:604
12 0x00007ffff6d35b7d in runScenarioBody (c=0x606098) at /ufs/manegold//scratch0/Monet/HG/Apr2011/source/MonetDB/monetdb5/mal/mal_scenario.mx:645
13 0x00007ffff6d35e04 in runScenario (c=0x606098) at /ufs/manegold/
/scratch0/Monet/HG/Apr2011/source/MonetDB/monetdb5/mal/mal_scenario.mx:682
14 0x00007ffff6d36e02 in MSserveClient (dummy=0x606098) at /ufs/manegold//scratch0/Monet/HG/Apr2011/source/MonetDB/monetdb5/mal/mal_session.mx:486
15 0x0000003d95606d5b in start_thread () from /lib64/libpthread.so.0
16 0x0000003d94ae4a7d in clone () from /lib64/libc.so.6
(gdb) up
1 0x00007fffe868615c in sql_trans_is_sorted (tr=0x7fffd8018208, col=0x7fffd806cb68) at /ufs/manegold/
/scratch0/Monet/HG/Apr2011/source/MonetDB/sql/storage/store.c:4153
4153 if (col && store_funcs.sorted_col(tr, col))
(gdb) li
4148 }
4149
4150 int
4151 sql_trans_is_sorted( sql_trans *tr, sql_column *col )
4152 {
4153 if (col && store_funcs.sorted_col(tr, col))
4154 return 1;
4155 return 0;
4156 }
4157
(gdb) p tr
$1 = (sql_trans *) 0x7fffd8018208
(gdb) p *tr
$2 = {name = 0x0, stime = 7, rtime = 0, wtime = 0, schema_number = 0, schema_updates = 0, status = 0, dropped = 0x0, schemas = {sa = 0x0, destroy = 0x7fffe86768cd <schema_destroy>, set = 0x7fffd8087808, dset = 0x0, nelm = 0x0}, parent = 0xef4ee8, stk = 0}
(gdb) p col
$3 = (sql_column *) 0x7fffd806cb68
(gdb) p *col
$4 = {base = {wtime = 0, rtime = 0, flag = 0, id = 5655, name = 0x7fffd806cbe8 "market_size"}, type = {type = 0xe661a8, digits = 32, scale = 0, comp_type = 0x0}, colnr = 0, null = 0 '\000', def = 0x0, unique = 0 '\000', drop_action = 0, storage_type = 0x0, sorted = 0, t = 0x7fffd806c6e8,
data = 0x7fffd806cc18}
(gdb) p store_funcs
$5 = {bind_col = 0x7fffe869449a <bind_col>, bind_idx = 0x7fffe869457f <bind_idx>, bind_del = 0x7fffe8694664 <bind_del>, append_col = 0x7fffe8695055 <append_col>, append_idx = 0x7fffe8695127 <append_idx>, update_col = 0x7fffe8694c4a <update_col>, update_idx = 0x7fffe8694d44 <update_idx>,
delete_tab = 0x7fffe8695384 <delete_tab>, count_col = 0x7fffe8695508 <count_col>, count_idx = 0x7fffe8695526 <count_idx>, sorted_col = 0, create_col = 0x7fffe86957b2 <create_col>, create_idx = 0x7fffe8695a48 <create_idx>, create_del = 0x7fffe8695cc2 <create_del>, dup_col = 0x7fffe8696089 <dup_col>,
dup_idx = 0x7fffe86960f4 <dup_idx>, dup_del = 0x7fffe869615f <dup_del>, destroy_col = 0x7fffe8696415 <destroy_col>, destroy_idx = 0x7fffe86964ab <destroy_idx>, destroy_del = 0x7fffe8696541 <destroy_del>, clear_col = 0x7fffe86966f6 <clear_col>, clear_idx = 0x7fffe8696736 <clear_idx>,
clear_del = 0x7fffe8696776 <clear_del>, log_create_col = 0x7fffe8695966 <log_create_col>, log_create_idx = 0x7fffe8695be0 <log_create_idx>, log_create_del = 0x7fffe8695e82 <log_create_del>, log_destroy_col = 0x7fffe869647f <log_destroy_col>, log_destroy_idx = 0x7fffe8696515 <log_destroy_idx>,
log_destroy_del = 0x7fffe86965b1 <log_destroy_del>, snapshot_create_col = 0x7fffe86959d7 <snapshot_create_col>, snapshot_create_idx = 0x7fffe8695c51 <snapshot_create_idx>, snapshot_create_del = 0x7fffe8695f38 <snapshot_create_del>, snapshot_destroy_col = 0, snapshot_destroy_idx = 0,
snapshot_destroy_del = 0, snapshot_table = 0x7fffe86972cf <snapshot_table>, log_table = 0x7fffe8696ded <log_table>, update_table = 0x7fffe8696845 <update_table>, gtrans_update = 0, gtrans_minmax = 0, col_ins = 0, col_upd = 0, idx_ins = 0, idx_upd = 0, del = 0}
(gdb) p store_funcs.sorted_col
$6 = (sorted_col_fptr) 0 <===== !!!
^
!
(gdb)

Comment 15858

Date: 2011-06-29 14:57:50 +0200
From: @sjoerdmullender

(In reply to comment 1)

The problem appears to be a not (correcly) initialized store_funcs.sorted_col .

sql_trans_is_sorted() tries to call store_funcs.sorted_col(), but that is NULL
(see below).

I haven't found, yet, where / why store_funcs.sorted_col is not (correctly)
initialized in --single-user mode (only) ...

store_funcs is initialized in store_init (sql/storage/store.c) which calls different functions to do the real initialization depending on flags such as --single-user. In the case of --single-user, su_storage_init() is called which indeed fails to initialize the sorted_col field. The other initialization functions do initialize the field.

Since this is a SQL problem I changed the product.

Comment 15876

Date: 2011-07-02 10:42:24 +0200
From: @njnes

initialisation is now fixed.

Comment 15998

Date: 2011-07-29 10:52:39 +0200
From: @sjoerdmullender

The Apr2011-SP2 bugfix release is out.

@monetdb-team monetdb-team added bug Something isn't working normal SQL labels Nov 30, 2020
@sjoerdmullender sjoerdmullender added this to the Ancient Release milestone Nov 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working normal SQL
Projects
None yet
Development

No branches or pull requests

2 participants