RE: [fpc-pascal] sending signal to child process
Hi, I found that the problem is coming from the fact that I use process.Options := ProcessB.Options + [poUsePipes]; If I switch that off, process B does execute the signal handling code. Is this a bug or am I missing something? Thx, Tom -Original Message- From: fpc-pascal-boun...@lists.freepascal.org [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Henry Vermaak Sent: maandag 30 maart 2009 16:37 To: FPC-Pascal users discussions Subject: Re: [fpc-pascal] sending signal to child process 2009/3/30 Tom Carly : > Hi, > > > > I have a process A that starts another process B (with TProcess.Create). > > I introduced signal handling for SIGHUP, SIGTERM and SIGINT in process A and > process B. > > The signal handling of process A triggers a call to > "fpkill(processA.processid, SIGTERM)" (or "processA.Terminate(0)"). do you mean processB.processid here? > > This code is executed when killing process A. > > The problem is that the signal handling code of process B is not executed > when killing process A (although process B does get killed). > > If I launch process B separately and kill it, then the signal handling code > of process B is executed. It seems that the signal that is sent from process > A to process B is not the same as when you kill it via the command line. are the permissions the same for the two processes? are you sending sigterm from the commandline, too? i've done something similar before, but using a different signal. that shouldn't matter, since sigterm can be blocked (unlike sigkill and sigstop). henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] sending signal to child process
2009/3/31 Tom Carly : > Hi, > > I found that the problem is coming from the fact that I use > process.Options := ProcessB.Options + [poUsePipes]; > > If I switch that off, process B does execute the signal handling code. Is > this a bug or am I missing something? it would be great if you could make a bugrep with a very simple example. henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] modifying system.pp's InstallSignals
I'm working on a project in Linux where I've got some special signal handling requirements. I need to modify system.pp's InstallSignals to dynamically load an .so, look up a function by name, and make some calls into that library instead of doing what it normally does. The dynlibs unit has the code I need to call SafeLoadLibrary and GetProcedureAddress, but my problem is that obviously I can't just put "uses dynlibs" in system since, well, it's system, and there would be circular dependencies since system is pretty much first on the dependency list. My thought is that basically I'll just have to pull the code from dynlibs.pas, dynlibs.inc, and dl.pp into my own .inc file and include it rather than trying to have anything in a uses section. I'm aware that doing this will decrease the portability of my code and make me dependent on libc, but these changes I'm making to the rtl are for a very specific purpose, and I won't be using them to compile anything else. :) Does that seem like the right way for me to get the functionality of those calls available to me in InstallSignals? Or is there something easier I'm missing? Thanks, SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] modifying system.pp's InstallSignals
In our previous episode, Seth Grover said: > Does that seem like the right way for me to get the functionality of > those calls available to me in InstallSignals? Or is there something > easier I'm missing? It is roughly ok. Optionally you can also -dFPC_USE_LIBC to force the system unit to use libc instead of syscalls, and save a few kb. Note that this is less frequently tested though. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] modifying system.pp's InstallSignals
Seth Grover schreef: Does that seem like the right way for me to get the functionality of those calls available to me in InstallSignals? Or is there something easier I'm missing? I don't think it can be done without editing the system unit. If you are willing to do that, I would add a procvar called CustomSignalHandler: TProcedure in the interface section of the system unit (or in an include file included in the interface section of the system unit). In the signal handler of the system unit, test assigned(CustomSignalHandler) and call it, if it is assigned, else do the current thing. Create a new unit MySignalHandlerUnit that contains your signal handler and that has procedure MySignalHandler in its interface. In the initialization section do System.CustomSignalHandler := @MySignalHandler; Add MySignalHandlerUnit to the uses section of your main program. Vincent P.S. I am sure you can find better names. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] modifying system.pp's InstallSignals
On 31 Mar 2009, at 15:53, Vincent Snijders wrote: Seth Grover schreef: Does that seem like the right way for me to get the functionality of those calls available to me in InstallSignals? Or is there something easier I'm missing? I don't think it can be done without editing the system unit. If you are willing to do that, I would add a procvar called CustomSignalHandler: TProcedure in the interface section of the system unit (or in an include file included in the interface section of the system unit). In the signal handler of the system unit, test assigned(CustomSignalHandler) and call it, if it is assigned, else do the current thing. In general this works well, but not in this case, since InstallSignals is called from the system unit's initialization code, and that's the first code that is executed when a program starts up. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] heaptrc unit output
I've been using the heaptrc unit in DEBUG versions of my application to detect memory leaks. However, when a memory leak is detected, it does not include any information on the unit, line number, etc - just the hex addresses, like this: Heap dump by heaptrc unit 15648 memory blocks allocated : 692533/768936 15641 memory blocks freed : 692193/768560 7 unfreed memory blocks : 340 True heap size : 753664 True free heap : 752816 Should be : 752896 Call trace for block $B7A58528 size 100 $B7E1A1C2 $B7F63DFD $B7EA9F16 $B7E2AD23 $B7E2B030 $0804891B $B7B03450 I am using fpc 2.2.0, and building the shared library as follows: fpc -Sd -Cgiro -g -gh -gl -dDEBUG library.pas -Fu../path1 -Fu../path2 -Fu../path3 Am I missing anything, or is this a shared library issue? Thanks much, Alan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] heaptrc unit output
On 31 Mar 2009, at 20:12, Alan Krause wrote: I am using fpc 2.2.0, and building the shared library as follows: fpc -Sd -Cgiro -g -gh -gl -dDEBUG library.pas -Fu../path1 -Fu../path2 -Fu../path3 Am I missing anything, or is this a shared library issue? It's a shared library issue. It has been fixed for a number of platforms in 2.2.4: http://bugs.freepascal.org/view.php?id=4171 (I don't know about Linux though, but I think so). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] heaptrc unit output
Thanks much for the FYI, Jonas. Alan On Tue, Mar 31, 2009 at 1:02 PM, Jonas Maebe wrote: > It's a shared library issue. It has been fixed for a number of platforms in > 2.2.4: http://bugs.freepascal.org/view.php?id=4171 (I don't know about > Linux though, but I think so). > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
