Bug 6482

Summary: spamd crash when run under Windows x64
Product: Spamassassin Reporter: Daniel Lemke <lemke>
Component: spamc/spamdAssignee: SpamAssassin Developer Mailing List <dev>
Status: RESOLVED WORKSFORME    
Severity: normal CC: lemke, sidney
Priority: P2    
Version: 3.3.1   
Target Milestone: Undefined   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description Daniel Lemke 2010-08-11 03:59:35 UTC 
I was just able to work around a bug with a specific dll when SpamAssassin is executed under a Win x64 system.

I'm aware that it's not a SpamAssassin bug but I guess that users having that issue will have a look here first (so it should give them some information, at least).

Steps to reproduce:
- Use a x64 Windows
- Install Perl (x86) (I tested Strawberry 5.10, 5.12 and ActivePerl 5.8.8, 5.8.9, 5.10, 5.12)
- Install SpamAssassin
- Start spamd with a small --max-spare (e.g. 1) and -m 10 or so.
- Let it process several mails at once so spamd will have to start couple of new children.

When processing is finished, spamd will kill most children. This will cause the interpreter to unload a dll, called IPHLPAPI.dll. Now, any call to that dll (dns resolves, etc.) will cause spamd to crash.

I added the following call in spamd spawn() sub to "fix" it:
  $pid = fork();
  die "spamd: fork: $!" unless defined $pid;
  Win32::LoadLibrary("Iphlpapi");

I'm not yet sure where I do have to report this. It may be a problem of Perl or of Microsoft's concept in 64-bit systems, where they have something like a layer virtual box for x86 processes that links to the corresponding x64 libraries.


Daniel
Comment 1 Daniel Lemke 2010-08-24 04:42:25 UTC 
This bug may be closely related to Bug 6359: In order to avoid "safe" signals, posix:sigaction is used in the util script. POSIX::SIGALRM( ) isn't available for Windows so we explicit forced the script to use $SIG{ALRM} instead. I've just found this article describing exactly that issue: 

> Note that some networking library functions like gethostbyname() are 
> known to have their own implementations of timeouts which may conflict 
> with your timeouts. If you are having problems with such functions, you 
> can try using the POSIX sigaction() function, which bypasses the Perl 
> safe signals (note that this means subjecting yourself to possible 
> memory corruption, as described above). 
See: http://perldoc.perl.org/perlipc.html#Deferred-Signals-%28Safe-Signals%29

Note that the crash always occured immediately after a call of gethostbyname()...

May it be possible to use Perl::Unsafe::Signals for the affected parts instead?

Daniel
Comment 2 Sidney Markowitz 2022-04-25 12:54:38 UTC 
This is old, and I could not reproduce it using 3.4.4 so I'm closing.