Re: Error: conflicting types for ‘sbrk’
On Wed, Mar 21, 2018 at 11:07:45AM -0300, Larissa Braz wrote: > Hi, > > I found the following compilation error: > > xmalloc.c:51:14: error: conflicting types for ‘sbrk’ > extern char *sbrk(); > ^ > In file included from xmalloc.c:29:0: > /usr/include/unistd.h:1043:14: note: previous declaration of ‘sbrk’ was here > extern void *sbrk (intptr_t __delta) __THROW; [...] > #if defined (HAVE_SBRK) && !HAVE_DECL_SBRK > extern char *sbrk(); > #endif This declaration is conditional. It will only be evaluated if HAVE_SBRK=1 HAVE_DECL_SBRK=0 These are set by the configure script based on what it can detect from your system. It is strange that it detects a working sbrk implementation, but no sbrk declaration. * What source tree are you building? (i.e. git devel branch, git master branch, tarball?) * Also, are you passing any special parameters to `configure' or `make'? * Can you share the following blocks from your config.log and config.h after running the configure script? $ grep -i 'checking for.*sbrk' config.log -A5 configure:10615: checking for sbrk configure:10615: gcc -o conftest -ggdb -O0 -Wno-parentheses -Wno-format-security conftest.c >&5 configure:10615: $? = 0 configure:10615: result: yes configure:10615: checking for fpurge configure:10615: gcc -o conftest -ggdb -O0 -Wno-parentheses -Wno-format-security conftest.c >&5 -- configure:14469: checking for working sbrk configure:14496: gcc -o conftest -ggdb -O0 -Wno-parentheses -Wno-format-security conftest.c -ldl >&5 configure:14496: $? = 0 configure:14496: ./conftest configure:14496: $? = 0 configure:14506: result: yes $ grep SBRK config.h #define HAVE_DECL_SBRK 1 #define HAVE_SBRK 1
bash handles terminate signals incorrectly, when it is run as the init process in a pid namespace
Hello,
Periodically we see bash processes which run in busy loops:
$ strace -fp 15264
strace: Process 15264 attached
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
rt_sigreturn({mask=[QUIT]}) = 143
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
rt_sigreturn({mask=[QUIT]}) = 143
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
rt_sigreturn({mask=[QUIT]}) = 143
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
rt_sigreturn({mask=[QUIT]}) = 143
$ gdb -p 15264
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) si
termsig_sighandler (sig=11) at sig.c:488
488 sig != SIGHUP &&
(gdb) s
486 if (
(gdb)
523sig == terminating_signal)
(gdb)
521sig != SIGUSR2 &&
(gdb)
526 terminating_signal = sig;
(gdb)
534 if (interactive_shell == 0 || interactive == 0 ||
(sig != SIGHUP && sig != SIGTERM) || no_line_editing || (RL_ISSTATE
(RL_STATE_READCMD) == 0))
(gdb)
536 history_lines_this_session = 0;
(gdb)
Breakpoint 1, termsig_sighandler (sig=11) at sig.c:539
539 termsig_handler (sig);
(gdb)
termsig_handler (sig=) at sig.c:564
564 if (handling_termsig)
(gdb)
termsig_sighandler (sig=11) at sig.c:538
538 terminate_immediately = 0;
(gdb)
539 termsig_handler (sig);
(gdb)
termsig_handler (sig=11) at sig.c:564
564 if (handling_termsig)
(gdb)
termsig_sighandler (sig=11) at sig.c:548
548 if (RL_ISSTATE (RL_STATE_SIGHANDLER) || RL_ISSTATE
(RL_STATE_TERMPREPPED))
(gdb)
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x5b006e
0x in ?? ()
I decided to investigate this problem and found that bash handles all
signals, and if it decides that a signal should be fatal, it sets a
default signal handler and sends the same signal to itself.
Unfortunately this doesn't work in a case, when a bash process is an
init process in its pid namespace, because an init process ignores all
signals which are sent from the current namespace.
It can be easy reproduced:
[avagin@laptop issue]$ cat run.sh
#!/bin/bash
set -e -m
unshare -fp sh -c 'exec -a init1234 bash init.sh' &
sleep 3
pid=`pidof init1234`
kill $pid
sleep 3
kill -9 $pid
[avagin@laptop issue]$
[avagin@laptop issue]$ cat init.sh
#!/bin/bash
function finish {
echo Exit trap
}
trap finish EXIT
while :; do
sleep 1;
echo "Alive"
done
[avagin@laptop issue]$ unshare -Ur bash -x run.sh
+ set -e -m
+ sleep 3
+ unshare -fp sh -c 'exec -a init1234 bash init.sh'
Alive
Alive
++ pidof init1234
+ pid=30916
+ kill 30916
+ sleep 3
Exit trap
Alive
Alive
Alive
+ kill -9 30916
You can see that the process continues working after the exit hook. It
is obviously a bug.
Another bad thing here is that termsig_handler() works only once:
void
termsig_handler (sig)
int sig;
{
static int handling_termsig = 0;
/* Simple semaphore to keep this function from being executed multiple
times. Since we no longer are running as a signal handler, we don't
block multiple occurrences of the terminating signals while running. */
if (handling_termsig)
goto out;
handling_termsig = 1;
terminating_signal = 0; /* keep macro from re-testing true. */
So if we kill a test process by SIGTERM, it sets a default handler for
SIGTERM and sends SIGTERM to itself again. As the process is the init
process in its pidns, the signal is ignored, and the process continues
running. Then the process triggers SIGSEGV (e.g. deference unmapped
memory), the kernel sends SEGV, bash executes its signal handler
(termsig_sighandler), but it doesn't try to set a default signal
handler, because termsig_handler() was already executed once, so the
process returns back from a signal handler and triggers SIGSEGV again
and so on.
I am thinking how to fix this issue properly. Here are a few points:
* bash should know that signals are ignored if a process is the init
process in a pid namespace.
* user and kernel signals (SEGV, SIGFPE, SIGBUS, etc) are handled differently
* bash should not return back from termsig_sighandler(), if it has
sent a signal to itself.
Do you have any ideas, advices, comments about this problem?
Thanks,
Andrei
Proper use of nohup within here-document?
Hi, I'm using Bash version 4.1.2 on RedHat EL 6.8 (I realize these are old releases). In one of my bash scripts I have a here-document and at the end of it's execution it will pop-up an gxmessage. My problem is that when the here-document exits, the gxmessage closes. Within the here-document I'm essentially calling gxmessage thusly: $ nohup gxmessage -timeout 0 -file abc.txt > /dev/null 2>&1 & Any ideas on how I can allow the here-document to exit but allow the gxmessage process to live on? Thanks, -- Mun
bash long prompt, color going past the end of prompt after reaching bottom of terminal
From: mabdulla
To: bug-bash@gnu.org
Subject: bash long prompt, color going past the end of prompt after
reaching bottom of terminal
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE
-DRECYCLES_PIDS -DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin' -O2 -g
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
uname output: Linux onx-mabdulla-01.ciena.com 3.10.0-327.59.3.el7.x86_64 #1
SMP Thu Sep 21 09:34:57 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 4.2
Patch Level: 46
Release Status: release
Description:
look at Repeat-By section
Repeat-By:
calculate_prompt1(){
host="my-linux"
git_branch="a very very very very very very very very very very
very very very very long prompt"
prompt="@$host \\w : \[$(tput bold)$(tput setab 1)$(tput setaf
7)\]${git_branch}\[$(tput sgr0)\]\$ "
export PS1="$prompt"}
PROMPT_COMMAND="calculate_prompt1;"
If you have to, resize your terminal so the prompt goes on two lines.
Then keep pressing enter until the bottom of the terminal.
keep pressing enter past the bottom of the terminal and you will see
that the background color doesn't
clear after the end of prompt
bash two line prompt, after reaching the bottom of terminal color going past the end of prompt
How to reproduce bug:
calculate_prompt1(){
host="my-linux"
git_branch="a very very very very very very very very very very
very very very very long prompt"
prompt="@$host \\w : \[$(tput bold)$(tput setab 1)$(tput setaf
7)\]${git_branch}\[$(tput sgr0)\]\$ "
export PS1="$prompt"}
PROMPT_COMMAND="calculate_prompt1;"
If you have to, resize your terminal so the prompt goes on two lines.
Then keep pressing enter until the bottom of the terminal.
keep pressing enter past the bottom of the terminal and you will see
that the background color doesn't
clear after the end of prompt
Re: bash long prompt, color going past the end of prompt after reaching bottom of terminal
On 3/22/18 1:44 PM, Musse Abdullahi wrote: > Bash Version: 4.2 > Patch Level: 46 > Release Status: release > > Description: > look at Repeat-By section If the version information above is accurate, you should investigate newer versions of bash. Version 4.2 is two major versions behind and was released around seven years ago. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: bash long prompt, color going past the end of prompt after reaching bottom of terminal
On 22.3. 22:22, Chet Ramey wrote: On 3/22/18 1:44 PM, Musse Abdullahi wrote: Bash Version: 4.2 Patch Level: 46 Release Status: release Description: look at Repeat-By section If the version information above is accurate, you should investigate newer versions of bash. Version 4.2 is two major versions behind and was released around seven years ago. I get the same with '4.4.12(1)-release' too, but it doesn't seem related to Bash or the prompt. I can get it with just a printf, the colored part just needs to get wrapped by the end of line. printf "%100s $(tput setab 1)colored part$(tput sgr0) normal again\n" If the screen scrolls, the background color on the last character gets copied to the next line. At least one way to work around that seems to be to clear the end of the line after the colored part ends, by putting "$(tput el)" after "$(tput sgr0)". You probably don't have anything to the right of the cursor at that point, so it'll only reset the color. -- Ilkka Virta / itvi...@iki.fi
Re: bash handles terminate signals incorrectly, when it is run as the init process in a pid namespace
On 3/22/18 3:38 PM, Andrei Vagin wrote: > I am thinking how to fix this issue properly. Here are a few points: > * bash should know that signals are ignored if a process is the init > process in a pid namespace. Why should it know this? It's not documented, not portable, and conflicts with the way signals are documented to behave. This is a situation-specific problem. > * user and kernel signals (SEGV, SIGFPE, SIGBUS, etc) are handled differently Fatal signals (signals whose default disposition is to exit the process) are pretty much handled identically. > * bash should not return back from termsig_sighandler(), if it has > sent a signal to itself. That suggests that the easiest way to solve the problem is to add a call to exit() after the kill(). -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
