Let me document another "funny" bug that I ran into while trying to install Net::SSLeay using nmake and VC2013: Even after installing openssl and setting the OPENSSL_PREFIX environment variable, for some unknown reason the build script was not able to find the libeay and ssleay libraries. You would get these warnings:
Warning (mostly harmless): No library found for -libeay32 Warning (mostly harmless): No library found for -ssleay32 Followed by many hundreds of external symbol errors. This is because the "link" command failed to actually link against the ssleay and libeay libraries. `look Net::SSLeay` and re-run the link command, adding the paths to those two .lib files: link -out:blib\arch\auto\Net\SSLeay\SSLeay.dll -dll -nologo -nodefaultlib -debug -opt:ref,icf -ltcg -libpath:"c:\cpantest\perl5163\lib\CORE" -machine:AMD64 "/manifestdependency:type='Win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'" SSLeay.obj "C:\cpantest\perl5163\lib\CORE\perl516.lib" <SNIP> "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\LIB\amd64\msvcrt.lib" "C:\openssl\lib\libeay32.lib" "C:\openssl\lib\ssleay32.lib" -def:SSLeay.def then `nmake install` and install IO::Socket::SSL. Regards, Dan Collins On Fri, Dec 19, 2014 at 5:30 PM, bulk88 <[email protected]> wrote: > Reini Urban wrote: > >> On 12/19/2014 02:25 PM, A. Sinan Unur wrote: >> >> >>> On Fri, Dec 19, 2014 at 3:00 PM, A. Sinan Unur <[email protected]> wrote: >>> >>> >>>> On Fri, Dec 19, 2014 at 2:04 PM, A. Sinan Unur <[email protected]> wrote: >>>> >>>> >>>>> On Fri, Dec 19, 2014 at 11:08 AM, Nigel Horne <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>>> PS – it would help if the red column under the MSWin32 column of >>>>>> http://matrix.cpantesters.org/?dist=POE-Component-SmokeBox+0.48 >>>>>> could be >>>>>> addressed. >>>>>> >>>>>> >>>>> OK, some more progress ... Here is the stack when t\backend\02_check.t >>>> fails. We have a null pointer thing going on: >>>> >>>> First-chance exception at 0x0000000054BD04C7 (perl520.dll) in >>>> perl.exe: 0xC0000005: Access violation writing location >>>> 0x0000000000000000. >>>> Unhandled exception at 0x0000000054BD04C7 (perl520.dll) in perl.exe: >>>> 0xC0000005: Access violation writing location 0x0000000000000000. >>>> >>>> >>> Hmmmmm .... Could it be related to: >>> >>> http://perl5.git.perl.org/perl.git/commitdiff/ >>> 1cbe4e6fdc25527a4e9930e2f6a96fea3834bfd1?hp= >>> 8fe523b46877224b0d8f3bd5ea78396ff0b4242d >>> >>> SvREFCNT_dec_NN in SDBM >>> >>> VC 2003 optimizer didn't catch it because SvREFCNT_dec is rarely inlined >>> on -O1 >>> >>> >> >> Yes, bulk88's _NN patch is wrong. You need to catch the NULL here >> >> > > My patch was correct. "if(pointer){if(!pointer) {unreachable();}}" If > suddenly unreachable() can be called, you need to submit a bug report to > your CC vendor. > > The callstack is from 5.20.*, that p5 core patch is in 5.21.7. Its not on > Unur's machine. Since the callstack had symbols, it is easy to figure out > what went wrong. > > perl520.dll!VMem::Free(void * pMem) Line 202 C++ > perl520.dll!Perl_safesysfree(void * where) Line 360 C > SDBM_File.dll!XS_SDBM_File_DESTROY(interpreter * my_perl, cv * cv) Line > 262 C > perl520.dll!Perl_pp_entersub(interpreter * my_perl) Line 2797 C > .......... > perl520.dll!perl_destruct(interpreter * my_perl) Line 807 C > perl520.dll!win32_start_child(void * arg) Line 1796 C++ > > Line 202, http://perl5.git.perl.org/perl.git/blob/HEAD:/win32/vmem.h#l202 > 197 if (ptr->owner != this) { > 198 if (ptr->owner) { > 199 #if 1 > 200 int *nowhere = NULL; > 201 Perl_warn_nocontext("Free to wrong pool %p not > %p",this,ptr->owner); > 202 *nowhere = 0; /* this segfault is deliberate, 203 > so you can see the stack trace */ > 204 #else > 205 ptr->owner->Free(pMem); 206 #endif > 207 } > > SDBM_File is ithread and therefore psuedofork unsafe. It either needs a > CLONE method in PP, svt_dup magic, and/or MY_CXT or to fatally die if a > resource can't be duplicated and a CLONE is attempted. > > void > sdbm_DESTROY(db) > SDBM_File db > CODE: > if (db) { > int i = store_value; > sdbm_close(db->dbp); > do { > if (db->filter[i]) > SvREFCNT_dec(db->filter[i]); > } while (i-- > 0); > safefree(db) ; > } > ------------------------------------------ > SDBM_File T_PTROBJ > ------------------------------------------ > T_PTROBJ > if (SvROK($arg) && sv_derived_from($arg, \"${ntype}\")) { > IV tmp = SvIV((SV*)SvRV($arg)); > $var = INT2PTR($type,tmp); > } > else > Perl_croak(aTHX_ \"%s: %s is not of type %s\", > ${$ALIAS?\q[GvNAME(CvGV(cv))]:\qq[\"$pname\"]}, > \"$var\", \"$ntype\") > ------------------------------------------ > > SDBM_File > sdbm_TIEHASH(dbtype, filename, flags, mode, pagname=NULL) > char * dbtype > char * filename > int flags > int mode > char * pagname > CODE: > { > DBM * dbp ; > > RETVAL = NULL ; > if (pagname == NULL) { > dbp = sdbm_open(filename, flags, mode); > } > else { > dbp = sdbm_prep(filename, pagname, flags, mode); > } > if (dbp) { > RETVAL = (SDBM_File)safecalloc(1, sizeof(SDBM_File_type)); > RETVAL->dbp = dbp ; > } > } > OUTPUT: > RETVAL > ------------------------------------------- > Yep, thread unsafe. If instead of using a blessed SVIV, it used a blessed > SVPV and sv_grow/SvCUR_set, perl would automatically dup the memory block, > but it would still be unsafe since the memory block is > > typedef struct { > DBM * dbp ; > SV * filter[4]; > int filtering ; > } SDBM_File_type; > > and it keeps SV*s there that Perl doesn't know about at CLONE time. > > Now even if SDBM_File_type was replaced with an AV, and AvARRAY and SvIVX > for speed, you will still crash when > > ------------------------------------------ > sdbm_close(db->dbp); > ------------------------------------------ > > runs twice on the same "DBM * dbp". I dont see how this can ever be > thread safe. IMO setting the blessed SVIV object to 0 during a CLONE is the > only thing to do, unless you can duplicate the data/resources inside DBM * > through the DBMS's API. SDBM would fail with valgrind and ithreads on Linux > with a double free anyway inside sdbm_close(). > >
