Bug #2599 mysql fails to start on ia64 because of too-small a thread-stack
Submitted: 1 Feb 2004 8:32 Modified: 2 Aug 2004 17:52
Reporter: Christian Hammers (Silver Quality Contributor) (OCA) Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S2 (Serious)
Version:4.0.17 OS:Linux (Debian GNU/Linux ia64)
Assigned to: Sergei Golubchik CPU Architecture:Any

[1 Feb 2004 8:32] Christian Hammers
Description:
This was reported through the Debian bug tracking system and is available at
http://bugs.debian.org/228834. The original submitter was David Mosberger-Tang <David.Mosberger@acm.org>
-----------------
Note: I reported the info below already as a follow-up for bug #158643
but upon re-reading the original report, I realized that this should
have been a reported separately, so I'm resubmitting it here.

The mysqld server fails to work on ia64 Linux apparently due to the
recent switch to a TLS-enabled glibc.  The problem is that the
interrupt thread fails to get created (it fails with EINVAL).  The
workaround that the patch below uses is to not try to limit the
stack-size to 32KB.  The code seems to be buggy to begin with (it
should at least use a stack-size of MAX(32768, PTHREAD_STACK_MIN); on
ia64, PTHREAD_STACK_MIN is 196608 bytes), but I think the reason this
bug got triggered now is due to the fact that NPTL insists that the
stack size no less than:

  guardsize + static-TLS-size + MINIMAL_REST_STACK + pagesize

where

  guardsize             >= 1 page (16KB with the Debian kernel)
  MINIMAL_REST_STACK:   16KB on ia64
  page_size:            16KB with the Debian kernel

In other words, the stack would have bo be at least 48KB for the
thread-creation to succeed.  Of course, with a page size of 64KB, this
minimum would increase to 144KB.

The static-TLS-size is somewhat unpredictable, since that's something
that will change whenever one of the dependent shared libraries
chooses to use more or less thread-local storage.  At the moment, only
glibc seems to use TLS and it's only about 16 bytes, but that can
obviously change easily.

In summary, I'd recommend that mysqld should at the very least
increase the stack-size to MAX(32768, PTHREAD_STACK_MIN).  However,
since virtual memory is cheap on 64-bit architectures, it might be
best not to try to set the stack size at all on those architectures.

        --david

How to repeat:
see above

-- System Information
Debian Release: 3.0
Architecture: ia64
Kernel: Linux panda.mostang.com 2.6.0-test9 #14 Sat Nov 1 01:14:22 PST 2003 ia64
Locale: LANG=C, LC_CTYPE=

Versions of packages mysql-server depends on:
ii  adduser                3.47              Add and remove users and groups
ii  debconf                1.2.34            Debian configuration management sy
ii  libc6.1                2.3.2.ds1-10.0.1  GNU C Library: Shared libraries an
ii  libdbi-perl            1.35-1            The Perl5 Database Interface by Ti
ii  libgcc1                1:3.3.2-4         GCC support library
ii  libmysqlclient12       4.0.16-2          mysql database client library
ii  libssl0.9.7            0.9.7c-5          SSL shared libraries
ii  libstdc++5             1:3.3.2-4         The GNU Standard C++ Library v3
ii  libwrap0               7.6-9             Wietse Venema's TCP wrappers libra
ii  mysql-client           4.0.16-2          mysql database client binaries
ii  passwd                 20000902-12       Change and administer password and
ii  perl                   5.8.0-18          Larry Wall's Practical Extraction
ii  psmisc                 20.2-2.1          Utilities that use the proc filesy
ii  zlib1g                 1:1.1.4-1.0woody0 compression library - runtime

Suggested fix:
--- sql/mysqld.cc~      2003-12-07 10:09:21.000000000 -0800
+++ sql/mysqld.cc       2003-12-07 10:32:29.291545673 -0800
@@ -1700,7 +1700,7 @@
 #endif

   (void) pthread_mutex_lock(&LOCK_thread_count);
-  if ((error=pthread_create(&signal_thread,&thr_attr,signal_hand,0)))
+  if ((error=pthread_create(&signal_thread,NULL/*&thr_attr*/,signal_hand,0)))
   {
     sql_print_error("Can't create interrupt-thread (error %d, errno: %d)",
                    error,errno);
[2 Feb 2004 5:05] MySQL Verification Team
Thank you for writting to us.

This is not MySQL bug.

Both our sources and our binaries have a default stack of 256 K.

This was tested and confirmed on all IA-64 platforms.
[2 Feb 2004 10:16] Sergei Golubchik
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:

ok, thanks for reporting this.

fixed.
[1 Aug 2004 20:51] Christian Hammers
Sinisa said it's not a bug and Sergei said that it has been fixed in the latest source?!
But at least the proposed fix has not been applied although the bug report is closed.
So what happened here? :-)

thanks,

-christian-
[1 Aug 2004 21:51] Christian Hammers
Oh, ok, I found the patch from Sergey, it's some lines down:
http://mysql.bkbits.net:8080/mysql-4.0/diffs/sql/mysqld.cc@1.478
[2 Aug 2004 17:52] MySQL Verification Team
It depended on the build.

That is why it worked for me.

Anyway, stack is increased for other reasons, including the way ECC compiler resolves some branches.