| Bug #10016 | Uninit memory touched if SPs and cursors are used | ||
|---|---|---|---|
| Submitted: | 19 Apr 2005 21:37 | Modified: | 9 Sep 2005 13:24 | 
| Reporter: | Jan Kneschke | Email Updates: | |
| Status: | Can't repeat | Impact on me: | |
| Category: | MySQL Server | Severity: | S3 (Non-critical) | 
| Version: | 5.0.4 | OS: | Linux (Linux/x86) | 
| Assigned to: | CPU Architecture: | Any | |
   [19 Apr 2005 21:37]
   Jan Kneschke        
  
 
   [20 Apr 2005 19:14]
   MySQL Verification Team        
  I got different Valgrind report running 5.0.5 BK source on Slackware 10.1 and testing on Windows Purify not shows that issue: ==2647== ==2647== Syscall param write(buf) points to uninitialised byte(s) ==2647== at 0x1BA86132: pthread_key_delete (in /lib/libpthread-0.10.so) ==2647== by 0x85D3967: my_thread_global_end (my_thr_init.c:108) ==2647== by 0x85AE94B: my_end (my_init.c:188) ==2647== by 0x81E3A2E: main (mysqld.cc:3218) ==2647== Address 0x52BFE38C is on thread 1's stack ==2647== discard syms at 0x1BD5D000-0x1BD67000 in /lib/libnss_files-2.3.4.so due to munmap() ==2647== ==2647== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 49 from 7) ==2647== ==2647== 1 errors in context 1 of 2: ==2647== Syscall param write(buf) points to uninitialised byte(s) ==2647== at 0x1BA86132: pthread_key_delete (in /lib/libpthread-0.10.so) ==2647== by 0x85D3967: my_thread_global_end (my_thr_init.c:108) ==2647== by 0x85AE94B: my_end (my_init.c:188) ==2647== by 0x81E3A2E: main (mysqld.cc:3218) ==2647== Address 0x52BFE38C is on thread 1's stack ==2647== ==2647== 1 errors in context 2 of 2: ==2647== Conditional jump or move depends on uninitialised value(s) ==2647== at 0x85DE21B: strstr (in /home/miguel/dbs/5.0/libexec/mysqld) ==2647== by 0x1BA8A674: (within /lib/libpthread-0.10.so) ==2647== by 0x1BA80A9D: (within /lib/libpthread-0.10.so) ==2647== by 0x1B8EEAAD: call_init (in /lib/ld-2.3.4.so) ==2647== by 0x1B8EE9AA: _dl_init (in /lib/ld-2.3.4.so) ==2647== by 0x1B8E47D4: (within /lib/ld-2.3.4.so) --2647-- --2647-- supp: 1 LinuxThreads: write/__pthread_initialize_manager/pthread_create --2647-- supp: 13 LinuxThreads: write/pthread_create --2647-- supp: 1 LinuxThreads: write/pthread_onexit_process --2647-- supp: 1 LinuxThread clone use (tlsinfo) --2647-- supp: 1 LinuxThread clone use (child_tidptr) --2647-- supp: 1 LinuxThread clone use (parent_tidptr) --2647-- supp: 31 dl_relocate_object ==2647== ==2647== IN SUMMARY: 2 errors from 2 contexts (suppressed: 49 from 7) ==2647== ==2647== malloc/free: in use at exit: 19956636 bytes in 40110 blocks. ==2647== malloc/free: 40825 allocs, 715 frees, 48202114 bytes allocated. ==2647== ==2647== searching for pointers to 40110 not-freed blocks. ==2647== checked 38609852 bytes. ==2647== ==2647== LEAK SUMMARY: ==2647== definitely lost: 8160 bytes in 1 blocks. ==2647== possibly lost: 0 bytes in 0 blocks. ==2647== still reachable: 19948476 bytes in 40109 blocks. ==2647== suppressed: 0 bytes in 0 blocks. ==2647== Use --leak-check=full to see details of leaked memory. --2647-- TT/TC: 0 tc sectors discarded. --2647-- 33714 tt_fast misses. --2647-- translate: new 29790 (586225 -> 7189852; ratio 122:10) --2647-- discard 143 (1789 -> 25984; ratio 145:10). --2647-- chainings: 20185 chainings, 0 unchainings. --2647-- dispatch: 68820056 jumps (bb entries); of them 9858438 (14%) unchained. --2647-- 1386/78530 major/minor sched events. --2647-- reg-alloc: 5731 t-req-spill, 1216345+39621 orig+spill uis, --2647-- 148991 total-reg-rank --2647-- sanity: 1387 cheap, 56 expensive checks. --2647-- ccalls: 145872 C calls, 54% saves+restores avoided (470562 bytes) --2647-- 202508 args, avg 0.87 setup instrs each (51970 bytes) --2647-- 0% clear the stack (437616 bytes) --2647-- 59371 retvals, 23% of reg-reg movs avoided (27002 bytes) miguel@light:~/dbs/5.0$
   [26 May 2005 10:05]
   Michael Widenius        
  Jan, can you verify that you compiled MySQL with -DHAVE_purify defined. Becasue if you didn't do this, the warning in my_pwrite() is ok (as we don't initialize the MyISAM page buffers when not using valgrind as this isn't needed during not valgrind runs) (Miguel's test case doesn't show any errors in read/write that may be releated) I agree that in theory this could be a bug in stack space detection and we have a memory overrun, but we need more data to know what is going one.
   [26 May 2005 21:02]
   Jan Kneschke        
  It is the binary debug tar.gz from the download page. The build-team says that HAVE_purify is not enabled in that package.
   [26 Jun 2005 23:00]
   Bugs System        
  No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
   [9 Sep 2005 13:24]
   Valeriy Kravchuk        
  Can't repeat it on today's 5.0.13-BK on Linux:
mysql> CREATE TABLE test10 (
    ->   id INT UNSIGNED NOT NULL auto_increment PRIMARY KEY,
    ->   name VARCHAR(128),
    ->    parent_id INT UNSIGNED
    -> ) engine=MyISAM;
Query OK, 0 rows affected (0,03 sec)
mysql> INSERT INTO test10 VALUES
    ->   ( 1, 'Earth', NULL ),
    ->   ( 2, 'Moon', NULL );
Query OK, 2 rows affected (0,00 sec)
Records: 2  Duplicates: 0  Warnings: 0
mysql> DROP FUNCTION IF EXISTS sp_tree_depth;
DELIMITER $$
CQuery OK, 0 rows affected, 1 warning (0,03 sec)
mysql> DELIMITER $$
mysql> CREATE FUNCTION sp_tree_depth(nid INT UNSIGNED)
    ->   RETURNS INT UNSIGNED
    -> BEGIN
    ->   DECLARE depth INT UNSIGNED DEFAULT 0;
    ->   DECLARE n INT UNSIGNED DEFAULT 0;
    ->   DECLARE maxdepth INT UNSIGNED DEFAULT 0;
    ->   DECLARE done INT UNSIGNED DEFAULT 0;
    ->    DECLARE cur CURSOR FOR SELECT id FROM test10 WHERE parent_id = nid;
    ->   DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
    ->
    ->   OPEN cur;
    -> l: LOOP
    ->     FETCH cur INTO n;
    ->
    ->     IF done = 1 THEN
    ->        LEAVE l;
    ->     END IF;
    ->     SELECT sp_tree_depth(n)+1 FROM test10 INTO depth;
    ->     IF depth > maxdepth THEN
    ->       SET maxdepth = depth;
    ->     END IF;
    ->   END LOOP;
    ->    CLOSE cur;
    ->
    ->   RETURN maxdepth;
    -> END$$
DELIMITER ;Query OK, 0 rows affected (0,04 sec)
mysql> DELIMITER ;
mysql> select version();
+-------------------+
| version()         |
+-------------------+
| 5.0.13-beta-debug |
+-------------------+
1 row in set (0,00 sec)
mysql> SELECT sp_tree_depth(1) FROM test10;
+------------------+
| sp_tree_depth(1) |
+------------------+
|                0 |
|                0 |
+------------------+
2 rows in set (0,00 sec)
Please, try newer verison of MySQL.
 
