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