Emacs dired problem triggered by NPTL-enabled glibc

Emacs dired problem triggered by NPTL-enabled glibc

[David Mosberger]

On Debian/testing, I noticed that I can no longer load a directory via
dired.  The root-cause of the problem appears to be that Emacs uses
setrlimit() to set RLIMIT_STACK.  This limit won't be
page-size-aligned in general.  As a result, whenever Emacs ends up
spawning a subprocess for an executable that uses NPTL, the subprocess
fails with an error like this:

  init.c:259: __pthread_initialize_minimal_internal: Assertion `__default_stacksize % __sysconf (_SC_PAGESIZE) == 0' failed.

__default_stacksize is initialized like this:

 #ifdef NEED_SEPARATE_REGISTER_STACK
   __default_stacksize = MAX (limit.rlim_cur / 2, PTHREAD_STACK_MIN);
 #else
   __default_stacksize = MAX (limit.rlim_cur, PTHREAD_STACK_MIN);
 #endif

An easy workaround is to start Emacs with LD_ASSUME_KERNEL=2.4.18.

As far as I know, there is no requirement that the RLIMIT_STACK limit
must be an integer-multiple of the page size (and certainly it doesn't
have an integer-multiple of _twice_ the page-size), so it would seem
to me that this is a bug in glibc?

	--david

Re: Emacs dired problem triggered by NPTL-enabled glibc

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The code in init.c was wrong.  There is no need to devide by two in this
place.  In fact, the default stack size was wrong because of this.  I've
checked in a patch.

- -- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/4REf2ijCOnn/RHQRAo63AJ9MNnedR6KFuktHRChU77rmP1N8nwCeP3se
s/oj4XEcrojmzfu2soL0LJg=
=ZD1V
-----END PGP SIGNATURE-----

Re: Emacs dired problem triggered by NPTL-enabled glibc

[David Mosberger]

>>>>> On Wed, 17 Dec 2003 18:29:51 -0800, Ulrich Drepper <drepper@redhat.com> said:

  Uli> The code in init.c was wrong.  There is no need to devide by
  Uli> two in this place.  In fact, the default stack size was wrong
  Uli> because of this.  I've checked in a patch.

Thanks, but I must still be missing something.  setrlimit() is
perfectly happy to set a non-page-size-aligned limit, so I don't
understand how the code in init.c could succeed if Emacs were to set a
limit that's greater than PTHREAD_STACK_MIN, but not page-aligned.

	--david

Re: Emacs dired problem triggered by NPTL-enabled glibc

[Roland McGrath]

> Thanks, but I must still be missing something.  setrlimit() is
> perfectly happy to set a non-page-size-aligned limit, so I don't
> understand how the code in init.c could succeed if Emacs were to set a
> limit that's greater than PTHREAD_STACK_MIN, but not page-aligned.

You are correct.  I've added a test case that creates the same situation
(just by doing "ulimit -s 1023" before running a test binary).  It hits the
assert as well.  (Production builds won't see this since they define NDEBUG.)

I made the initializer round the value taken from getrlimit up to page size.


Thanks,
Roland

Re: Emacs dired problem triggered by NPTL-enabled glibc

[David Mosberger]

>>>>> On Tue, 23 Dec 2003 15:07:38 -0800, Roland McGrath <roland@redhat.com> said:

  >> Thanks, but I must still be missing something.  setrlimit() is
  >> perfectly happy to set a non-page-size-aligned limit, so I don't
  >> understand how the code in init.c could succeed if Emacs were to
  >> set a limit that's greater than PTHREAD_STACK_MIN, but not
  >> page-aligned.

  Roland> You are correct.  I've added a test case that creates the
  Roland> same situation (just by doing "ulimit -s 1023" before
  Roland> running a test binary).  It hits the assert as well.
  Roland> (Production builds won't see this since they define NDEBUG.)

  Roland> I made the initializer round the value taken from getrlimit
  Roland> up to page size.

Sounds great.

Thanks!

	--david