Your message dated Sat, 21 Nov 2009 13:43:30 +0000
with message-id <[email protected]>
and subject line Bug is fixed
has caused the Debian Bug report #343107,
regarding debians perl requires an extreme amount of stack
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
343107: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343107
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: perl
Version: 5.8.7-8
Severity: normal


This is the beginning of Perl_magic_get in the perl-5.8.7 I compiled
myself:

   Dump of assembler code for function Perl_magic_get:
   0x000000000047dee0 <Perl_magic_get+0>:  mov    %r12,0xfffffffffffffff0(%rsp)
   0x000000000047dee5 <Perl_magic_get+5>:  mov    %rbx,0xffffffffffffffe0(%rsp)
   0x000000000047deea <Perl_magic_get+10>: mov    %rdi,%r12
   0x000000000047deed <Perl_magic_get+13>: mov    %rbp,0xffffffffffffffe8(%rsp)
   0x000000000047def2 <Perl_magic_get+18>: mov    %r13,0xfffffffffffffff8(%rsp)
   0x000000000047def7 <Perl_magic_get+23>: sub    $0xa8,%rsp

The last lien allocates 168 byte sof local variable space on the stack.

This is the beginning of Perl_magic_get in debians (debug)perl on the same
system:

   0x00000000004aaf61 <Perl_magic_get+0>:  push   %rbp
   0x00000000004aaf62 <Perl_magic_get+1>:  mov    %rsp,%rbp
   0x00000000004aaf65 <Perl_magic_get+4>:  push   %r12
   0x00000000004aaf67 <Perl_magic_get+6>:  push   %rbx
   0x00000000004aaf68 <Perl_magic_get+7>:  sub    $0x40150,%rsp

This allocates 262480 bytes(!) (in words: a quarter megabyte) of local
variables on the stack.

The problem is that for thread stacks, you don't want to allocate
a megatbyte or so of stack for each thread (or even coroutine), not even
if it's only virtual memory (page tables cost a lot).

Obviously, perl can work with less than 256 bytes in Perl_magic_get, but
in the debian binary, it uses much much more.

This might be a problem with the compiler (I compiled with gcc-3.4) or the
fact that my own perl doesn't have the windows thread emulation enabled.

My perl configuration script ist attached.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.14
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages perl depends on:
hi  libc6                         2.3.5-8.1  GNU C Library: Shared libraries an
ii  libdb4.3                      4.3.29-1   Berkeley v4.3 Database Libraries [
ii  libgdbm3                      1.8.3-2    GNU dbm database routines (runtime
ii  perl-base                     5.8.7-8    The Pathologically Eclectic Rubbis
ii  perl-modules                  5.8.7-8    Core Perl modules

Versions of packages perl recommends:
ii  perl-doc                      5.8.7-8    Perl documentation

-- no debconf information

Attachment: Configure64.sh.txt
Description: application/shellscript


--- End Message ---
--- Begin Message ---
The fix for this bug was included in perl 5.8.8, so this bug can be closed.

>From 5.8.8's changelog:

____________________________________________________________________________
[ 26788] By: nicholas                              on 2006/01/11  17:19:22
        Log: Integrate:
        [ 26480] Subject: Re: [perl #37907] Perl_magic_get reqires ridiculous 
amounts of stackmemory
        From: Jim Cromie <[email protected]>
        Date: Fri, 23 Dec 2005 13:24:29 -0700
        Message-ID: <[email protected]>

-- 
    Chris Butler <[email protected]>
      GnuPG Key ID: 1024D/D097A261
*New* GnuPG Key ID: 4096R/C39E74E049E3ACD3


--- End Message ---

Reply via email to