Two other possible fixes would have been: realloc in mapi_query_part, or malloc to the same size (512) in mapi_query. I don't understand your suggestion. Do you mean overwriting the contents of hdl->query with the new part? On 2011-10-11 09:04, Fabian Groffen wrote:
On 10-10-2011 22:48:49 +0200, Sjoerd Mullender wrote:
Don't append partial queries inside mapi_query_part. When using the construct mclient -s 'COPY INTO t FROM STDIN ...' < file.csv mapi_query is called for the first part of the query (on the command line) which allocates just enough space to remember that query, and then mapi_query_part is called for each line of the input file, which assumed the allocated space was 512 bytes, resulting in out-of-bounds writes.
Wouldn't the fix have been to use (computed) ln instead of sz in the else case of the hdl->query check? I think this is the original problem.
With your change now, are back to the situation where only the first line of a query is remembered, which is often as useless as not showing any query at all.
Consider SELECT *<enter> FROM table<enter> WHERE blabla<enter> ;<enter>
if (hdl->query == NULL) { - size_t sz = size; - - sz = 512; - hdl->query = malloc(sz + 1); - assert(hdl->query); - hdl->query[0] = '\0'; - strncpy(hdl->query, query, sz); - hdl->query[sz] = '\0'; - } else { - size_t ln = strlen(hdl->query), sz = 512 - ln; - if (sz > 0) { - if (size < sz) - sz = size; - assert(hdl->query); - strncat(hdl->query, query, sz); - } + hdl->query = strdup(query); }
------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
-- Sjoerd Mullender