Bug #47791 Several test cases fail on Solaris with error Thread stack overrun
Submitted: 2 Oct 2009 12:23 Modified: 17 Aug 2011 14:31
Reporter: Olav Sandstå Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: General Severity:S3 (Non-critical)
Version:5.1-bugteam, Betony (M2), Celosia (M3),5.6.99,mysql-trunk OS:Any (Solaris 10, rhel5 ia64)
Assigned to: Marc ALFF CPU Architecture:Any
Tags: experimental, pb2, pushbuild, test failure

[2 Oct 2009 12:23] Olav Sandstå
Description:
The test main.signal_demo3 fails when running it on Solaris. The output contains:

main.signal_demo3                        [ fail ]
        Test ended at 2009-10-02 14:18:53

CURRENT_TEST: main.signal_demo3
mysqltest: At line 122: query 'call proc_1()' failed with wrong errno 1436: 'Thread stack overrun:  135952 bytes used of a 262144 byte stack, and 128000 bytes needed.  Use 'mysqld -O thread_stack=#' to specify a bigger stack.', instead of 1782...

How to repeat:
On Solaris 10 do the following:

1. Use a 6.0 source three (I used mysql-6.0-codebase-bugfixing)
2. ./BUILD/autorun.sh
3. Configure with:

    ./configure CC=/opt/studio12/SUNWspro/bin/cc CXX=/opt/studio12/SUNWspro/bin/CC CFLAGS="-Xa -m64 -mt -g" CXXFLAGS="-m64 -mt -g" --prefix=/home/os136802/install/mysql6 --with-client-ldflags=-static --with-plugins=myisam,innobase --enable-dtrace --with-debug

4. make
5. cd mysql-test
6. ./mysql-test-run.pl signal_demo3
[2 Oct 2009 13:50] Valeriy Kravchuk
Does not fail on Linux.
[3 Oct 2009 7:00] Sveta Smirnova
Thank you for the report.

Verified as described.
[4 Dec 2009 9:51] Georgi Kodinov
This test was probably passing for quite some time. We need to find out what change causes it fail fist.
[4 Dec 2009 10:40] Manyi Lu
Bug verification team: Have you verified whether this bug exists in releases prior to 6.0?

Thanks,
Manyi
[20 Jan 2010 15:19] Alexander Nozdrin
Making the test case experimental on Solaris
staring from Celosia (next-mr).
[20 Jan 2010 15:21] Alexander Nozdrin
List of test cases:
  - main.signal_demo3
  - main.sp
  - rpl.rpl_row_sp011
  - sys_vars.max_sp_recursion_depth_func
[28 Jan 2010 18:43] Alexander Nozdrin
It's now also failing in Betony/Celosia.
[31 Jan 2010 11:33] Alexander Nozdrin
Adding rpl.rpl_row_sp011 to this list.
[16 Feb 2010 9:53] Alexander Nozdrin
Adding main.subselect_sj2 & main.subselect_sj2_jcl6 to this list.
[12 Mar 2010 10:56] Staale Smedseng
Inspection of the main.sp case (in 5.1-bugteam) indicates that stack
frame size for mysql_execute_command() is more than twice the size in
non-optimized build compared to optimized build on sparc32 with
sunstudio12u1. (9.4k compared to 4.3k.)

In main.sp, stored procedure recursion puts multiple invocations of
mysql_execute_command() on the stack, and with enough levels one will
hit the ceiling imposed by check_stack_overrun(), in this case called
by sp_head::execute().

The reason for these differences is likely that the compiler in
non-optimized mode makes no effort to optimize/reuse variable space in
the stack frame for sub-scopes (there are a few large objects
allocated on the stack in sub-scopes in mysql_execute_command()).

Quick reproduction (snipped from main.sp):

   delimiter |
   create procedure bug10100p(prm int, inout res int)
   begin
     set res = res * prm;
     if prm > 1 then
       call bug10100p(prm - 1, res);  
     end if;
   end|
   create procedure bug10100t(prm int)
   begin
     declare res int;
     set res = 1;
     call bug10100p(prm, res);
     select res;
   end|
   delimiter ;

   set session max_sp_recursion_depth=4;
   call bug10100t(5);

and inspect the behavior of the stack pointer in a deugger.
[13 Nov 2010 16:06] Bugs System
Pushed into mysql-trunk 5.6.99-m5 (revid:alexander.nozdrin@oracle.com-20101113155825-czmva9kg4n31anmu) (version source revid:vasil.dimov@oracle.com-20100629074804-359l9m9gniauxr94) (merge vers: 5.6.99-m4) (pib:21)
[13 Nov 2010 16:38] Bugs System
Pushed into mysql-next-mr (revid:alexander.nozdrin@oracle.com-20101113160336-atmtmfb3mzm4pz4i) (version source revid:vasil.dimov@oracle.com-20100629074804-359l9m9gniauxr94) (pib:21)
[4 Jan 2011 10:02] Joerg Bruehe
In the release build of 5.6.1-m5, this symptom shows up in test "subquery_sj_none" (specific to Solaris 10 Sparc in debug mode).
[4 Jan 2011 10:10] Joerg Bruehe
Correction:
... (specific to Solaris 10 in debug mode).

It happens on both Sparc-64 and x86_64, the test passes on x86 (32 bit).
[18 Jan 2011 3:59] Anitha Gopi
Fails every day in the nightly release run of the trunk http://pb2.norway.sun.com/?template=mysql_show_test_failure&test_failure_id=&test_output_i...
[21 Jan 2011 7:04] Anitha Gopi
Also seen in sys_vars.sp_recusrion_depth

http://pb2.norway.sun.com/?action=archive_download&archive_id=2866255&pretty=please

sys_vars.max_sp_recursion_depth_func     w13 [ exp-fail ]
        Test ended at 2011-01-21 00:55:00

CURRENT_TEST: sys_vars.max_sp_recursion_depth_func
mysqltest: At line 64: query 'CALL sp_addRecords(0,8)' failed: 1436: Thread stack overrun:  138960 bytes used of a 262144 byte stack, and 128000 bytes needed.  Use 'mysqld --thread_stack=#' to specify a bigger stack.
[28 Jan 2011 5:35] Bugs System
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/129827

3563 Anitha Gopi	2011-01-28
      Bug#47791 : Moved main.subquery_sj_none to experimental group
[31 Jan 2011 4:24] Bugs System
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/129990

3576 Anitha Gopi	2011-01-31 [merge]
      Bug#47791 : Moved main.subquery_sj_none to experimental group
[31 Jan 2011 4:25] Bugs System
Pushed into mysql-trunk 5.6.2 (revid:anitha.gopi@sun.com-20110131042308-0l2ggxhv1pgqpmet) (version source revid:anitha.gopi@sun.com-20110131042308-0l2ggxhv1pgqpmet) (merge vers: 5.6.2) (pib:24)
[8 Feb 2011 11:02] Anitha Gopi
Moving back to verified state. Patch pushed was for just moving a test to experimental state
[17 Aug 2011 14:31] Jon Stephens
Duplicate of BUG#45445.