Tue Jan 11 19:16:34 2011: Request 64575 was acted upon.
Transaction: Correspondence added by j...@activestate.com
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: ha...@strotbek.com
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
