Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 2.0.0
    • None
    • None
    • None
    • Ubuntu 12.04LTS and others

    Description

      In my application I'm getting a crash, valgrind shows this:

      ==4801== Memcheck, a memory error detector
      ==4801== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
      ==4801== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
      ==4801== Command: ./CONC-92
      ==4801== 
      ==4801== Invalid write of size 1
      ==4801==    at 0x4E4CABF: mthd_my_read_rows (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E4C59D: mthd_my_read_query_result (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E5F812: mysql_stmt_execute (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x401599: myexecute (CONC-92.c:283)
      ==4801==    by 0x401F5D: main (CONC-92.c:432)
      ==4801==  Address 0x63d7d38 is 0 bytes after a block of size 8,152 alloc'd
      ==4801==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==4801==    by 0x4E54481: my_malloc (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E52728: alloc_root (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E4C88F: mthd_my_read_rows (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E4C59D: mthd_my_read_query_result (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E5F812: mysql_stmt_execute (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x401599: myexecute (CONC-92.c:283)
      ==4801==    by 0x401F5D: main (CONC-92.c:432)
      ==4801== 
      ==4801== Invalid read of size 1
      ==4801==    at 0x4C2BFA2: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==4801==    by 0x4E52895: strdup_root (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E4B91F: unpack_fields (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E4C5C2: mthd_my_read_query_result (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E5F812: mysql_stmt_execute (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x401599: myexecute (CONC-92.c:283)
      ==4801==    by 0x401F5D: main (CONC-92.c:432)
      ==4801==  Address 0x63d7d38 is 0 bytes after a block of size 8,152 alloc'd
      ==4801==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==4801==    by 0x4E54481: my_malloc (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E52728: alloc_root (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E4C88F: mthd_my_read_rows (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E4C59D: mthd_my_read_query_result (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E5F812: mysql_stmt_execute (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x401599: myexecute (CONC-92.c:283)
      ==4801==    by 0x401F5D: main (CONC-92.c:432)
      ==4801== 
      ==4801== Invalid read of size 1
      ==4801==    at 0x4C2D0E1: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==4801==    by 0x4E528BD: strdup_root (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E4B91F: unpack_fields (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E4C5C2: mthd_my_read_query_result (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E5F812: mysql_stmt_execute (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x401599: myexecute (CONC-92.c:283)
      ==4801==    by 0x401F5D: main (CONC-92.c:432)
      ==4801==  Address 0x63d7d38 is 0 bytes after a block of size 8,152 alloc'd
      ==4801==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==4801==    by 0x4E54481: my_malloc (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E52728: alloc_root (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E4C88F: mthd_my_read_rows (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E4C59D: mthd_my_read_query_result (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x4E5F812: mysql_stmt_execute (in /usr/local/mariadbr134/lib/mariadb/libmariadb.so.2)
      ==4801==    by 0x401599: myexecute (CONC-92.c:283)
      ==4801==    by 0x401F5D: main (CONC-92.c:432)
      ==4801== 
      SUCCESS!
      ==4801== 
      ==4801== HEAP SUMMARY:
      ==4801==     in use at exit: 296 bytes in 2 blocks
      ==4801==   total heap usage: 239 allocs, 237 frees, 167,116 bytes allocated
      ==4801== 
      ==4801== LEAK SUMMARY:
      ==4801==    definitely lost: 0 bytes in 0 blocks
      ==4801==    indirectly lost: 0 bytes in 0 blocks
      ==4801==      possibly lost: 0 bytes in 0 blocks
      ==4801==    still reachable: 296 bytes in 2 blocks
      ==4801==         suppressed: 0 bytes in 0 blocks
      ==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.

      Attachments

        Activity

          Patch to fix bug reported.

          brad_mssw Brad House (Inactive) added a comment - Patch to fix bug reported.

          Any update on this?

          brad_mssw Brad House (Inactive) added a comment - Any update on this?
          georg 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!

          georg 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_mssw 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_mssw 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.

          updated patch to fix test suite regressions

          brad_mssw Brad House (Inactive) added a comment - updated patch to fix test suite regressions
          georg Georg Richter added a comment -

          Fixed in rev.141

          georg Georg Richter added a comment - Fixed in rev.141

          People

            georg Georg Richter
            brad_mssw Brad House (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.