p5-net-ssleay icon indicating copy to clipboard operation
p5-net-ssleay copied to clipboard

XS code assumes that USE_ITHREADS means that the `threads` package is actually loaded

Open SineSwiper opened this issue 2 years ago • 2 comments

I'm running into a problem with a thread-compiled 5.18.2 Perl that tries to load in Net::SSLeay and fails:

XSLoader at dev-perl/centos7/5.18.2/lib/perl5/XSLoader.pm line 90.
        XSLoader::load('Net::SSLeay', 1.92) called at dev-perl/centos7/5.18.2/lib/perl5/x86_64-linux-thread-multi/Net/SSLeay.pm line 856
        eval {...} called at dev-perl/centos7/5.18.2/lib/perl5/x86_64-linux-thread-multi/Net/SSLeay.pm line 858
        require Net/SSLeay.pm called at dev-perl/centos7/5.18.2/lib/perl5/IO/Socket/SSL.pm line 19
        IO::Socket::SSL::BEGIN() called at dev-perl/centos7/5.18.2/lib/perl5/x86_64-linux-thread-multi/Net/SSLeay.pm line 0
        eval {...} called at dev-perl/centos7/5.18.2/lib/perl5/x86_64-linux-thread-multi/Net/SSLeay.pm line 0
        require IO/Socket/SSL.pm called at dev-perl/centos7/5.18.2/lib/perl5/HTTP/Tiny.pm line 529
        eval {...} called at dev-perl/centos7/5.18.2/lib/perl5/HTTP/Tiny.pm line 529
        HTTP::Tiny::can_ssl('HTTP::Tiny') called at dev-perl/centos7/5.18.2/lib/perl5/HTTP/Tiny.pm line 1566
        HTTP::Tiny::Handle::_assert_ssl('HTTP::Tiny::Handle=HASH(0x2cb2728)') called at dev-perl/centos7/5.18.2/lib/perl5/HTTP/Tiny.pm line 1062
        HTTP::Tiny::Handle::connect('HTTP::Tiny::Handle=HASH(0x2cb2728)', 'https', 'domain', 9200, 'domain') called at dev-perl/centos7/5.18.2/lib/perl5/HTTP/Tiny.pm line 702
        ...etc...
Can't locate object method "tid" via package "threads" at dev-perl/centos7/5.18.2/lib/perl5/XSLoader.pm line 94.

Note that I had to put in a Carp::cluck line in the XSLoader to get a stack trace.

Looking at the XS code, there are built-in assumptions that just because #ifdef USE_ITHREADS is declared, then the threads package is already loaded. However, that's not the case, and the XS version of threads->tid fails.

A workaround is use threads; in the main script, but I don't want to use threads.

Unfortunately, I can't get a stack trace of XS code, so I only know that the XS code somehow fails during the XSLoader process. But, BOOT is calling get_my_thread_id, and this appears to be the only case where it's trying to call threads->tid.

SineSwiper avatar Sep 13 '22 17:09 SineSwiper