Navigation Menu

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

SQL: extremely long and complex query causes SEGFAULT #104

Closed
monetdb-team opened this issue Nov 30, 2020 · 0 comments
Closed

SQL: extremely long and complex query causes SEGFAULT #104

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

Comments

@monetdb-team
Copy link

Date: 2004-03-22 06:04:40 +0100
From: @sjoerdmullender
To: SQL devs <>
Version: 2.40.1 (Oct2010) [obsolete]
CC: @romulogoncalves, @njnes, @drstmane

Last updated: 2011-03-28 17:31:43 +0200

Comment 547

Date: 2004-03-22 18:04:40 +0100
From: @sjoerdmullender

The attached file contains a query from the crash-me
script that causes a SEGFAULT in the server.

My guess is that there is a buffer overflow in
sql_gencode. I'm looking into it.

Comment 548

Date: 2004-03-22 20:09:12 +0100
From: @njnes

Logged In: YES
user_id=43556

A to large column name was generated. Column names are now
protected,
but a full audit (buffer overflow) of sql_gencode is needed.

Comment 549

Date: 2005-10-06 12:34:49 +0200
From: @drstmane

Logged In: YES
user_id=572415

BugDay_2005-10-06: CLAIMED BY stmane

BugDay_2005-10-06: TEST ADDED / FAILURE
test (excl. stable.out) added as
sql/src/test/BugDay_2005-10-06_2.9.3/Tests/huge_expression_and_column_name.SF-921173.*

bug re-opened, as the segfault re-occurs (at least with
MonetDB 4.9.3 + SQL 2.9.3 compiled with gcc 4.0.1 on my
64-bit Fedora Core sytem)

It might very well be that we run out of stack space with a
rather deep recursion...!

Comment 550

Date: 2005-10-23 00:11:55 +0200
From: @njnes

Logged In: YES
user_id=43556

check for to big (recursion depth) queries is added.

Comment 551

Date: 2005-10-23 13:57:33 +0200
From: @njnes

Logged In: YES
user_id=43556

check for to big (recursion depth) queries is added.

Comment 552

Date: 2006-01-14 13:35:02 +0100
From: @drstmane

Logged In: YES
user_id=572415

re-opend as it segfauls on the same platforms as
1314982 "kill(0) causes SEGFAULT"
https://sourceforge.net/tracker/index.php?func=detail&aid=1314982&group_id=56967&atid=482468
and
1292727 "Mserver segfault because of 'col_name'"
https://sourceforge.net/tracker/index.php?func=detail&aid=1292727&group_id=56967&atid=482468

Fedora Core 4 (32-bit)
http://monetdb.cwi.nl/testing/projects/monetdb/Current/sql/.mTests103/GNU.32.32.d-Fedora4/src_test_BugDay_2005-10-06_2.9.3/huge_expression_and_column_name.SF-921173.err.00.html
Gentoo 1.6.13 (32-bit)
http://monetdb.cwi.nl/testing/projects/monetdb/Current/sql/.mTests103/GNU.32.32.d-Gentoo1.6.13/src_test_BugDay_2005-10-06_2.9.3/huge_expression_and_column_name.SF-921173.err.00.html
SuSE 9.3 (32-bit)
http://monetdb.cwi.nl/testing/projects/monetdb/Current/sql/.mTests103/GNU.32.32.d-SuSE9.3/src_test_BugDay_2005-10-06_2.9.3/huge_expression_and_column_name.SF-921173.err.00.html
SuSE 9ES (32-bit)
http://monetdb.cwi.nl/testing/projects/monetdb/Current/sql/.mTests103/GNU.32.32.d-SuSE9ES/src_test_BugDay_2005-10-06_2.9.3/huge_expression_and_column_name.SF-921173.err.00.html

Comment 553

Date: 2006-01-15 14:15:29 +0100
From: @drstmane

Logged In: YES
user_id=572415

Closed as the actual/original bug is fixed.

The segfault on some platforms is file in this new report
1406591 "several tests cause segfault on the same subset
of
platforms"
https://sourceforge.net/tracker/index.php?func=detail&aid=1406591&group_id=56967&atid=482468

Comment 554

Date: 2008-06-01 21:44:08 +0200
From: @drstmane

Logged In: YES
user_id=572415
Originator: NO

Re-opened as the respective test fails again (still?).

With M5 server (both default and "algebra" SQL compiler), only the output seems to differ (returns "NULL" instead of "2001"):
http://monetdb.cwi.nl/testing/projects/monetdb/Stable/sql/.mTests5103/GNU.64.64.d-Fedora8/src_test_BugDay_2005-10-06_2.9.3/huge_expression_and_column_name.SF-921173.out.00.html
http://monetdb.cwi.nl/testing/projects/monetdb/Stable/sql/.mTestsG103/GNU.64.64.d-Fedora8/src_test_BugDay_2005-10-06_2.9.3/huge_expression_and_column_name.SF-921173.out.00.html

With M4 server, the test triggers a segfault (at least on some architectures):
http://monetdb.cwi.nl/testing/projects/monetdb/Stable/sql/.mTests4103/GNU.64.64.d-Fedora8/src_test_BugDay_2005-10-06_2.9.3/huge_expression_and_column_name.SF-921173.err.00.html

Comment 555

Date: 2008-06-02 09:13:45 +0200
From: @njnes

Logged In: YES
user_id=43556
Originator: NO

The problem here is overflow detection. On gdk and m4/m5 level we need to introduce some overflow exceptions.

Comment 556

Date: 2008-11-10 09:08:14 +0100
From: @mlkersten

The overflow is caused by the SQL default to assume a tinyint type
as argument. We cannot assume the compiler to be more clever.
The result is an overflow which is correctly catched
with a null. (provided tinyint is 0-255 ;))

Comment 557

Date: 2009-02-15 21:08:19 +0100
From: @drstmane

test sql/src/test/BugDay_2005-10-06_2.9.3/Tests/huge_expression_and_column_name.SF-921173* has been disabled in the Feb2009 release branch as the bug won't be fixed, there.

Comment 558

Date: 2009-08-13 18:40:04 +0200
From: @drstmane

Should this test be disabled in the Aug2009 branch, again?
cf.
http://monetdb.cwi.nl/testing/projects/monetdb/Stable/sql/.mTests103/GNU.64.64.d.1-Fedora10/src_test_BugDay_2005-10-06_2.9.3/huge_expression_and_column_name.SF-921173.out.00.html

Comment 559

Date: 2009-08-14 14:02:52 +0200
From: @drstmane

tagged subject

Comment 560

Date: 2009-11-16 23:19:19 +0100
From: @drstmane

test has been disabled in Nov2009 branch, only.

Comment 561

Date: 2009-11-29 17:01:04 +0100
From: @njnes

closed, we no longjmp out of the recursion.

The overflow problem which we used to hit here (when we didn't crash) isn't fixed but is covered by the 'case overflow bug'.

Comment 562

Date: 2010-05-04 09:32:09 +0200
From: Pseudo user for Sourceforge import <>

This bug was previously known as tracker item 921173 at http://sourceforge.net/support/tracker.php?aid=921173

Comment 14385

Date: 2010-07-13 14:54:16 +0200
From: @sjoerdmullender

*** Bug #2610 has been marked as a duplicate of this bug. ***

Comment 14386

Date: 2010-07-13 15:00:20 +0200
From: @sjoerdmullender

This crashes in the Jun2010 branch.

Comment 14387

Date: 2010-07-13 15:04:31 +0200
From: @sjoerdmullender

Looks like a double free (but of course it could be something entirely different):

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdf49b710 (LWP 17101)]
0x00007fffe038582a in sa_destroy (sa=0x7fffd0007608)
at /ufs/sjoerd/src/MonetDB/candidate/sql/src/common/sql_mem.mx:136
136 GDKfree(sa->blks[i]);
(gdb) p sa
$1 = (sql_allocator *) 0x7fffd0007608
(gdb) p *sa
$2 = {size = 15842497851538791387, nr = 15842497851538791387,
blks = 0xdbdbdbdbdbdbdbdb, used = 15842497851538791387}
(gdb) bt
0 0x00007fffe038582a in sa_destroy (sa=0x7fffd0007608)
at /ufs/sjoerd/src/MonetDB/candidate/sql/src/common/sql_mem.mx:136
1 0x00007fffe02ffb7b in cq_delete (clientid=1, q=0x7fffd03e3a08)
at /ufs/sjoerd/src/MonetDB/candidate/sql/src/server/sql_qc.mx:117
2 0x00007fffe02ffc57 in qc_destroy (cache=0x7fffd00075a8)
at /ufs/sjoerd/src/MonetDB/candidate/sql/src/server/sql_qc.mx:147
3 0x00007fffe031a425 in mvc_destroy (m=0x7fffd0005438)
at /ufs/sjoerd/src/MonetDB/candidate/sql/src/server/sql_mvc.mx:753
4 0x00007fffe02d2739 in SQLexitClient (c=0x605b38)
at /ufs/sjoerd/src/MonetDB/candidate/sql/src/backends/monet5/sql_scenario.mx:492
5 0x00007ffff7d22ee7 in runScenarioBody (c=0x605b38)
at /ufs/sjoerd/src/MonetDB/candidate/MonetDB5/src/mal/mal_scenario.mx:670
6 0x00007ffff7d22f3d in runScenario (c=0x605b38)
at /ufs/sjoerd/src/MonetDB/candidate/MonetDB5/src/mal/mal_scenario.mx:682
7 0x00007ffff7cd6e99 in MSserveClient (dummy=0x605b38)
at /ufs/sjoerd/src/MonetDB/candidate/MonetDB5/src/mal/mal_session.mx:473
8 0x0000003a8d606a3a in start_thread () from /lib64/libpthread.so.0
9 0x0000003a8cade77d in clone () from /lib64/libc.so.6
10 0x0000000000000000 in ?? ()
(gdb)

Comment 14847

Date: 2010-08-30 09:23:22 +0200
From: @sjoerdmullender

The Jun2010-SP2 version has been released.

Comment 14864

Date: 2010-08-30 17:01:49 +0200
From: @sjoerdmullender

Changeset http://dev.monetdb.org/hg/MonetDB/rev/ea928da4ea87 fixed the latest incarnation of this bug.

Comment 14865

Date: 2010-08-30 17:04:09 +0200
From: @sjoerdmullender

Changeset e4a025a9f189 made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.

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

Changeset description:

Added changelog for bug #104.

Comment 15163

Date: 2010-10-30 11:23:40 +0200
From: @drstmane

Is this bug indeed fixed?

The respective test does not trigger any crash or error anymore,
but the result is (unexpectedly) NULL;
cf.,

http://monetdb.cwi.nl/testing/projects/monetdb/Candidate/sql/.mTests103/GNU.64.64.d.1-Fedora10/src_test_BugDay_2005-10-06_2.9.3/huge_expression_and_column_name.SF-921173.out.00.html

Comment 15258

Date: 2010-12-03 21:31:00 +0100
From: @njnes

crash is fixed now (by the flattend stmt tree). Still a fix for the overflow
is needed (but covered by the overflow bug report)

Comment 15658

Date: 2011-03-28 17:31:43 +0200
From: @sjoerdmullender

The Mar2011 version has been released.

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