| Bug #8680 | Stored procedure with loop encounters memory limit | ||
|---|---|---|---|
| Submitted: | 22 Feb 2005 11:55 | Modified: | 27 May 2005 16:11 |
| Reporter: | Joerg Bruehe | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server | Severity: | S2 (Serious) |
| Version: | 5.0.3-pre | OS: | Other (Tru64) |
| Assigned to: | Per-Erik Martin | CPU Architecture: | Any |
[28 Feb 2005 17:48]
Per-Erik Martin
If this is still an issue, please point me to a machine and a source tree where I can test it.
[1 Mar 2005 14:47]
Joerg Bruehe
Still happened with build based on changeset 1.1774 05/03/01 01:59:37 petr@mysql.com +1 -0 Merge pchardin@bk-internal.mysql.com:/home/bk/mysql-5.0 into mysql.com:/home/cps/mysql/devel/im-fix-review Tree saved on 'barey' in directory '~/bug8680'.
[2 Mar 2005 11:30]
Per-Erik Martin
This appears to be a C compiler bug. Simply changing the optimization leverl from -O4 to -O3 makes the test pass. (All other flags the same.)
[21 Mar 2005 10:47]
Joerg Bruehe
I doubt the "compiler optimization level" analysis:
1) I reduced from "-O4" (original) to "-O3" and now to "-O2", and it still occurs.
2) It also occurs in "debug" builds, which on Tru64 cause a compiler message:
"cc: Info: File not optimized; use -g3 if both optimization and debug wanted. (suppressoptlvl)"
3) It does _not_ occur in a "classic" build (without InnoDB), here the test passes.
[8 Apr 2005 16:25]
Lenz Grimmer
Still happened for the last 5.0.4 build, which now uses "-O2" Could this be caused by static linking? Just guessing.
[11 Apr 2005 12:34]
Joerg Bruehe
For further research, optimization on this host reduced from "-O2" to "-O1".
[14 Apr 2005 15:52]
Per-Erik Martin
When attempting to reproduce this, I failed to debug it since it didn't happen as soon as I lowered the optimization level (and thus made it hard to check in a debugger). Another possible angle: It might actually be out of memory. Although the loop count doesn't seem to be large enough for this to happen, it might depend on wordsize, thread stack size etc. So it's possible that it's an instance of BUG#6048.
[24 May 2005 14:51]
Per-Erik Martin
The first test run on one of the affected machines now passes the test, after the patch for BUG#6048 was applied. So tentatively, this was probably an instance of the same bug.
[27 May 2005 16:11]
Per-Erik Martin
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.
If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information
about accessing the source trees is available at
http://www.mysql.com/doc/en/Installing_source_tree.html
Additional info:
It turns out there was only one machine where this happened, and there the test now passes.
Description: Until now, this is only noted on 'barney': type_newdecimal [ fail ] Errors are (from /local/users/mysqldev/barney/test/mysql-debug-5.0.3-alpha-dec-osf5.1b-alphaev67/mysql-test/var/log/mysqltest-time) : /local/users/mysqldev/barney/test/mysql-debug-5.0.3-alpha-dec-osf5.1b-alphaev67/bin/mysqltest: At line 514: query 'call p1()' failed: 5: Out of memory (Needed 424320 bytes) (the last lines may be the most important ones) Ending Tests Shutting-down MySQL daemon Master shutdown finished Slave shutdown finished type_ranges [ pass ] This is the test file (with line numbers): 507 # 508 create procedure p1 () begin 509 declare v1, v2, v3, v4 decimal(16,12); declare v5 int; 510 set v1 = 1; set v2 = 2; set v3 = 1000000000000; set v4 = 2000000000000; set v5 = 0; 511 while v5 < 100000 do 512 set v1 = v1 + 0.000000000001; set v2 = v2 - 0.000000000001; set v3 = v3 + 1; set v4 = v4 - 1; set v5 = v5 + 1; 513 end while; select v1, v2, v3 * 0.000000000001, v4 * 0.000000000001; end;// 514 # 515 call p1()// How to repeat: Build and test on Tru64.