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

server crashes when executing particular loopback query in embedded python #4017

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


Copy link

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

Date: 2016-06-06 10:57:19 +0200
From: fioravanzos
To: Embedded devs <>
Version: unspecified
CC: @njnes

Last updated: 2017-10-26 14:01:28 +0200

Comment 22196

Date: 2016-06-06 10:57:19 +0200
From: fioravanzos

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36
Build Identifier:

If I execute a loopback query with a min() or max() statement in it, monet crashes.
mserver5 outputs 'segmentation fault'.
Example of function used:
res = _conn.execute("SELECT max(d) FROM mytable;")
result = dict()
result['n'] = str(res)
return result

Using the function without min() or max() in the query does not arise any issue.

Reproducible: Always

Steps to Reproduce:

1.Create function
2.Executed function
3.Server crashed

Actual Results:

Server crashes, segmentation fault

Expected Results:

Returned a table with the min or max result

Comment 24971

Date: 2017-02-03 17:15:12 +0100
From: @sjoerdmullender

Is this still a problem? I tried:

sql>create table mytable (d int);
operation successful (13.110ms)
sql>create function myfunc() returns table(n string) language python {
more> res = _conn.execute("SELECT max(d) FROM mytable;")
more> result = dict()
more> result['n'] = str(res)
more> return result
operation successful (1.2s)
sql>insert into mytable values (10);
1 affected row (5.312ms)
sql>insert into mytable values (20);
1 affected row (5.973ms)
sql>select * from myfunc();
| n |
| {'L3': array([20], dtype=int32)} |
1 tuple (9.596ms)

I.e., no crash. This was in the Dec2016 branch.

Comment 24982

Date: 2017-02-07 09:14:39 +0100
From: fioravanzos

Indeed the issue seems to have been resolved.
Thank you!

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

Successfully merging a pull request may close this issue.

None yet
1 participant