Re: [fpc-pascal] library (win32 dll) finalization section - what is allowed and what not?
On 04 Oct 2010, at 15:28, Bernd Kreuss wrote: Currently I am poking around in the dark and doing some trial and error and try to leave this section alone (as much as possible). Is there anything I could read that would tell me clearly what is actually allowed here and in which order things are uninitialized so I can see myself what must fail and why and what can be safely done? I don't know anything about Windows specifically, but FPC always executes the finalization sections of all units in the opposite order compared to how the initialization sections were called. The initialization order is determined by the unit dependencies (processed in the order in which units appear in the uses-clauses, using a depth- first approach), but note that the order is hard to predict if you have circular dependencies. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] library (win32 dll) finalization section - what is allowed and what not?
Hi, I'm currently fighting with some problems that seem to have to do with the order in which things are done when a library is unloaded. For example I have written a little exception handler unit that installs its handler function with AddVectoredExceptionHandler() from within the initialization section and uninstalls it in the finalization section. Now I seem to have discovered that it matters in which order I use my units: when I use my exception handler as the last unit in my library it will not crash on unload but if it is the first unit it will reliably crash with c005 somewhere in ntdll.dll (sometimes i can catch and print it while the main application (3rd party, closed source) is still running but sometimes the app even disappears instantly). Also it seems that I am risking more crashes *sometimes* and totally non-deterministic when I use things like OutputDebugString(PChar(Format(...))) in the finalization section, sometimes this happens even without the Format() but sometimes it works (it will output the string but then immediately crash. Might this be the PChar that becomes invalid too early during unload?) Also things like TProcess.Terminate; TProcess.Free will reliably provoke a crash when done during finalization and in general it seems that also all my TThreads are already stopped (but not freed) at this point, but i also can't free them anymore at this point. Currently I am poking around in the dark and doing some trial and error and try to leave this section alone (as much as possible). Is there anything I could read that would tell me clearly what is actually allowed here and in which order things are uninitialized so I can see myself what must fail and why and what can be safely done? Bernd ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] library (win32 dll) finalization section - what is allowed and what not?
Am 04.10.2010 15:28, schrieb Bernd Kreuss: Hi, I'm currently fighting with some problems that seem to have to do with the order in which things are done when a library is unloaded. For example I have written a little exception handler unit that installs its handler function with AddVectoredExceptionHandler() from within the initialization section and uninstalls it in the finalization section. Now I seem to have discovered that it matters in which order I use my units: when I use my exception handler as the last unit in my library it will not crash on unload but if it is the first unit it will reliably crash with c005 somewhere in ntdll.dll (sometimes i can catch and print it while the main application (3rd party, closed source) is still running but sometimes the app even disappears instantly). Also it seems that I am risking more crashes *sometimes* and totally non-deterministic when I use things like OutputDebugString(PChar(Format(...))) in the finalization section, sometimes this happens even without the Format() but sometimes it works (it will output the string but then immediately crash. Might this be the PChar that becomes invalid too early during unload?) Also things like TProcess.Terminate; TProcess.Free will reliably provoke a crash when done during finalization and in general it seems that also all my TThreads are already stopped (but not freed) at this point, but i also can't free them anymore at this point. Currently I am poking around in the dark and doing some trial and error and try to leave this section alone (as much as possible). Is there anything I could read that would tell me clearly what is actually allowed here and in which order things are uninitialized so I can see myself what must fail and why and what can be safely done? Bernd You might want to take a look at the Old New Thing blog from one of the Microsoft developers. He has written some interesting things about DllMain (finalization sections are called when DllMain entrypoint is called with DLL_PROCESS_DETACH as parameter). Here is a search link (for DllMain) on that blog: http://blogs.msdn.com/search/SearchResults.aspx?q=dllmain§ions=2905 Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] TProcess.Free - three exceptions in ntdll.dll - only *sometimes*
Hi, has anybody ever had the problem of TProcess.Free causing three exceptions in in ntdll.dll? C005 at 7C928FEA in C:\WINDOWS\system32\ntdll.dll 7C928FEA seems to be RtlpWaitForCriticalSection() somewhere deep inside the windows kernel. The first two happen almost immediately and the third one a few seconds later. I narrowed it down to TProcess.CloseOutput(), CloseInput() and CloseStderr() and if I create the process with poStderrToOutPut there will only be two exceptions instead of three. At the time this happens the process is already terminated because I sent it its quit command via its input and then WaitOnExit() and it will terminate orderly. Nobody should be reading or writing to these pipes anymore. Is there any alternative way to close the stdio? My only workaround at the moment is to never free the TProcess at all and simply hope that it won't crash when the dll is unloaded (it is all residing inside a dll that is loaded and unloaded during runtime). Most of the time it won't crash this way, but unfortunately not always. Bernd ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Delphi incompatible conditionals?
> -- Doorgestuurd bericht --
> From: Martin
> if you can put it after the uses clause (so you can have a const section, the
> following worked for me:
> {$IFNDEF FPC}
> const fpc_version=1; fpc_release=1;
> {$ENDIF}
> // your code below
> {$IFDEF FPC}
> {$IFNDEF ver1}
> {$IF (fpc_version>2) or (fpc_version=2) and (fpc_release>3)}
> {$info FPC version >= 2.4.0 : Should work}
> {$ELSE}
> {$warning FPC versions below 2.4 are not supported. However :
> give it a try, you never know.}
> {$IFEND}
> {$ELSE}
> {$fatal FPC version 1 isn't supported at all}
> {$ENDIF}
> {$ENDIF}
>
Not an option : uses clauses may depend on the defines in the file.
>
> {$IF Defined(fpc_version) and ((fpc_version>word(2)) or
> (fpc_version=word(2)) and (fpc_release>word(3)))}
>
> gets rid of the warnings
Works great on Delphi, but doesn't compile in fpc with following message:
Zeos.inc(49,9) Error: Compile time expression: Wanted INTEGER but got
STRING at "2 > word"
Also tried Marcov's Longint(2) instead of word(2). Same error.
Mark
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
