From helm@es.net

Created by helm@dir2.es.net

The site configuration below is wrong for this bug report.
This bug report is for a threaded configuration (the other
details below are consistent between the threaded & non-th.
configurations).
This configuration segfaults on some solaris 2.5.1, but not on others,
no obvious pattern. Here's what & where​:

Reading symbolic information for perl
core file header read successfully
Reading symbolic information for rtld /usr/lib/ld.so.1
dbx​: program is not active
Reading symbolic information for libsocket.so.1
Reading symbolic information for libnsl.so.1
Reading symbolic information for libdl.so.1
Reading symbolic information for libposix4.so.1
Reading symbolic information for libpthread.so.1
Reading symbolic information for libc.so.1
Reading symbolic information for libintl.so.1
Reading symbolic information for libmp.so.1
Reading symbolic information for libw.so.1
Reading symbolic information for libc_psr.so.1
Reading symbolic information for libthread.so.1
detected a multithreaded program
t@​1 (l@​1) terminated by signal SEGV (Segmentation Fault)
dbx​: core file read error​: address 0xef7fff40 not in data space
dbx​: core file read error​: address 0xef7fff7c not in data space
dbx​: core file read error​: address 0xef7ca140 not in text space
dbx​: attempt to fetch registers failed - stack corrupted

(dbx) where
current thread​: t@​1
dbx​: core file read error​: address 0xef7fff7c not in data space
dbx​: core file read error​: address 0xef7ca140 not in text space
dbx​: attempt to fetch registers failed - stack corrupted
(dbx)

Ok, let's try running it​:

(dbx) run
Running​: perl
(process id 5973)
Reading symbolic information for libthread.so.1
t@​1 (l@​1) signal SEGV (no mapping at the fault address) in call_init at 0xef7ca154
0xef7ca154​: call_init+0x0014​: st %i0, [%fp + 0x44]
(dbx) where
current thread​: t@​1
=>[1] call_init(0xef721324, 0x400181, 0xffffffff, 0xef7ed7b8, 0xef7ed7a0, 0x0), at 0xef7ca154
dbx​: fetch at 0xef7fffd8 failed -- I/O error
dbx​: attempt to read stack failed - bad frame pointer

Site configuration information for perl 5.00503:

Configured by helm at Sat Feb  5 13:32:04 PST 2000.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
    osname=solaris, osvers=2.5.1, archname=sun4-solaris
    uname='sunos dir2 5.5.1 generic_103640-31 sun4u '
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
    cc='cc', optimize='-g -O', gccversion=
    cppflags='-DDEBUGGING -I/usr/local/include'
    ccflags ='-DDEBUGGING -I/usr/local/include'
    stdchar='unsigned char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
    libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt
    libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-KPIC', lddlflags='-G -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.00503:
    /usr/local/lib/perl5/5.00503/sun4-solaris
    /usr/local/lib/perl5/5.00503
    /usr/local/lib/perl5/site_perl/5.005/sun4-solaris
    /usr/local/lib/perl5/site_perl/5.005
    .


Environment for perl 5.00503:
    HOME=/export/home/helm
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/local/bin:/bin:/usr/bin:/usr/ucb:/etc:.
    PERL_BADLANG (unset)
    SHELL=/bin/csh

From @floatingatoll

Merged 2107 -- a reply that should have gone into 2106 -- into 2106.

From @smpeters

[helm@​es.net - Sat Feb 05 07​:58​:13 2000]​:

This is a bug report for perl from helm@​dir2.es.net,
generated with the help of perlbug 1.26 running under perl 5.00503.

-----------------------------------------------------------------
[Please enter your report here]

The site configuration below is wrong for this bug report.
This bug report is for a threaded configuration (the other
details below are consistent between the threaded & non-th.
configurations).
This configuration segfaults on some solaris 2.5.1, but not on others,
no obvious pattern. Here's what & where​:

Reading symbolic information for perl
core file header read successfully
Reading symbolic information for rtld /usr/lib/ld.so.1
dbx​: program is not active
Reading symbolic information for libsocket.so.1
Reading symbolic information for libnsl.so.1
Reading symbolic information for libdl.so.1
Reading symbolic information for libposix4.so.1
Reading symbolic information for libpthread.so.1
Reading symbolic information for libc.so.1
Reading symbolic information for libintl.so.1
Reading symbolic information for libmp.so.1
Reading symbolic information for libw.so.1
Reading symbolic information for libc_psr.so.1
Reading symbolic information for libthread.so.1
detected a multithreaded program
t@​1 (l@​1) terminated by signal SEGV (Segmentation Fault)
dbx​: core file read error​: address 0xef7fff40 not in data space
dbx​: core file read error​: address 0xef7fff7c not in data space
dbx​: core file read error​: address 0xef7ca140 not in text space
dbx​: attempt to fetch registers failed - stack corrupted

(dbx) where
current thread​: t@​1
dbx​: core file read error​: address 0xef7fff7c not in data space
dbx​: core file read error​: address 0xef7ca140 not in text space
dbx​: attempt to fetch registers failed - stack corrupted
(dbx)

Ok, let's try running it​:

(dbx) run
Running​: perl
(process id 5973)
Reading symbolic information for libthread.so.1
t@​1 (l@​1) signal SEGV (no mapping at the fault address) in call_init
at 0xef7ca154
0xef7ca154​: call_init+0x0014​: st %i0, [%fp + 0x44]
(dbx) where
current thread​: t@​1
=>[1] call_init(0xef721324, 0x400181, 0xffffffff, 0xef7ed7b8,
0xef7ed7a0, 0x0), at 0xef7ca154
dbx​: fetch at 0xef7fffd8 failed -- I/O error
dbx​: attempt to read stack failed - bad frame pointer

There's not really much to go on with this ticket. Marking it stalled.

@smpeters - Status changed from 'open' to 'stalled'

From @schwern

5.005 threads are due to be eliminated in 5.10. Closing this bug.

The RT System itself - Status changed from 'stalled' to 'open'

@schwern - Status changed from 'open' to 'resolved'

From @hvds

"Michael G Schwern via RT" <perlbug-followup@​perl.org> wrote​:
:5.005 threads are due to be eliminated in 5.10. Closing this bug.

This seems like an inappropriate justification for closing the bug​:
if there is a bug in (eg) 5.8.x the ticket remains valid.

Closing it because there is insufficient information and the OP does
not respond to requests for more info might be valid. But leaving
it 'stalled' as it was before seems appropriately descriptive.

Hugo

From @schwern

On Wed, Jul 13, 2005 at 03​:31​:58PM +0100, hv@​crypt.org wrote​:

"Michael G Schwern via RT" <perlbug-followup@​perl.org> wrote​:
:5.005 threads are due to be eliminated in 5.10. Closing this bug.

This seems like an inappropriate justification for closing the bug​:
if there is a bug in (eg) 5.8.x the ticket remains valid.

Closing it because there is insufficient information and the OP does
not respond to requests for more info might be valid. But leaving
it 'stalled' as it was before seems appropriately descriptive.

Let's be pragmatic. Do we have any plans to fix 5.005 threads in the 5.8
track? Is it likely that some white knight is going to come forward now,
after this bug sitting around for five years and 5.005 threads have
been torn out of bleadperl, and fix it?

The 5.8.x track will remain open for a long time, I'd rather we didn't
have to keep all the 5.005 threads bugs stalled for another five years just
in case. There's already 144 stalled tickets.

However, instead of "resolved" I can mark these "rejected" and ensure the
type is "5005threads" so they can be found later. Good nuff?

--
Michael G Schwern schwern@​pobox.com http​://www.pobox.com/~schwern
Reality is that which, when you stop believing in it, doesn't go away.
  -- Phillip K. Dick

From @hvds

Michael G Schwern <schwern@​pobox.com> wrote​:
:On Wed, Jul 13, 2005 at 03​:31​:58PM +0100, hv@​crypt.org wrote​:
:> "Michael G Schwern via RT" <perlbug-followup@​perl.org> wrote​:
:> :5.005 threads are due to be eliminated in 5.10. Closing this bug.
:>
:> This seems like an inappropriate justification for closing the bug​:
:> if there is a bug in (eg) 5.8.x the ticket remains valid.
:>
:> Closing it because there is insufficient information and the OP does
:> not respond to requests for more info might be valid. But leaving
:> it 'stalled' as it was before seems appropriately descriptive.
:
:Let's be pragmatic. Do we have any plans to fix 5.005 threads in the 5.8
:track? Is it likely that some white knight is going to come forward now,
:after this bug sitting around for five years and 5.005 threads have
:been torn out of bleadperl, and fix it?

It won't be fixed - there's no code, and hardly any useful information;
it is not possible to discern that this represents a bug, let alone
how it might be fixed.

The wording of your closure message worried me because it suggested the
same approach would be applied to a genuine bug report that could in
principle be investigated and maybe fixed.

:The 5.8.x track will remain open for a long time, I'd rather we didn't
:have to keep all the 5.005 threads bugs stalled for another five years just
:in case. There's already 144 stalled tickets.

What problem does it cause having 144 stalled tickets? Do they somehow
get in the way? I had assumed that 'stalled' meant that it would be
impossible to validate and track down the reported bug without more
information from the originator, and that they therefore don't need
to be looked at unless more information arrives or someone wants to
pursue the originator.

:However, instead of "resolved" I can mark these "rejected" and ensure the
:type is "5005threads" so they can be found later. Good nuff?

Good nuff.

On the general point, I think it is important to keep things in the
bug database that are accepted as bugs but that are unlikely to be
fixed. Further, in an ideal world, each bug report would be branched by
perl version, so that we'd also be able to see that a bug reported for
5.6.0 was fixed in 5.8.4, unlikely to be backported to 5.6.x, and
irrelevant in 5.10.x due to chainsaw.

But I also ccept that we don't live in an ideal world, and that everyone
is eager to see the open bug count go down, and that more metadata
inevitably means more work for maintainers.

Hugo

From @schwern

On Thu, Jul 14, 2005 at 02​:15​:35AM +0100, hv@​crypt.org wrote​:

What problem does it cause having 144 stalled tickets? Do they somehow
get in the way? I had assumed that 'stalled' meant that it would be
impossible to validate and track down the reported bug without more
information from the originator, and that they therefore don't need
to be looked at unless more information arrives or someone wants to
pursue the originator.

Yeah, that's what they should mean and what I use it to mean. But I'm
going through them and finding a lot that were marked as stalled but are
fixable or turn out to have already been fixed. Reducing the number of
bugs in general makes these sort of sweeps a lot easier. Closing a bunch
of stalled bugs that will never be fixed helps that. The 5.005 threads
thing is a special case.

On the general point, I think it is important to keep things in the
bug database that are accepted as bugs but that are unlikely to be
fixed.

I agree, and I use stalled for that or just leave them open.

Further, in an ideal world, each bug report would be branched by
perl version, so that we'd also be able to see that a bug reported for
5.6.0 was fixed in 5.8.4, unlikely to be backported to 5.6.x, and
irrelevant in 5.10.x due to chainsaw.

But I also ccept that we don't live in an ideal world, and that everyone
is eager to see the open bug count go down, and that more metadata
inevitably means more work for maintainers.

Yeah. For a while I was making sure the Perl Version and Fixed In fields
for each bug were all properly marked but after a few dozen it gets really
tiresome and pretty much stopped. Especially since its mostly just Steve
and my occassional manic sweeps. If folks on p5p would examine a bug a
day or some such steady approach things would be a lot more sustainable.

--
Michael G Schwern schwern@​pobox.com http​://www.pobox.com/~schwern
Just call me 'Moron Sugar'.
  http​://www.somethingpositive.net/sp05182002.shtml

@schwern - Status changed from 'resolved' to 'rejected'