Developer forums (C::B DEVELOPMENT STRICTLY!) > Contributions to C::B

SIGPIPE handler is not set to default handler

<< < (2/3) > >>

blacksages:

--- Quote from: oBFusCATed on January 19, 2019, 06:10:22 pm ---
--- Quote from: blacksages on January 19, 2019, 10:28:58 am ---... SIGPIPE signal handler by GCC standard should be SIG_DFL, but codeblocks doesn't respect that standard...

--- End quote ---
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.

--- End quote ---

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.
--- End quote ---
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.

stahta01:
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.

blacksages:

--- Quote from: stahta01 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.

--- End quote ---

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...

BlueHazzard:

--- Quote from: blacksages on January 19, 2019, 07:53:42 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...

--- End quote ---
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

blacksages:
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 :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version