RE: [rt.cpan.org #64575] Start callback not called with Strawberry Perl 5.10 / 5.12

Tue Jan 11 19:16:34 2011: Request 64575 was acted upon.
Transaction: Correspondence added by [email protected]
       Queue: Win32-Daemon
     Subject: RE: [rt.cpan.org #64575] Start callback not called with Strawberry Perl 5.10 / 5.12
   Broken in: (no value)
    Severity: (no value)
       Owner: Nobody
  Requestors: [email protected]
      Status: open
 Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=64575 >


On Tue, 11 Jan 2011, Haiko Strotbek via RT wrote:
> 
> > I find that hard to believe.  Did you sprinkle some OutputDebugString()
> > calls into the function and then watch either with the Sysinternals
> > Debug viewer, or Visual Studio etc. to see where the control flow
> > goes through.  If DllMain() isn't called, then all the other initializations
> > in the DLL_PROCESS_ATTACH entry in the switch statement won't happen
> > either.
> 
> Perhaps I made a mistake:
> I #defined DEBUG in all header files and added these lines at Daemon.xs:955
> 		        {
> 		            char szBuffer[256];
> 		            sprintf( szBuffer, "Main thread ID: %lu", gMainThreadId );
> 		            ALERT( szBuffer );
> 		        }
> 
> and these at Daemon.xs:918
>         {
>             char szBuffer[256];
>             sprintf( szBuffer, "Started for reason: %lu", fdwReason );
>             ALERT( szBuffer );
>         }
> 
> but none of the messages appear in the debug output file.
> 
> Is there something wrong with this?

Yes, ALERT() will write to the log file, which isn't opened until you
call Win32::Daemon::DebugOutputPath().  That's why I suggested you use

	OutputDebugString( szBuffer );

The use the DebugView utility from Sysinternal (now part of Microsoft)
to display all debugging output:

    http://technet.microsoft.com/en-us/sysinternals/bb896647

> I also verified that the patch definitely works - and since I tried two
> different versions of Strawberry Perl I don't think that it's my fault
> in any way.

This is not about something being anyone's fault.  I simply don't want
to apply a patch to code that I haven't written, that I don't understand
how/why it would make a difference.  Especially since there are no
regression tests for this module either.

Until I understand *why* the patch makes a difference on your system,
I can't really be sure that the patch is correct in the general case,
and if it covers the whole problem, or just a part of it.  E.g. if
the DllMain() function really isn't called, then there are other
initializations that aren't happening either.  But I don't think this
is the root cause of the problem.

I really appreciate it that you are helping to uncover the real problem
behind the issue you are seeing.

Cheers,
-Jan