Opened 11 years ago
Closed 11 years ago
#493 closed defect (fixed)
Complex constructor doesn't accept integers
Reported by: | Veranika Liaukevich | Owned by: | Veranika Liaukevich |
---|---|---|---|
Priority: | minor | Milestone: | 9.0 |
Component: | qlparser | Version: | 8.5 |
Keywords: | Cc: | ||
Complexity: | Medium |
Description
Complex accepts only floats as constructor arguments
$ rasql -q 'select complex(1,0) from test' --out string rasql: rasdaman query tool v1.0, rasdaman v8.5.0-gc2aeb38 -- generated on 23.10.2013 12:42:31. opening database RASBASE at localhost:7001...ok Executing retrieval query...rasdaman error 300: Parsing error 300 in line 1, column 16: Unexpected name 1. aborting transaction...ok
Change History (6)
comment:1 by , 11 years ago
comment:3 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:4 by , 11 years ago
Component: | undecided → qlparser |
---|---|
Milestone: | → 9.0 |
Resolution: | fixed |
Status: | closed → reopened |
The systemtest case source:systemtest/testcases_mandatory/test_select/queries/composite_constants_complex_integer.rasql randomly causes segfault for me with this stacktrace:
#0 0x00007ff5937d58b4 in std::string::assign(std::string const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #1 0x00000000004ccfd9 in ParseInfo::ParseInfo (this=0x231c9c0, old=...) at parseinfo.cc:59 #2 0x000000000049a729 in QtData::setParseInfo (this=0x23195b0, info=...) at ../qlparser/qtdata.icc:83 #3 0x0000000000494232 in yyparse (mflag=0x0) at oql.yy:2501 #4 0x000000000046694b in ServerComm::executeQuery (this=0x1ee66b0, callingClientId=198, query=0x2318054 "select complex( 42, 73 ) from test_grey", returnStructure=...) at servercomm2.cc:1540 #5 0x000000000045aeaa in RasServerEntry::compat_executeQueryRpc (this=0x1ee66b0, query=0x2318054 "select complex( 42, 73 ) from test_grey", queryResult=...) at rasserver_entry.cc:276 #6 0x000000000047832c in RnpRasDaManComm::executeQueryRpc (this=0x89b520 <rnpServerComm>) at ../rnprotocol/rnpservercomm.cc:591 #7 0x0000000000477a1d in RnpRasDaManComm::decodeFragment (this=0x89b520 <rnpServerComm>) at ../rnprotocol/rnpservercomm.cc:282 #8 0x0000000000477435 in RnpRasDaManComm::processRequest (this=0x89b520 <rnpServerComm>, receiverBuffer=0x1ee6250, transmiterBuffer=0x1ee6278, protocol=rnp::RnpTransport::crp_Rnp, callingJob=0x1ee61f0) at ../rnprotocol/rnpservercomm.cc:132 #9 0x000000000047ee17 in rnp::RnpServerJob::processRequest (this=0x1ee61f0) at ../rnprotocol/rnpcommunication.cc:413 #10 0x00000000005c99a7 in akg::NbCommunicator::processJobs (this=0x89b600 <communicator>) at akgnet_nbcomm.cc:483 #11 0x00000000005c98c4 in akg::NbCommunicator::mainLoop (this=0x89b600 <communicator>) at akgnet_nbcomm.cc:452 #12 0x00000000005c97ee in akg::NbCommunicator::runServer (this=0x89b600 <communicator>) at akgnet_nbcomm.cc:421 #13 0x00000000004765c3 in startRnpServer () at ../rnprotocol/rnpserver.cc:97 #14 0x000000000041d851 in main (argc=14, argv=0x7fffecfe98e8) at rasserver_main.cc:168
comment:5 by , 11 years ago
Oh. The problem is that I free the node whose information is still used (in oql.yy)
2528| $$.info = $1.info; 2529| FREESTACK($1);
I'll fix it immediately.
comment:6 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Note:
See TracTickets
for help on using tickets.
Veranika I see you submitted the patch. Can you include a test for the bug in the systemtest as well?
In source:systemtest/testcases_mandatory/test_select you'd just add a query in
queries
, and expected output for that query inoracle
.