Author Topic: SIGPIPE handler is not set to default handler  (Read 513 times)

Offline blacksages

  • Single posting newcomer
  • *
  • Posts: 6
SIGPIPE handler is not set to default handler
« on: January 19, 2019, 12:36:40 am »
SIGPIPE signal handler is set to SIG_IGN instead of SIG_DFL
Even though gnu gcc default (edit: the default compiler on codeblocks I used) signal handler should not ignore the signals : https://www.gnu.org/software/libc/manual/html_node/Operation-Error-Signals.html

I reported this error on stackoverflow: https://stackoverflow.com/questions/53801914/why-was-default-sigpipe-handler-changed

A detailed example is given on my stackoverflow post please look into it for more information.

this was tested on fedora 28, it is not a behaviour of fedora but codeblocks itself
« Last Edit: January 19, 2019, 03:58:24 pm by blacksages »

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6437
    • My Best Post
Re: SIGPIPE handler is not set to default handler
« Reply #1 on: January 19, 2019, 01:29:19 am »
Do you understand that Code::Blocks is an IDE; and, it is not a compiler?

Because your post seems to be about an compiler issue instead of a IDE issue.

Edit: The link implies you know the difference between the CB IDE and the GCC Compiler.

Looks like an Linux expert is going to have to read your link to decide if this is a valid CB issue.

Tim .
« Last Edit: January 19, 2019, 01:33:08 am by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline blacksages

  • Single posting newcomer
  • *
  • Posts: 6
Re: SIGPIPE handler is not set to default handler
« Reply #2 on: January 19, 2019, 10:28:58 am »
Sorry I should make this clearer.

I installed codeblocks and the default compiler given was gcc. SIGPIPE signal handler by GCC standard should be SIG_DFL, but codeblocks doesn't respect that standard.
In my post I elaborate on how I tried to use GCC with the command-line, and it showed in command-line that SIG_DFL was used, so indeed it is not a problem with the compiler.

edit: One of the comment on my post suggested it was due to gtk library
« Last Edit: January 19, 2019, 10:31:53 am by blacksages »

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 2253
Re: SIGPIPE handler is not set to default handler
« Reply #3 on: January 19, 2019, 05:31:06 pm »
I do not think codeblocks alters anything in your signal handlers....
Codeblocks does not alter the code or anything about your program. I think the problem is in the console runner codeblocks uses. Can you try if the error happens also if you run the with codeblocks compiled program from the shell and not from within codeblocks?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11492
    • Travis build status
Re: SIGPIPE handler is not set to default handler
« Reply #4 on: January 19, 2019, 06:10:22 pm »
... SIGPIPE signal handler by GCC standard should be SIG_DFL, but codeblocks doesn't respect that standard...
Can you provide a quote from the standard where it is specified that the signal handlers should have been reset to defaults after a fork/exec? From the info given up to now I can only conclude that they are inherited from the parent process and so they have random state after fork/exec. So if your program has some expectations, it should use the specific system calls to set them up.

p.s. signal handlers are OS feature and they have nothing to do with GCC.
p.p.s. There is no mention of SIGPIPE in C::B's source code...

(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline blacksages

  • Single posting newcomer
  • *
  • Posts: 6
Re: SIGPIPE handler is not set to default handler
« Reply #5 on: January 19, 2019, 07:27:21 pm »
... SIGPIPE signal handler by GCC standard should be SIG_DFL, but codeblocks doesn't respect that standard...
Can you provide a quote from the standard where it is specified that the signal handlers should have been reset to defaults after a fork/exec? From the info given up to now I can only conclude that they are inherited from the parent process and so they have random state after fork/exec. So if your program has some expectations, it should use the specific system calls to set them up.

There is no specific line saying that fork or exec should reset/inherit any signal handling :) Anywya i'm not using any of these in the code
As provided, gnu gcc standard states
Quote
The default action for all of them is to cause the process to terminate.
on https://www.gnu.org/software/libc/manual/html_node/Operation-Error-Signals.html

In your opinion, there is no reason taht codeblocks would do anything to change signal handlers. But Why is this problem only occuring when I use codeblocks? As I said, I tried it on commandline with the same code and the signal handler was on SIG_DFL not SIG_IGN

My program shouldn't have to fiddle with signal handlers if the compiler specify a default behaviour.
If you looked on my stackoverflow post, you'll see the code and that i don't change anything on signal handlers.
« Last Edit: January 19, 2019, 07:52:39 pm by blacksages »

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6437
    • My Best Post
Re: SIGPIPE handler is not set to default handler
« Reply #6 on: January 19, 2019, 07:47:04 pm »
Why are you not complaining to wxGTK people?

Note: There is no evidence that wxGTK is at fault. But, there is little evidence that CB is at fault.

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline blacksages

  • Single posting newcomer
  • *
  • Posts: 6
Re: SIGPIPE handler is not set to default handler
« Reply #7 on: January 19, 2019, 07:53:42 pm »
Why are you not complaining to wxGTK people?

Note: There is no evidence that wxGTK is at fault. But, there is little evidence that CB is at fault.

Tim S.

So the console used by codeblocks is made with gtk+?

Because someone gave away this link github.com/linuxmint/gtk/blob/master/gtk/gtkmain.c#L689
gtk+ library does change SIGPIPE signal handler, but i don't know its relation with codeblocks...
« Last Edit: January 19, 2019, 08:00:45 pm by blacksages »

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 2253
Re: SIGPIPE handler is not set to default handler
« Reply #8 on: January 19, 2019, 08:33:05 pm »
So the console used by codeblocks is made with gtk+?

Because someone gave away this link github.com/linuxmint/gtk/blob/master/gtk/gtkmain.c#L689
gtk+ library does change SIGPIPE signal handler, but i don't know its relation with codeblocks...
How do you think codeblocks starts a program? Codeblocks uses fork or exec to run a program, and if this calls influence the signal handling so will codeblocks influence the signal handling. But i do not see how we could avoid this....
Codeblocks uses wxWidgets for convenience and on linux wxWidgets uses gtk, so if gtk changes the signal handling so will codeblocks.
You can see from this behaviour that relating on default signal handling on linux is "broken" by default if you relay on it. Better set all to a known state if you want to relate on something. Codeblocks saved your life here xD

greetings

Offline blacksages

  • Single posting newcomer
  • *
  • Posts: 6
Re: SIGPIPE handler is not set to default handler
« Reply #9 on: January 19, 2019, 08:52:12 pm »
Did it save me or cost me hours of forehead scratching? Hum...
But thanks for your input, I feel relieved to understand the bottom of the matter :)

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 2253
Re: SIGPIPE handler is not set to default handler
« Reply #10 on: January 19, 2019, 09:06:42 pm »
Did it save me or cost me hours of forehead scratching? Hum...
But thanks for your input, I feel relieved to understand the bottom of the matter :)
it made you now investigate in a problem and find the cause of this problem. If this would have happened on the client side after shipping, because he uses your program througth some other program, happy debugging....