Opened 10 years ago

Closed 9 years ago

#812 closed defect (fixed)

Segfault with long case queries

Reported by: Marcus Sen Owned by: Vlad Merticariu
Priority: major Milestone: 9.1
Component: qlparser Version: development
Keywords: Cc:
Complexity: Medium

Description

If I execute the query:

rasql -q 'select case c when 0 then { 0,  0,  0} when  1 then { 200,  200,  200} when 7 then { 255,  0,  0} when 9 then { 255,  255,  255} when 14 then { 149,  0,  148} when 16 then { 254,  168,  0} when 20 then { 23,  250,  255} when 26 then { 255,  255,  0} when 33 then { 255,  235,  0} when 34 then { 147,  112,  219} when 39 then { 176,  48,  96} when 47 then { 255,  127,  80} when 48 then { 231,  142,  79} when 49 then { 178,  178,  178} when 59 then { 255,  165,  0} when 62 then { 107,  142,  35} else  { 0,  0,  255} end from tno_geotop_lithostrat as c' --out file --outfile tno_rgb.mdd --type

I get the error:

rasql: rasdaman query tool v1.0, rasdaman v9.0.3 -- generated on 16.06.2014 09:34:11.
opening database RASBASE at localhost:7001...ok
Executing retrieval query...rasdaman error 0: Exception: Transfer Failed
aborting transaction...ok
rasql done.

In rasmgr.nnn.log:

rasdaman server process with pid 12755 has terminated.
Error: rasdaman server N1, pid 12755 terminated illegally, reason: exited with return code 255
[2014-07-07 12:34:18] starting server N1, executable /usr/bin/rasserver; pid 12822...

And in N1.012755.log:

Request: 'select case c when 0 then { 0,  0,  0} when  1 then { 200,  200,  200} when 7 then { 255,  0,  0} when 9 then { 255,  255,  255} when 14 then { 149,  0,  148} when 16 then { 254,  168,  0} when 20 then { 23,  250,  255} when 26 then { 255,  255,  0} when 33 then { 255,  235,  0} when 34 then { 147,  112,  219} when 39 then { 176,  48,  96} when 47 then { 255,  127,  80} when 48 then { 231,  142,  79} when 49 then { 178,  178,  178} when 59 then { 255,  165,  0} when 62 then { 107,  142,  35} else  { 0,  0,  255} end from tno_geotop_lithostrat as c'...parsing...checking semantics...evaluating...ok, result type 'set <marray <struct { long 0, long 1, long 2 }, [0:199,0:249,0:319]>>', 1 element(s).


Segmentation fault caught, stacktrace:
[bt]: (1) /lib64/libc.so.6() [0x37182329a0]
[bt]: (2) /usr/bin/rasserver() [0x4c586a]
[bt]: (3) /usr/bin/rasserver() [0x487f17]
[bt]: (4) /usr/bin/rasserver() [0x4ab02e]
[bt]: (5) /usr/bin/rasserver() [0x4c1bb8]
[bt]: (6) /usr/bin/rasserver() [0x47fc26]
[bt]: (7) /usr/bin/rasserver() [0x47fc89]
[bt]: (8) /usr/bin/rasserver() [0x4b5e3b]
[bt]: (9) /usr/bin/rasserver() [0x44dcd7]
[bt]: (10) /usr/bin/rasserver() [0x44043e]
[bt]: (11) /usr/bin/rasserver() [0x4591b0]
[bt]: (12) /usr/bin/rasserver() [0x459f38]
[bt]: (13) /usr/bin/rasserver() [0x45a2aa]
[bt]: (14) /usr/bin/rasserver() [0x45dcac]
[bt]: (15) /usr/bin/rasserver() [0x5599a8]
[bt]: (16) /usr/bin/rasserver() [0x55a422]
[bt]: (17) /usr/bin/rasserver() [0x4569ef]
[bt]: (18) /usr/bin/rasserver() [0x41d475]
[bt]: (19) /lib64/libc.so.6 (??:0) - __libc_start_main+0xfd [0x371821ed1d]
[bt]: (20) /usr/bin/rasserver() [0x41bf09]

rasserver terminated.

This is pure rasql but you can see a description of the coverage at http://earthserver.bgs.ac.uk/rasdaman/ows?service=WCS&Request=DescribeCoverage&version=2.0.1&CoverageId=tno_geotop_lithostrat&

If I execute what I think is the equivalent using the old-fashioned way of multiplying by boolean expressions rather than using the case statement:

rasql -q 'select (c = 0) * { 0c,  0c,  0c} +  (c = 1) * { 200c,  200c,  200c} +  (c = 7) * { 255c,  0c,  0c} +  (c = 9) * { 255c,  255c,  255c} +  (c = 14) * { 149c,  0c,  148c} +  (c = 16) * { 254c,  168c,  0c} +  (c = 20) * { 23c,  250c,  255c} +  (c = 26) * { 255c,  255c,  0c} +  (c = 33) * { 255c,  235c,  0c} +  (c = 34) * { 147c,  112c,  219c} +  (c = 39) * { 176c,  48c,  96c} +  (c = 47) * { 255c,  127c,  80c} +  (c = 48) * { 231c,  142c,  79c} +  (c = 49) * { 178c,  178c,  178c} +  (c = 59) * { 255c,  165c,  0c} +  (c = 62) * { 107c,  142c,  35c} + (c != 0 and c !=1 and c != 7 and c != 9 and c != 14 and c != 16 and c != 20 and c != 26 and c != 33 and c != 34 and c != 39 and c != 47 and c != 48 and c != 49 and c != 59 and c != 62) * { 0c,  0c,  255c} from tno_geotop_lithostrat as c' --out file --outfile tno_rgb.mdd --type

this seems to work.

Some further investigation with the complexity of statement that fails or not shows that one case and one else as below works:

rasql -q 'select case c when 0 then { 0c,  0c,  0c} else  { 0c,  0c,  255c} end from tno_geotop_lithostrat as c' --out file --outfile tno_rgb.mdd --type

but putting one extra when statement as below fails:

rasql -q 'select case c when 0 then { 0c,  0c,  0c} when  1 then { 200c,  200c,  200c} else  { 0c,  0c,  255c} end from tno_geotop_lithostrat as c' --out file --outfile tno_rgb.mdd --type

I am using v9.0.3 RPMs

Change History (10)

comment:1 by Dimitar Misev, 10 years ago

Owner: changed from Dimitar Misev to Vlad Merticariu
Status: newassigned

comment:2 by Vlad Merticariu, 10 years ago

Hi,

From the initial tests it seems there is a rewriting issue in the short hand case version. I will fix this soon.
A workaround is using the long version, i.e.:

select case when c = 0 then {0c, 0c, 0c} when c = 1 then ….

I'm mentioning this just in case you need to use the query before the patches are applied, if it's not urgent then don't change the query.

comment:3 by Marcus Sen, 10 years ago

Thanks, that is a useful workaround. When it is patched will there be any difference in performance or how the commands are executed or will it just be a case of syntactic convenience?

in reply to:  3 comment:4 by Vlad Merticariu, 10 years ago

The difference is purely syntactic. Before execution, the query is transformed in a long case query.

comment:5 by Dimitar Misev, 10 years ago

I couldn't reproduce any errors on my side, but great that you figured the problem!

comment:6 by Peter Baumann, 10 years ago

so can we close it?

comment:7 by Dimitar Misev, 10 years ago

Vlad, have you fixed this already?

comment:8 by Dimitar Misev, 10 years ago

Component: undecidedqlparser
Priority: criticalmajor

Ok I'm demoting this to major as there is a workaround for now.

comment:9 by Dimitar Misev, 9 years ago

Milestone: 9.1

comment:10 by Vlad Merticariu, 9 years ago

Resolution: fixed
Status: assignedclosed

Fixed in 9.1.

Note: See TracTickets for help on using tickets.