Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2011-08

timer_create on linux

12 messages · 4 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Max Vlasov

Hi,

I tried to implement linux timer with timer_create and signals, but an exception always fired (External:SIGUSR1).
It was a lcl program, but I narrowed it to a console one. Here is the lines without extra codes of releasing (the error appears before),
What can be wrong with the code below?

Thanks in advance,

Max

==================================

program ConsTest;
uses ... libc, baseunix;
procedure PosixTimerHandler(signal: longint; info: psiginfo; context:
psigcontext);cdecl;
begin
  Now; // <- Never stops here.
end;
procedure TMyApplication.DoRun;
var
  ...
  fnewact: SigActionRec;
  fits: itimerspec;
  sev: sigevent;
  timerid: timer_t;
begin
...
  { add your program here }
  FillChar(fnewact, sizeof(SigActionRec),0);
  fnewact.sa_handler := @PosixTimerHandler;
  fnewact.sa_flags:=SA_SIGINFO;
  if fpsigaction(SIGUSR1,@fnewact, Nil)  0 then
    raise Exception.Create('sigaction failed');
  sev.sigev_notify := SIGEV_SIGNAL;
  sev.sigev_signo := SIGUSR1;
  timer_create(CLOCK_REALTIME, @sev, @timerid);
  fits.it_value.tv_sec := 1;
  fits.it_value.tv_nsec := 0;
  fits.it_interval.tv_sec := 1;
  fits.it_interval.tv_nsec := 0;
  timer_settime(timerid, 0, @fits, Nil);
  ReadLn(); // <- raise External:SIGUSR1. With debug fpc rtl, the line stops
at "call  psysinfo" inside FpSysCall
Unknown author
to Max Vlasov
Max Vlasov wrote 8 lines
Hi, I tried to implement linux timer with timer_create and signals, but an exception always fired (External:SIGUSR1). It was a lcl program, but I narrowed it to a console one. Here is the lines without extra codes of releasing (the error appears before), What can be wrong with the code below?

I assume threads are used for these timers.
If so, then this is normal, signal USR1 is used
by the linux threading mechanism, if I remember correctly.

Michael.

Max Vlasov
to Unknown author
Show quoted text 16 lines
On Wed, 10 Aug 2011, Max Vlasov wrote: Hi, > > I tried to implement linux timer with timer_create and signals, but an > exception always fired (External:SIGUSR1).... > What can be wrong with the code below? > I assume threads are used for these timers. If so, then this is normal, signal USR1 is used by the linux threading mechanism, if I remember correctly.

I also thought that the signal could be occupied by some api, but changing it to SIGRTMIN + 1, +2,+3 just changes the exception to "External:SIG35", "External:SIG36"...
Maybe I should apply the blocking mask for other signal for this api since it probably uses threads?

Max

Max Vlasov
to Max Vlasov: I tried to implement linux timer with timer_create and signals, but an exception always…
Max Vlasov wrote 5 lines
Hi, I tried to implement linux timer with timer_create and signals, but an exception always fired (External:SIGUSR1).

Hmm, it seems that it's not a 'wrong' exception, I executed the same program from console and it worked. So there's a range of signals that is 'wrong' for the debugger/ide and it stops catching them. Can I somehow tell it to ignore some, for example 'SIG35'? I tried to add it to Language exceptions ignore list as 'External: SIG35', 'External:SIG35' (without space), SIG35. Nothing helped.

Max

Jonas Maebe
to Max Vlasov
Max Vlasov wrote 12 lines
On Wed, Aug 10, 2011 at 1:18 PM, Max Vlasov wrote: > I tried to implement linux timer with timer_create and signals, but > an > exception always fired (External:SIGUSR1). > Hmm, it seems that it's not a 'wrong' exception, I executed the same program from console and it worked. So there's a range of signals that is 'wrong' for the debugger/ide and it stops catching them.

It's not considered as "wrong" by gdb. By default it simply catches all signals. If you type "cont" at that point, the program will continue execution and the signal will be delivered to the program.

Show quoted text 6 lines
Can I somehow tell it to ignore some, for example 'SIG35'? I tried to add it to Language exceptions ignore list as 'External: SIG35', 'External:SIG35' (without space), SIG35. Nothing helped.

handle SIG35 nostop noprint pass

Jonas

Max Vlasov
to Jonas Maebe
Jonas Maebe wrote 12 lines
Can I somehow tell it to > ignore some, for example 'SIG35'? I tried to add it to Language exceptions > ignore list as 'External: SIG35', 'External:SIG35' (without space), SIG35. > Nothing helped. > handle SIG35 nostop noprint pass

Jonas, where am I supposed to add this options?

I tried adding
--eval-command="handle SIGUSR1 nostop noprint pass" to
Debugger_Startup_Options

but that didn't help. Actually nothing happened until I restarted the IDE. After the restart the first run showed
---------------
Initialization output:
&"Undefined command:\"\".Try \"help\".\n"
----------

To ensure the string is correct I tried
gdb --eval-command="handle SIGUSR1 nostop noprint pass" from terminal and it worked.
Is it possible that some procedure makes c-style string translation (" -> \") while actually it isn't necessary here?

Max

Jonas Maebe
to Max Vlasov
Max Vlasov wrote 13 lines
On Wed, Aug 10, 2011 at 4:34 PM, Jonas Maebe < >wrote: >> Can I somehow tell it to >> ignore some, for example 'SIG35'? I tried to add it to Language >> exceptions >> ignore list as 'External: SIG35', 'External:SIG35' (without >> space), SIG35. >> Nothing helped. > > handle SIG35 nostop noprint pass > Jonas, where am I supposed to add this options?

That's what you can enter on the gdb console after you start it from the command line. I've never debugged using Lazarus, so I can't help with that.

I tried adding --eval-command="handle SIGUSR1 nostop noprint pass"

While this won't solve your problem, as Michael said you should not use SIGUSR1 because it's probably already used by the system.

Jonas

Max Vlasov
to Jonas Maebe
Jonas Maebe wrote 10 lines
I tried adding > --eval-command="handle SIGUSR1 nostop noprint pass" > While this won't solve your problem, as Michael said you should not use SIGUSR1 because it's probably already used by the system.

SIG35 behaves the same. Strangely, I looked in system monitor for gdb command-line, it looked ok

/usr/bin/gdb -silent -i mi -nx --eval-command="handle SIG35 nostop noprint pass"

but after the same Initialization output dialog it still stops with "External:SIG35"
Actually looking at the -i mi options, I see it's machine interface with all these escaping sequences, so probably lazarus didn't undestand something, but it's strange it still stops

Thanks anyway

Max

Jonas Maebe
to Max Vlasov
Max Vlasov wrote 14 lines
SIG35 behaves the same. Strangely, I looked in system monitor for gdb command-line, it looked ok /usr/bin/gdb -silent -i mi -nx --eval-command="handle SIG35 nostop noprint pass" but after the same Initialization output dialog it still stops with "External:SIG35" Actually looking at the -i mi options, I see it's machine interface with all these escaping sequences, so probably lazarus didn't undestand something, but it's strange it still stops

Most commands are different in the machine interface. "handle SIG35 nostop noprint pass" is probably only valid when using the default interface. I don't know what the MI equivalent is.

Jonas

Max Vlasov
to Jonas Maebe
Jonas Maebe wrote 23 lines
On 10 Aug 2011, at 16:12, Max Vlasov wrote: SIG35 behaves the same. Strangely, I looked in system monitor for gdb > command-line, it looked ok > > /usr/bin/gdb -silent -i mi -nx --eval-command="handle SIG35 nostop noprint > pass" > > but after the same Initialization output dialog it still stops with > "External:SIG35" > Actually looking at the -i mi options, I see it's machine interface with > all > these escaping sequences, so probably lazarus didn't undestand something, > but it's strange it still stops > Most commands are different in the machine interface. "handle SIG35 nostop noprint pass" is probably only valid when using the default interface. I don't know what the MI equivalent is.

If I invoke the same full line in the terminal the output

$ /usr/bin/gdb -silent -i mi -nx --eval-command="handle SIG35 nostop noprint
pass"

=thread-group-added,id="i1"
~"Signal Stop\tPrint\tPass to program\tDescription\n" ~"SIG35 No\tNo\tYes\t\tReal-time event 35\n"

So looks like (Stop = No) gdb got the command.
Jonas, I see that you probably have your reasons not to use gdb inside the lazarus, but it was quite decent for me until this strange unavoidable moment :) It still is, hope I will find a work around

Max

Helmut Hartl
to Max Vlasov
Max Vlasov wrote 5 lines
Jonas, I see that you probably have your reasons not to use gdb inside the lazarus, but it was quite decent for me until this strange unavoidable moment :) It still is, hope I will find a work around Max

Max,

This works (for me)

1) Add a file like :
/Users/helly/fos_buildsys/gdbinit

2) Content of file is:
handle SIGUSR1 pass noprint nostop

3) Add in Lazarus at

Debuger_Startup_Options : --command /Users/helly/fos_buildsys/gdbinit

4) Depending on lazarus version -> Reset Debugger via Menu / or restart

---

I use this to ignore signals, and it works here. (afair under linux/freebsd the same way)
I debug a multithreaded server hith kevent/kqueue waiting on the signals. (hup,kill,usr1,int) in a commandline daemon. I am on OSX Lion, fpc 2.5.1 trunk (2 weeks ago) lazarus trunk (2-3 weeks) ago.

helmut

Max Vlasov
to Helmut Hartl
Helmut Hartl wrote 35 lines
Am 10.08.11 16:56, schrieb Max Vlasov: Jonas, I see that you probably have your reasons not to use gdb inside the > lazarus, but it was quite decent for me until this strange unavoidable > moment :) It still is, hope I will find a work around > > Max > Max, This works (for me) 1) Add a file like : /Users/helly/fos_buildsys/**gdbinit 2) Content of file is: handle SIGUSR1 pass noprint nostop 3) Add in Lazarus at Debuger_Startup_Options : --command /Users/helly/fos_buildsys/**gdbinit 4) Depending on lazarus version -> Reset Debugger via Menu / or restart --- I use this to ignore signals, and it works here. (afair under linux/freebsd the same way) I debug a multithreaded server hith kevent/kqueue waiting on the signals. (hup,kill,usr1,int) in a commandline daemon. I am on OSX Lion, fpc 2.5.1 trunk (2 weeks ago) lazarus trunk (2-3 weeks) ago.

Helmut, worked like magic! Thanks :)
In case Graeme see this post (he hates over-quoting desperately), I intentionally did not cut the quote to make this useful information exist twice everywhere ;)

Max