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

segfault caused by select rank() on a newly-loaded table #3341

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

segfault caused by select rank() on a newly-loaded table #3341

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

Comments

@monetdb-team
Copy link

@monetdb-team monetdb-team commented Nov 30, 2020

Date: 2013-08-12 23:51:32 +0200
From: Tim H. <<monetdb.bug.reporter>>
To: GDK devs <>
Version: 11.15.7 (Feb2013-SP2)
CC: @njnes

Last updated: 2013-09-27 13:47:13 +0200

Comment 18993

Date: 2013-08-12 23:51:32 +0200
From: Tim H. <<monetdb.bug.reporter>>

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36
Build Identifier:

mserver5 segfaults when I do the following in the same database session: create a table, load it with data and then issue a query that uses rank().

Reproducible: Always

Steps to Reproduce:

  1. Build and install monet from the source tarball
  2. In bash run mserver5 with no arguments
  3. Start an mclient session with the default database 'demo' and the monetdb user.
  4. Run the following commands in the same mclient session (I will attach the referenced files to this bug):
    drop table orders;
    < /path/to/orders.sql
    copy into "orders" from '/path/to/orders.tbl';
    select rank() over(partition by o_custkey) from orders;

Actual Results:

connection terminated

Expected Results:

+----------------+
| rank_o_custkey |
+================+
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
| 1 |
+----------------+

This problem does not reproduce if I kill and re-run mserver5 after the orders table is loaded.

gdb trace:
(gdb) where
0 0x00007ffff750b2b0 in lngCmp () from /deploy/lib/libbat.so.9
1 0x00007ffff75225c9 in GDKqsort_impl_any () from /deploy/lib/libbat.so.9
2 0x00007ffff75251f9 in GDKqsort () from /deploy/lib/libbat.so.9
3 0x00007ffff74a7c99 in do_sort () from /deploy/lib/libbat.so.9
4 0x00007ffff74a83e9 in BATsubsort () from /deploy/lib/libbat.so.9
5 0x00007ffff7bd6438 in ALGsubsort33 () from /deploy/lib/libmonetdb5.so.14
6 0x00007ffff7bd6608 in ALGsubsort13 () from /deploy/lib/libmonetdb5.so.14
7 0x00007ffff7b24c6b in runMALsequence () from /deploy/lib/libmonetdb5.so.14
8 0x00007ffff7b26a2e in DFLOWworker () from /deploy/lib/libmonetdb5.so.14
9 0x00000034ee007851 in start_thread (arg=0x7fffefb8c700) at pthread_create.c:301
10 0x00000034ed4e811d in clone () from /lib64/libc.so.6

Comment 18994

Date: 2013-08-12 23:52:39 +0200
From: Tim H. <<monetdb.bug.reporter>>

Created attachment 218
SQL file referenced in the repro steps

Attached file: orders.sql (application/octet-stream, 303 bytes)
Description: SQL file referenced in the repro steps

Comment 18995

Date: 2013-08-12 23:53:10 +0200
From: Tim H. <<monetdb.bug.reporter>>

Created attachment 219
Data file referenced in the repro steps

Attached file: orders.tbl (application/octet-stream, 3226 bytes)
Description: Data file referenced in the repro steps

Comment 19008

Date: 2013-08-16 15:48:03 +0200
From: MonetDB Mercurial Repository <>

Changeset bce79e07ae3a 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=bce79e07ae3a

Changeset description:

fixed bug #3341 instead of 3441

Comment 19009

Date: 2013-08-16 15:48:45 +0200
From: @njnes

fixed, ie don't sort allready sorted void columns

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant