in reply to Re: panic: regfree data code 'ð' during global destruction. error when joining threads
in thread panic: regfree data code 'ð' during global destruction. error when joining threads

The perl version I am running is 
Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
  Platform:
    osname=solaris, osvers=2.8, archname=sun4-solaris-thread-multi-64i
+nt
    uname='sunos thor1 5.8 generic_117350-26 sun4u sparc sunw,sun-fire
+-v210 '
    config_args='-de -Dcc=gcc -Dmake=make -D prefix=/opt/VRTSperl -D u
+sethreads -D useithreads -D useperlio -D use64bitint'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemulti
+plicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=define use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -fno-strict-aliasing -pipe -Wdecl
+aration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_F
+ILE_OFFSET_BITS=64',
    optimize='-O',
    cppflags='-D_REENTRANT -fno-strict-aliasing -pipe -Wdeclaration-af
+ter-statement -I/usr/local/include'
    ccversion='', gccversion='3.4.2', gccosandvers='solaris2.8'
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=87654321
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=1
+6
    ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='of
+f_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -L/usr/local/lib '
    libpth=/usr/local/lib /usr/lib /usr/ccs/lib
    libs=-lsocket -lnsl -ldl -lm -lpthread -lc
    perllibs=-lsocket -lnsl -ldl -lm -lpthread -lc
    libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'


Characteristics of this binary (from libperl):
  Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT
                        PERL_MALLOC_WRAP USE_64_BIT_INT USE_ITHREADS
                        USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API
  Built under solaris
  Compiled at May  1 2007 14:18:14
  @INC:
    /opt/VRTSperl/lib/5.8.8/sun4-solaris-thread-multi-64int
    /opt/VRTSperl/lib/5.8.8
    /opt/VRTSperl/lib/site_perl/5.8.8/sun4-solaris-thread-multi-64int
    /opt/VRTSperl/lib/site_perl/5.8.8
    /opt/VRTSperl/lib/site_perl
    .

[download]
I am using threads::shared, but at the moment the only things that are shared are the subroutine, args passed onto the queue that the thread is waiting on to execute.

I made my Object pool global and simplified it so it surely can be cleaned up. Even after cleaning everything up myself, I get: 

DESTROY AIX=HASH(0x86df04)
DESTROY Cfg=HASH(0x8bea54)
DESTROY HPUX1123=HASH(0x8851e8)
DESTROY HPUX1131=HASH(0x89ec3c)
DESTROY RHEL4x8664=HASH(0x8686ac)
DESTROY RHEL5x8664=HASH(0x86d4a8)
DESTROY SLES10x8664=HASH(0x86d9d0)
DESTROY SLES9x8664=HASH(0x891110)
DESTROY SolSparc=HASH(0x89f164)
DESTROY Solx64=HASH(0x890d98)
DESTROY Sys=HASH(0x8850d4)
1 17:12:31 thread 1 returning sq_run_subs
0 17:12:32 Joining thread 1
DESTROY Thr=HASH(0x91994c)
DESTROY EDR=HASH(0x885014)
panic: regfree data code 'À' during global destruction.

[download]
I presume the last two do not get cleaned up because I am running a subroutine from the Thr class, called from one in the EDR class. I can't imagine these objects being thread-unsafe, they're as simple as can be. Any further insight on to what is going on would be a blessing.
  • Comment on Re^2: panic: regfree data code 'ð' during global destruction. error when joining threads
  • Select or Download Code

Replies are listed 'Best First'.
Re^3: panic: regfree data code 'ð' during global destruction. error when joining threads
by BrowserUk (Patriarch) on Jun 12, 2008 at 02:15 UTC

    You didn't identify which version of threads you are using? 

    perl -Mthreads -le"print $threads::VERSION"

    [download]

    Debugging any code is nigh impossible without seeing the code. Debugging threaded code without seeing it is impossible. If you're worried about proprietary code, then simply remove everything you can whilst still exhibiting the same problem.

    If you take something out and the problem goes away, put it back. When you have the minimum code left that still panics, post it. If nothng else, you will have a suitable testcase for raising a bug report.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
      thanks for the common sense advice. I took my working Thread module and instead of slamming it into my other system, added elements until the break was detected several hours later. I don't know exactly the cause, but it is a combination of using: 
      use Data::Dumper;
$Data::Dumper::Deparse=1;

      [download]
      along with a number of objects for the thread->join to clean up and the twist, a subroutine with a regular expression in it, hence the regfree reference.

      Thanks everyone for their help.

[reply]
[d/l]
        but it is a combination of using: use Data::Dumper; $Data::Dumper::Deparse=1;

        Yep! That'd do it. From the docs for D::D:

        Caution : use this option only if you know that your coderefs will be properly reconstructed by B::Deparse.

        I seriously doubt if that option or B::Deparse have ever been tested seriously in a threaded environment.

        If you can see your way clear to producing a small tst case demonstrating the panic, and raising a perlbug, it might be get fixed sometime.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom