1. 24 Jun, 2007 1 commit
  2. 23 Jun, 2007 3 commits
  3. 22 Jun, 2007 6 commits
    • gkodinov/kgeorge@magare.gmz's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 6a6f7234
      gkodinov/kgeorge@magare.gmz authored
      into  magare.gmz:/home/kgeorge/mysql/autopush/B28400-5.0-opt
      6a6f7234
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #27383: Crash in test "mysql_client_test" · f45601ce
      gkodinov/kgeorge@magare.gmz authored
      The C optimizer may decide that data access operations
      through pointer of different type are not related to 
      the original data (strict aliasing).
      This is what happens in fetch_long_with_conversion(),
      when called as part of mysql_stmt_fetch() : it tries 
      to check for truncation errors by first storing float
      (and other types of data) into a char * buffer and then 
      accesses them through a float pointer.
      This is done to prevent the effects of excess precision
      when using FPU registers.
      However the doublestore() macro converts a double pointer
      to an union pointer. This violates the strict aliasing rule.
      Fixed by making the intermediary variables volatile (
      to not re-introduce the excess precision bug) and using
      the intermediary value instead of the char * buffer.
      Note that there can be loss of precision for both signed
      and unsigned 64 bit integers converted to double and back,
      so the check must stay there (even for compatibility 
      reasons).
      Based on the excellent analysis in bug 28400.
      f45601ce
    • tsmith@maint1.mysql.com's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0-maint · 9f234274
      tsmith@maint1.mysql.com authored
      into  maint1.mysql.com:/data/localhome/tsmith/bk/maint/50
      9f234274
    • holyfoot/hf@hfmain.(none)'s avatar
      Merge bk@192.168.21.1:mysql-5.0-opt · 287f3485
      holyfoot/hf@hfmain.(none) authored
      into  mysql.com:/home/hf/work/28839/my50-28839
      287f3485
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      78c53ea3
    • dkatz@damien-katzs-computer.local's avatar
      Bug #29138 'kill' fails in pushbuild · a393b215
      dkatz@damien-katzs-computer.local authored
      The reason the "reap;" succeeds unexpectedly is because the query was completing(almost always) and the network buffer was big enough to store the query result (sometimes) on Windows, meaning the response was completely sent before the server thread could be killed.
      
      Therefore we use a much longer running query that doesn't have a chance to fully complete before the reap happens, testing the kill properly.
      a393b215
  4. 21 Jun, 2007 16 commits
  5. 20 Jun, 2007 14 commits