We have upgraded the community system as part of the upgrade a password reset is required for all users before login in.

How to capture CTRL+C in a native C/C++ compiled application

  • Hi,

    I have this C++ framework that compiles across Win32 and Linux on x86/ARM/MIPS.. so far so good.

    To be able to trap the user pressing CTRL+C I have installed following signal handlers that work fine under Linux on x86 and ARM (Raspberry) platforms.

    signal(SIGINT, sigproc);
    signal(SIGQUIT, quitproc);

    Unfortunately these don't seem to work on OpenWRT/Omega

    Anybody an idea which signals I should use?


  • Seems like my framework was doing just fine... but I was using the new GPIO library from Kit Bishop !?

    Once I backed out this library and used the fast GPIO instead, CTRL+C worked as expected.

    Possibly the new GPIO library also sets a hook for CTRL+C

  • @Johan-Simons Sorry you are having issues with my new-gpio library šŸ˜ž
    It is possible that it has some issues with trapping CTRL+C - I'll take a look and make any changes needed.

  • @Kit-Bishop Thx for looking into it.

    I also noticed that my app uses 4% system memory with the fast GPIO libs... and 10% with your new GPIO lib. Guess that has to do with the usage of threads in your lib.

  • @Johan-Simons Probably more to do with the usage of C++ objects than the threads, though thread usage may well have some impact too. I will look at this too in case I can reduce it.

    Can you let me know how you are using the new-gpio libraries? What calls you are making etc? This may help me diagnose what needs doing. thanks

  • @Johan-Simons FYI: I have found why my new-gpio code is not trapping CTRL-C
    My mistake in the coding, there is a line left over from some testing I was doing that should not be in there.
    I am in the process of changing some of the code and the fix will be in the next release.

    For now, if you are building libnew-gpio from the sources I supplied, you can fix this yourself by removing the line that reads:

          sigaddset(&irqSigset, SIGINT); //	Ctrl+C

    from the file GPIOAccess.cpp

    Regarding the memory usage, I think this can be attributed to the following reasons:

    • new-gpio provides significant increased functionality over fast-gpio so there is more code
    • new-gpio has quite extensive error checking and returning that does not exist in fast-gpio so again more code
    • new-gpio uses C++ classes rather than straight C code and this carries some overhead
    • In order to properly implement both PWM and IRQ handling some of the object instances of the classes have to hang around during the program execution
    • Both PWM and IRQ currently use an object or data structure for each pin. At present, these are actually allocated as soon as the system is initialised. On closer consideration, this is not actually needed until such time as PWM or IRQ is used for a pin. So I will make a change that ensures they are only allocated when actually needed.

    Finally, there may be some savings to be had by ensuring unneeded symbols are stripped from the object code.

  • @Johan-Simons After a bit of extra digging and changes, I have managed to make a small reduction in the memory usage of new-gpio (stripping symbols made negligible difference, some code changes made a small difference).
    As far as I can see the main factors affecting the size of new-gpio vs fast-gpio are primarily:

    • Extra code in new-gpio to handle the extra functionality
    • Memory used by additional system libraries that new-gpio code uses.

    Unless this is a major issue for you, I don't think there is much more I can do.

  • @Kit-Bishop

    I was just using set pin direction and get/set pin value, so it was quite a large difference in memory usage between fast and new GPIO.

    But as you state, your code is more extensive and provides more functionality.

    For my application the extra memory is no problem as it will be the sole app running on the Onion. My eye fell on it while debugging a memory leak.

    Anyway, it would be great to have the CTRL+C issue fixed.

    Thx for the effort

  • @Johan-Simons All good - let me know if you find any issues.

    Have you managed to deal with the Ctrl-C issues using the fix I posted above?

    Just to assist me in diagnosing possible memory related issues, can you let me know how you are using the fast-gpio code to manipulate the pins:

  • @Kit-Bishop

    Removing the sigaddset(&irqSigset, SIGINT); did NOT solve the problem of CTRL+C not working.

    I compile the fast-gpio sources in my own C++ app, so it is all in my executable, no libraries linked, no external apps called or processes spawned.

  • @Johan-Simons Thanks for the quick reply.

    • Surprised to hear that removing the sigaddset doesn't work for you - it seems to do so for me. I will have a closer look and get back to you as and when I find anything.
    • Thanks for the info on how you are building - this implies that the extra memory usage for new-gpio is down to the extra code functionality

Log in to reply

Looks like your connection to Community was lost, please wait while we try to reconnect.