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