gxbacher has asked for the wisdom of the Perl Monks concerning the following question:

Hi, I've written a SOAP client that runs fine on Windows (strawberry 5.10.1) when the protocol is HTTP, but as soon as I switch to HTTPS, perl crashes unexpectedly with no error (Windows 7 just says "perl.exe has stopped working" or something equally useless).

I should mention that my client forks and hits the SOAP server with several sub-processes in parallel. I've determined the following:
- HTTP with and without fork() = works fine
- HTTPS without fork() = works fine
- HTTPS with fork() = CRASH
It might be significant to note that, in Windows, fork does not start a new process, but rather is implemented with threads (or so I've read).

I suspect SSLeay simply because I've read about problems with Windows and threading. Am I wrong to suspect this?

Is there a way to replace SSLeay as the SSL provider for SOAP::Lite?

Any tips as to what I could try next?

Thanks in advance.

Replies are listed 'Best First'.
Re: SOAP::Lite, HTTPS and Windows
by Anonymous Monk on Mar 29, 2011 at 23:11 UTC
    fork, then require yada yada SSL, or use threads, then require yada yada ssl

    Check for error messages in the eventviewer (eventvwr.msc)

[reply]
[d/l]
[select]
      Thanks for that, the event log reveals:
      Faulting application name: perl.exe, version: 0.0.0.0, time stamp: 0x4adf6716
      Faulting module name: libssl32_.dll, version: 0.0.0.0, time stamp: 0x4a8d73a0
      Exception code: 0xc0000005
      Fault offset: 0x00006648
      Faulting process id: 0xa88
      Faulting application start time: 0x01cbee534f4beda4
      Faulting application path: C:\strawberry\perl\bin\perl.exe
      Faulting module path: C:\strawberry\c\bin\libssl32_.dll

      If Windows forked "process" fails, why would threads be any different?

[reply]
        its different because you use require instead of use, thats why its different
[reply]

Back to Seekers of Perl Wisdom