in reply to Re: Perl 5.8.2 thread is worse - more findings from today
in thread Perl 5.8.2 thread is worse - more findings from today

"Can you cut the code down to something that shows that its actually 'detach' thats breaking it"

Okay, that's easy. It only took me 1 minute to come up with this code, and break (core dump) it: (I repeated 3 times to make sure it is really broken)

use strict; use warnings; use threads; for (my $i = 1; $i < 1000; $i ++) { threads->create(\&abc)->detach(); } sub abc { }

Update:

It was a waste to create 1000 threads, and side tracks people's focus. This is much more simple and clear:

use strict; use warnings; use threads; for (my $i = 1; $i < 3; $i ++) { threads->create(\&abc)->detach(); } <>; sub abc { }

Update 2:

The testing is done on win32, using .2. This was mentioned in the first stream of notes Perl 5.8.2 thread is much worse on .2 threads. Any way, I should have repeated this here earlier.

Replies are listed 'Best First'.
Re: Re: Re: Perl 5.8.2 thread is worse - more findings from today
by liz (Monsignor) on Dec 28, 2003 at 19:24 UTC
    Could you try it with this change (in pseudo diff format):
    sub abc { +undef }
    A bug (new to 5.8.2) causes problems with empty subroutines. Put the undef in there, and see if that helps. I've had to update several of my modules to get around this problem for threaded 5.8.2.

    I should have thought about this earlier. The whole thing sort of left my mind already... ;-) Good thing I document my changes... ;-)

    BTW, this should already be fixed for 5.8.3.

    Liz

      Tried, and it was the same thing. So the problem here is not empty subs. I also tried to add a line in that sub to print "abcdefg", the same thing.

        FWIW, your example code works fine under Mac OS X (10.2.8) and Linux (RH9), and is even valgrind clean.

        It must be a Win32 only thing, it would seem. That is out of my league, I'm afraid. Please perlbug your simple case, particularly to ActiveState.

        Liz

Re: Re: Re: Perl 5.8.2 thread is worse - more findings from today
by Corion (Patriarch) on Dec 28, 2003 at 19:55 UTC

    I can partly confirm the results with my perl 5.8.2 under Windows 2000 - some times, the snippet crashes with an access violation, but sometimes it dosen't. I could not safely reproduce the bug all times. This looks to me like a weird bug in Perl to me, some uninitialized pointer somewhere.

    Update: In my search for the cause, I found the following behaviour - the segfault appears within a spawned thread, as the following script exits even as the segfault messagebox is still on screen:

    use strict; use warnings; use threads; for (1..2) { threads->create(sub { undef })->detach(); }; sleep 1;
    Summary of my perl5 (revision 5 version 8 subversion 2) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=undef use5005threads=undef useithreads=define usemultip +licity=def ine useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -Gf -W3 -MD -DNDEBUG -O1 -DWIN32 -D_CON +SOLE -DNO_ STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS +-DUSE_PERL IO -DPERL_MSVCRT_READFIX', optimize='-MD -DNDEBUG -O1', cppflags='-DWIN32' ccversion='', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64 +', lseeksi ze=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -release -libpath:"d:\ +perl\5.8.2 \lib\CORE" -machine:x86' libpth=C:\PROGRA~1\MICROS~3\VC98\lib libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib + comdlg32 .lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uui +d.lib wsoc k32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt. +lib perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool +.lib comd lg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib + uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msv +crt.lib libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib gnulibc_version='undef' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release -l +ibpath:"d: \perl\5.8.2\lib\CORE" -machine:x86' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL +_IMPLICIT_ CONTEXT PERL_IMPLICIT_SYS Built under MSWin32 Compiled at Nov 6 2003 12:48:55 @INC: D:/perl/5.8.2/lib D:/perl/site/5.8.2/lib .
    perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ; # The $d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider ($c = $d->accept())->get_request(); $c->send_response( new #in the HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' # web
Re: Re: Re: Perl 5.8.2 thread is worse - more findings from today
by castaway (Parson) on Dec 28, 2003 at 19:40 UTC
    No core dump using that code on my perl 5.8.2:
    This is perl, v5.8.2 built for i686-linux-thread-multi
    
    Copyright 1987-2003, Larry Wall
    
    Perl may be copied only under the terms of either the Artistic License or the
    GNU General Public License, which may be found in the Perl 5 source kit.
    
    Complete documentation for Perl, including FAQ lists, should be found on
    this system using `man perl' or `perldoc perl'.  If you have access to the
    Internet, point your browser at http://www.perl.com/, the Perl Home Page.
    

    C.

      I thought you were in the loop, any way, this is win32 + Perl .2

      As you can see that, liz clearly knows this.

        What loop? Your original claim was that it was probably broken on all platforms, which is why I tried it, to confirm that it is not. (You'll notice that my post is slightly before liz', saying that it works on MAC OS and her linux..)

        C.

Re: Re: Re: Perl 5.8.2 thread is worse - more findings from today
by PodMaster (Abbot) on Dec 29, 2003 at 09:05 UTC
    If invoke perl interactively like so, no memory access violations.
    E:\>perl use strict; use warnings; use threads; for (my $i = 1; $i < 3; $i ++) { threads->create(\&abc)->detach(); } <>; sub abc { } __END__ E:\>perl -V Summary of my perl5 (revision 5 version 8 subversion 2) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=undef use5005threads=undef useithreads=define usemultip +licity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -Gf -W3 -MD -DNDEBUG -O1 -DWIN32 -D_CON +SOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLIC IT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX', optimize='-MD -DNDEBUG -O1', cppflags='-DWIN32' ccversion='', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64 +', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -release -libpath:"G:\ +perls\5.8.2\lib\CORE" -machine:x86' libpth=\lib \site\lib libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib + comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib ver +sion.lib odbc32.lib odbccp32.lib msvcrt.lib perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool +.lib comdlg32.lib advapi32.lib shell32.lib ole32. lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib + version.lib odbc32.lib odbccp32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib gnulibc_version='undef' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release -l +ibpath:"G:\perls\5.8.2\lib\CORE" -machine:x86' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL +_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS Built under MSWin32 Compiled at Nov 5 2003 21:13:21 %ENV: PERL5LIB="G:\perls\5.8.2\site\lib;" @INC: G:\perls\5.8.2\site\lib G:/perls/5.8.2/lib . E:\>
    update: ok, if I save it to a file, it happens, d'oh. The bugs appears in threads.dll according to mah debugger (Unhandled exception in perl.exe(THREADS.DLL): 0XC0000005 ). And apparently, line 152 in threads.xs is the culprit (        PerlMemShared_free(thread);)

    update: I should note that both the threads cause this violation, but that this is only apparent in the debug version (in the non-debug version it's death after the 1st), and that like corion, I can't reliably reproduce this (sometimes I have no problems running the snippet, sometimes I do).

    It appears that the interactive invocation can cause the error also.

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

Re: Re: Re: Perl 5.8.2 thread is worse - more findings from today
by dominix (Deacon) on Dec 30, 2003 at 10:51 UTC
    under cygwin, which basicaly is win32 with a *nix layer this code core dump
    # echo|perl thisscript use strict; use warnings; use threads; for (my $i = 1; $i < 3; $i ++) { threads->create(\&abc)->detach(); } <>; sub abc { }
    while this one is OK
    #perl use strict; use warnings; use threads; for (my $i = 1; $i < 3; $i ++) { threads->create(\&abc)->detach(); } sleep 1; sub abc { }
    ... I've tried to mix case of empty sub and processing the <>.
    --
    dominix