==4801== Rerun with --leak-check=full to see details of leaked memory
==4801==
==4801== For counts of detected and suppressed errors, rerun with: -v
==4801== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 2 from 2)
This does not occur with the mysql client library. The resultset actually has 0 rows as a result, I've tried reproducing this with a minimal test case but it appears it is relevant to have a lot of data in the table in question so I haven't been able to reproduce it.
HOWEVER, I have found the issue and resolved it, it appears to be some pointer arithmatic issues. I'll attach the correction.
the patch doesn't work, the test suite returns a lot of errors.
Can you activate the servers general log (set global general_log=ON) and isolate the statement which generates the crash?
Thanks!
Georg Richter
added a comment - Brad,
the patch doesn't work, the test suite returns a lot of errors.
Can you activate the servers general log (set global general_log=ON) and isolate the statement which generates the crash?
Thanks!
Can you tell me how to run the test suite so I can test to see what errors are generated? Perhaps I missed a concept in there as the code is very hard to interpret and the pattern is very unusual to use a single malloc in this manner. The only thing I can think of is I thought I saw an issue in using '+fields+1' as an offset for the beginning of the actual data and changed it to just '+fields', but perhaps the original was valid and the only issue is the malloc didn't add the space for the null terminators after each field. Obviously as per the reported valgrind issue, there is an overflow. My patch definitely fixed the overflow according to valgrind.
I know the query which produces my issue, for some reason, depends on the data in the table, even though the query returns no results. I've only been able to reproduce on a table with millions of records, again though, the query returns no results legitimately. I don't know enough about the underlying mysql protocol to know why it depends on the number of records in the table when it returns no results, and a blank table that also returns no results doesn't have the issue.
The query is:
"SELECT m_type,auth_proc,cardtype,tranflags,txnstatus,ttid,msoft_code,phard_code,reasoncode,pclevel,cardlevel,abaroute,account,last4,expdate,checknum,ts,startdate,issuenum,accounttype,code,verbiage,amount,examount,tax,cashback,apcode,stan,batnum,itemnum,cardholdername,avsresp,cvresp,clerkid,stationid,comments,divisionnum,promoid,descmerch,ptrannum,ordernum,custref,bdate,edate,roomnum,excharge,rate,language,actcode,discountamount,freightamount,dutyamount,shipzip,shipcountry,l3num FROM transdata WHERE userid=? AND txnstatus IN (?, ?, ?, ?, ?, ?, ?, ?) ORDER BY ttid";
with bound values of 9, 2, 514, 1538, 1026, 4, 516, 1540, 1028.
Brad House (Inactive)
added a comment - Can you tell me how to run the test suite so I can test to see what errors are generated? Perhaps I missed a concept in there as the code is very hard to interpret and the pattern is very unusual to use a single malloc in this manner. The only thing I can think of is I thought I saw an issue in using '+fields+1' as an offset for the beginning of the actual data and changed it to just '+fields', but perhaps the original was valid and the only issue is the malloc didn't add the space for the null terminators after each field. Obviously as per the reported valgrind issue, there is an overflow. My patch definitely fixed the overflow according to valgrind.
I know the query which produces my issue, for some reason, depends on the data in the table, even though the query returns no results. I've only been able to reproduce on a table with millions of records, again though, the query returns no results legitimately. I don't know enough about the underlying mysql protocol to know why it depends on the number of records in the table when it returns no results, and a blank table that also returns no results doesn't have the issue.
The query is:
"SELECT m_type,auth_proc,cardtype,tranflags,txnstatus,ttid,msoft_code,phard_code,reasoncode,pclevel,cardlevel,abaroute,account,last4,expdate,checknum,ts,startdate,issuenum,accounttype,code,verbiage,amount,examount,tax,cashback,apcode,stan,batnum,itemnum,cardholdername,avsresp,cvresp,clerkid,stationid,comments,divisionnum,promoid,descmerch,ptrannum,ordernum,custref,bdate,edate,roomnum,excharge,rate,language,actcode,discountamount,freightamount,dutyamount,shipzip,shipcountry,l3num FROM transdata WHERE userid=? AND txnstatus IN (?, ?, ?, ?, ?, ?, ?, ?) ORDER BY ttid";
with bound values of 9, 2, 514, 1538, 1026, 4, 516, 1540, 1028.
FYI, the basic-t tests segfault on me with or without my patchset. The 'ps' tests did not and there was one regression listed. Normally there are 2 failures, but with my patch, there are 3. I've adjusted the patch and now for the 'ps' tests, it returns the same results and it also resolves my valgrind issue still.
I'll attach it in a sec.
Brad House (Inactive)
added a comment - FYI, the basic-t tests segfault on me with or without my patchset. The 'ps' tests did not and there was one regression listed. Normally there are 2 failures, but with my patch, there are 3. I've adjusted the patch and now for the 'ps' tests, it returns the same results and it also resolves my valgrind issue still.
I'll attach it in a sec.
Patch to fix bug reported.