Bug #47128 Test "binlog_unsafe" exceds default stack allocation

Description:
Found during the 5.4.2-beta release build:

=====
binlog.binlog_unsafe 'stmt'              [ retry-fail ]
        Test ended at YYYY-MM-DD HH:MM:SS

CURRENT_TEST: binlog.binlog_unsafe
mysqltest: At line NNN: query 'EXECUTE prep6' failed: 1436: Thread stack overrun:  69456 bytes used of a 196608 byte stack, and 128000 bytes needed.  Use 'mysqld -O thread_stack=#' to specify a bigger stack.

The result from queries just before the failure was:
< snip >
BEGIN
CALL proc1();
RETURN 0;
END|
CREATE TRIGGER trig3
BEFORE INSERT ON trigger_table2
FOR EACH ROW
BEGIN
DECLARE tmp INT;
SELECT func2() INTO tmp;
END|
CREATE PROCEDURE proc4()
INSERT INTO trigger_table2 VALUES (1)|
CREATE FUNCTION func5()
RETURNS INT
BEGIN
CALL proc4;
RETURN 0;
END|
PREPARE prep6 FROM 'SELECT func5()'|

More results from queries before failure can be found in /PATH/mysql-test/var/log/binlog_unsafe.log

 - saving '/PATH/mysql-test/var/log/binlog.binlog_unsafe-stmt/' to '/PATH/mysql-test/var/log/binlog.binlog_uns
afe-stmt/'
=====

This happened (with slightly differing stack usage values) on
  Linux x86 ICC
and in the debug builds on
  Solaris 8 x86
  Solaris 10 Sparc 32bit
  Linux IA64 (RPMs for RH 3, 4, and 5, SuSE 9 and 10)

How to repeat:
Run the test suite on any of these.

Suggested fix:
Simplify the test, so that "stack used" is reduced

or

Raise the default stack size

or

Check whether we really need to assume 128,000 byte for a new Sp stack frame.

In the build of clster-6.3.27a, that very same problem also arises in test "sp":

=====
CURRENT_TEST: main.sp
mysqltest: At line NNN: query 'call bug10100t(5)' failed: 1436: Thread stack overrun:  68936 bytes used of a 196608 byte stack, and 128000 bytes needed.  Use 'mysqld -O thread_stack=#' to specify a bigger stack.

The result from queries just before the failure was:
< snip >
if level < lim then
select level;
fetch c into lv;
select lv;
update t3 set a=level+lv;
FLUSH TABLES;
call bug10100pc(level+1, lim);
else
select * from t3;
end if;
close c;
end|
set @@max_sp_recursion_depth=4|
select @@max_sp_recursion_depth|
@@max_sp_recursion_depth
4
select bug10100f(3)|
ERROR HY000: Recursive stored functions and triggers are not allowed.
select bug10100f(6)|
ERROR HY000: Recursive stored functions and triggers are not allowed.
=====

Here, it affects Solaris 9 and 10, Sparc, 32 bit, debug build.

Sme problem in the build of 5.5.0-beta.

In 5.5.0-beta, test "signal_demo3" has the same problem.

Same problem in the 5.1.43 release build.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/103375

3436 Bernd Ocklin	2010-03-09
      make failing solaris test cases experimental Bug#47128, Bug#46895

Situation in the release build of 5.6.1-m5:

The failure occurs in tests "signal_demo3" and "max_sp_recursion_depth_func" with RPMs for RHEL or SLES on IA64 (compiler icc) in debug mode.

(A similar error on Solaris in test "subquery_sj_none" is filed as bug#47791.)