Re: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client
Hi Chet, Serge Dussud wrote: On 12/ 8/08 03:00 PM, Chet Ramey wrote: Serge Dussud wrote: Indeed, ld(1)'s -z interpose option is a rather big hammer, as it establishes that the application can interpose on *all* of the symbols that it offers, rather than just the few related to malloc. That might be a problem if there are some public symbols in libc that bash happens to use, but bash is pretty careful to replace libc functions only if they're missing or somehow substandard. OK. Not sure I am willing to take the risk at this point. Also, note that the linker issue is being investigated at the moment. FYI, the linker issue [1] was the root cause of all this, and was fixed in recent OpenSolaris build (snv_106). We're working on fixing it to previous version of Solaris, when/if applicable. Bottom line, we're not applying any patch to the way we build our bash delivery bundled to [Open]Solaris :) Thanks for the help/chat on this one, serge [1] http://bugs.opensolaris.org/view_bug.do?bug_id=6778453
Bash Commander: new project
Hello all, What do you think about extending bash functionality with visual two-panel file browser? Here is a new project to implement this: http://bashc.wiki.sourceforge.net/ Critique and suggestions are welcome. ___ Best wishes, Serge
Re: Bash Commander: new project
> I think it looks very much like midnight commander and other file > manager applications. How does this differentiate itself? Bash commander is not a separate application, like others. It is the same good old bash, with added functionality. About 2klines of source code, or about 20kbytes of binary code added to bash. The commander layer lies somewhere in between the core shell and readline library. Right now I use bashc as a replacement of /bin/bash on my home Mac mini. ___ Serge
Re: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client
Hi Chet, thanks for the quick answer. More in-line: On 10/ 3/08 10:52 PM, Chet Ramey wrote: Serge Dussud - Sun Microsystems wrote: Hello bug-bash, please find attached a bashbug report. I am not sure how to follow-up then, could you advise ? This is the appropriate venue for these reports. I have a few questions OK. about this one. 1. The trace shows that the process is not, in fact, using the bash malloc when it dies. The traced _malloc_unlocked and cleanfree functions are not in the bash malloc, but are present in libc. ff137068 sigacthandler (efe08, f706, 0, f8ca0, 0, 0) --- called from signal handler with signal 982536 (SIG Unknown) --- ff0e62a4 cleanfree (0, 8, ff1e64f8, ff1de63c, f83ec, 2) + 58 ff0e53d8 _malloc_unlocked (20, f7065554, efe00, f706, ff1e0468, ffdf) + 104 ff0e52b8 malloc (20, 0, 1, ff1de63c, f93c8, ff1e4864) + 48 I saw that, still, when I tried to analyze the core some while back, I had the feeling that debugger (mdb at the time ?) was confused with these malloc routines. That's when I realized about the malloc bash internal routines and tried compiling with --witthou-bash-malloc. 2. What library installs the `sigacthandler'? It's not a function in bash. It is a symbol in libc, but there's no indication which library installs it as a signal handler. I have just tried psig on on running bash (in another config), and see that the function that set signals handler for SIGV is indeed: bash-3.2# pgrep bash 16384 bash-3.2# psig 16384 | grep "^SEGV" SEGVblocked,caught termsig_sighandler 0 HUP,INT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,VTALRM,XCPU,XFSZ,LOST bash-3.2# termsig_sighandler() is part bash source code (sig.c) if I am not mistaken. 3. What does the traceback look like when bash is run under gdb and allowed to fail? I suspect that the libraries are pre-bound to use the system's malloc, and the calls to different malloc libraries are causing the core dumps. Another possibility is that libc functions are using private pseudo- global libc malloc interfaces, causing the libc malloc to be linked in. Either way, the trace and library load address maps indicate that the process is dying in the libc malloc. One way to confirm my suspicion is to start bash under gdb, set a breakpoint in malloc, and see where it stops. OK, I'll try that and come back to you. Thanks, Serge If it's documented that applications on Solaris may no longer link with their own versions of malloc, that's fine -- I can arrange things so that bash doesn't try to use it's internal malloc on Solaris 10 and 11. Chet
Re: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client
On 10/ 6/08 05:11 PM, Chet Ramey wrote: 2. What library installs the `sigacthandler'? It's not a function in bash. It is a symbol in libc, but there's no indication which library installs it as a signal handler. I have just tried psig on on running bash (in another config), and see that the function that set signals handler for SIGV is indeed: bash-3.2# pgrep bash 16384 bash-3.2# psig 16384 | grep "^SEGV" SEGVblocked,caught termsig_sighandler 0 HUP,INT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,VTALRM,XCPU,XFSZ,LOST bash-3.2# termsig_sighandler() is part bash source code (sig.c) if I am not mistaken. It is, but that's not what shows up in the call trace. Is `sigacthandler' part of the Solaris signal trampoline code? it's part of libc, sigaction() related code as far as I can tell: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/threads/sigaction.c#283 I am not very familiar with this part of Solaris code to be honest. Serge Chet
Re: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client
Hi Chet, any follow-up on this ? tia, Serge [..] From man page ld(1) (snv_99 box): -B direct | nodirect These options govern direct binding. -B direct estab- lishes direct binding information by recording the rela- tionship between each symbol reference together with the dependency that provides the definition. In addition, direct binding information is established between each symbol reference and an associated definition within the object being created. The runtime linker uses this information to search directly for a symbol in the asso- ciated object rather than to carry out a default symbol search. Direct binding information can only be established to dependencies specified with the link-edit. Thus, you should use the -z defs option. Objects that wish to interpose on symbols in a direct binding environment should identify themselves as interposers with the -z interpose option. The use of -B direct enables -z lazy- load for all dependencies. The -B nodirect option prevents any direct binding to the interfaces offered by the object being created. The object being created can continue to directly bind to external interfaces by specifying the -z direct option. See Appendix D, Direct Bindings, in Linker and Libraries Guide. . -z interpose Marks the object as an interposer. At runtime, an object is identified as an explicit interposer if the object has been tagged using the -z interpose option. An expli- cit interposer is also established when an object is loaded using the LD_PRELOAD environment variable. Impli- cit interposition can occur because of the load order of objects, however, this implicit interposition is unknown to the runtime linker. Explicit interposition can ensure that interposition takes place regardless of the order in which objects are loaded. Explicit interposition also ensures that the runtime linker searches for symbols in any explicit interposers when direct bindings are in effect. . Could it be the explanation and a possible solution ? Serge Thanks, Serge If it's documented that applications on Solaris may no longer link with their own versions of malloc, that's fine -- I can arrange things so that bash doesn't try to use it's internal malloc on Solaris 10 and 11. Chet
Re: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client
ok, thanks ! Serge On 10/30/08 08:26 PM, Chet Ramey wrote: ah OK, so I guess I need to work on a customized patched for 3.2 then. Any ideas yet of what the exact change will be in configure.bin so that I can apply to same in our deliveries ? *** ../bash-3.2-patched/configure.in2007-12-14 21:12:29.0 -0500 --- configure.in2008-10-23 09:10:57.0 -0400 *** *** 992,997 --- 1009,1017 sco3.2*) LOCAL_CFLAGS=-DMUST_UNBLOCK_CHLD ;; sunos4*) LOCAL_CFLAGS=-DSunOS4 ;; solaris2.5*) LOCAL_CFLAGS="-DSunOS5 -DSOLARIS" ;; + solaris2.8*) LOCAL_CFLAGS=-DSOLARIS LOCAL_LDFLAGS='-z interpose' ;; + solaris2.9*) LOCAL_CFLAGS=-DSOLARIS LOCAL_LDFLAGS='-z interpose' ;; + solaris2.10*) LOCAL_CFLAGS=-DSOLARIS LOCAL_LDFLAGS='-z interpose' ;; solaris2*)LOCAL_CFLAGS=-DSOLARIS ;; lynxos*) LOCAL_CFLAGS=-DRECYCLES_PIDS ;; linux*) LOCAL_LDFLAGS=-rdynamic # allow dynamic loading Also, do you or would you have a bug # for reference ? Sorry, I don't. Chet
Re: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client
Hi Chet, there've been follow-up discussions and reviews here with our linker folks (see [1] for some details on the bug that was open to capture those) and consensus is that best approach is to not compile with bash's own malloc routines. Indeed, ld(1)'s -z interpose option is a rather big hammer, as it establishes that the application can interpose on *all* of the symbols that it offers, rather than just the few related to malloc. Hence, my question to you is: are there any real benefit these days of using bash's own malloc function rather than the one from the system ? or, otherwise said, what do bash lose when it's compiled with option --without-bash-malloc ? TIA, Serge [1] http://bugs.opensolaris.org/view_bug.do?bug_id=6778453 On 10/30/08 08:26 PM, Chet Ramey wrote: ah OK, so I guess I need to work on a customized patched for 3.2 then. Any ideas yet of what the exact change will be in configure.bin so that I can apply to same in our deliveries ? *** ../bash-3.2-patched/configure.in2007-12-14 21:12:29.0 -0500 --- configure.in2008-10-23 09:10:57.0 -0400 *** *** 992,997 --- 1009,1017 sco3.2*) LOCAL_CFLAGS=-DMUST_UNBLOCK_CHLD ;; sunos4*) LOCAL_CFLAGS=-DSunOS4 ;; solaris2.5*) LOCAL_CFLAGS="-DSunOS5 -DSOLARIS" ;; + solaris2.8*) LOCAL_CFLAGS=-DSOLARIS LOCAL_LDFLAGS='-z interpose' ;; + solaris2.9*) LOCAL_CFLAGS=-DSOLARIS LOCAL_LDFLAGS='-z interpose' ;; + solaris2.10*) LOCAL_CFLAGS=-DSOLARIS LOCAL_LDFLAGS='-z interpose' ;; solaris2*)LOCAL_CFLAGS=-DSOLARIS ;; lynxos*) LOCAL_CFLAGS=-DRECYCLES_PIDS ;; linux*) LOCAL_LDFLAGS=-rdynamic # allow dynamic loading Also, do you or would you have a bug # for reference ? Sorry, I don't. Chet
Re: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client
On 12/ 8/08 03:00 PM, Chet Ramey wrote: Serge Dussud wrote: Indeed, ld(1)'s -z interpose option is a rather big hammer, as it establishes that the application can interpose on *all* of the symbols that it offers, rather than just the few related to malloc. That might be a problem if there are some public symbols in libc that bash happens to use, but bash is pretty careful to replace libc functions only if they're missing or somehow substandard. OK. Not sure I am willing to take the risk at this point. Also, note that the linker issue is being investigated at the moment. Hence, my question to you is: are there any real benefit these days of using bash's own malloc function rather than the one from the system ? or, otherwise said, what do bash lose when it's compiled with option --without-bash-malloc ? The bash malloc is a lot faster than the Solaris malloc, and it performs indeed ? OK. Thanks, Serge a lot more checking. Chet
Question about Xterm title
Hello, dear all! I am bash v3.0 user. Often I need to run long-lived foreground tasks and I wish the name of the task with its arguments to be shown in the Xterm title. Much like preexec() function from zsh. I'm very happy with bash, and don't want to change my shell, but I'm badly need this feature. I haven't found any clues in documentation of bash how to achieve this. May be I missed something? Thank you! -- Sincerely yours, Serge ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Question about Xterm title
On Thu, Feb 17, 2005 at 04:12:49PM +0100, Al Elgert wrote: > Hello, > > you can change the title with this command (if the term supports it): > > echo -en "\033]0;--- $HOSTNAME $TERM $$ ---\007" >^^ May be I'm don't explained clearly enough. I need dynamic title, not static. For example, I type: $some_ncurses_appname -arg1 -arg2 And after I pressed enter key I want xterm title changed to: "-=xterm=- myhost.mydomain: some_ncurses_appname -arg1 -arg2". zsh uses preexec() builtin function to accomplish this - a function which is just before a command is executed, and I haven't found any way to do this in bash. Look at http://www.tldp.org/HOWTO/Xterm-Title-6.html if I'm again not described my problem clearly enough. Thank you, and have a nice day. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
[mapfile]: problem reentrance with normal file
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-1ixwpb/bash-4.4=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall -no-pie
-Wno-parentheses -Wno-format-security
uname output: Linux MX36 4.10.0-42-generic #46-Ubuntu SMP Mon Dec 4
14:36:05 UTC 2017 i686 i686 i686 GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 4.4
Patch Level: 7
Release Status: release
Description:
When use mapfile from normal file that call function that use mapfile, the
first mapfile lost data.
Repeat-By:
I create 3 functions:
ww(){ echo "$@" | mapfile -C yy -c 1 -t TT ; }
xx(){ mapfile -C yy -c 1 -t TT < <(echo "$@") ; }
yy(){ echo "$@" ;}
I create 1 normal file:
echo -e "Premiere ligne" A{1..45} "\nDeuxieme ligne" B{1..45} "\nTroisieme
ligne" C{1..45} >fic.txt
This work but I can't use array TT:
mapfile -C ww -c 1 UU
Re: [mapfile]: problem reentrance with normal file
Ok, in this case, this should not work either:
mapfile -C xx -c 1 UU < <( echo -e "Premiere ligne" A{1..45} "\nDeuxieme
ligne" B{1..45} "\nTroisieme ligne" C{1..45})
But, this form work fine.
Le lun. 12 nov. 2018 à 15:44, Chet Ramey a écrit :
> On 11/11/18 3:32 PM, Didou Serge wrote:
>
> > Bash Version: 4.4
> > Patch Level: 7
> > Release Status: release
> >
> > Description:
> > When use mapfile from normal file that call function that use mapfile,
> the
> > first mapfile lost data.
> >
> > Repeat-By:
> > I create 3 functions:
> > ww(){ echo "$@" | mapfile -C yy -c 1 -t TT ; }
> > xx(){ mapfile -C yy -c 1 -t TT < <(echo "$@") ; }
> > yy(){ echo "$@" ;}
> >
> > I create 1 normal file:
> > echo -e "Premiere ligne" A{1..45} "\nDeuxieme ligne" B{1..45}
> "\nTroisieme
> > ligne" C{1..45} >fic.txt
> >
> [...]
> > This not work (lost data in second line and after) :
> > mapfile -C xx -c 1 UU > 0 0 Premiere ligne A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15 A16
> > A17 A18 A19 A20 A21 A22 A23 A24 A25 A26 A27 A28 A29 A30 A31 A32 A33 A34
> A35
> > A36 A37 A38 A39 A40 A41 A42 A43 A44 A45
> > 0 1 B17 B18 B19 B20 B21 B22 B23 B24 B25 B26 B27 B28 B29 B30 B31 B32 B33
> > B34 B35 B36 B37 B38 B39 B40 B41 B42 B43 B44 B45
> > 0 2 ligne C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 C15 C16 C17 C18
> > C19 C20 C21 C22 C23 C24 C25 C26 C27 C28 C29 C30 C31 C32 C33 C34 C35 C36
> C37
> > C38 C39 C40 C41 C42 C43 C44 C45
>
> This is a buffering issue caused by nested calls to mapfile in the same
> process. The first call to mapfile reads a bufferful of data from the
> input file, and the second mapfile (the one executed as part of the
> callback) reads data into that same buffer. When the second call finishes,
> and the first mapfile is called again, the remaining characters in the
> buffer have already been discarded. It's not safe to call mapfile as part
> of a callback to a mapfile invocation.
>
> 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: [mapfile]: problem reentrance with normal file
I tested with another configuration and ALL work fine:
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: cygwin
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='x86_64-unknown-cygwin'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS -I.
-I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4
-I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4/include
-I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4/lib -DWORDEXP_OPTION -ggdb
-O2 -pipe -Wimplicit-function-declaration
-fdebug-prefix-map=/usr/src/bash-4.4.12-3.x86_64/build=/usr/src/debug/bash-4.4.12-3
-fdebug-prefix-map=/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4=/usr/src/debug/bash-4.4.12-3
-Wno-parentheses -Wno-format-security
uname output: CYGWIN_NT-6.1 EB-5CG63201SJ 2.8.0(0.309/5/3) 2017-04-01 20:47
x86_64 Cygwin
Machine Type: x86_64-unknown-cygwin
Bash Version: 4.4
Patch Level: 12
Release Status: release
Le lun. 12 nov. 2018 à 16:48, Didou Serge a écrit :
> Ok, in this case, this should not work either:
>
> mapfile -C xx -c 1 UU < <( echo -e "Premiere ligne" A{1..45} "\nDeuxieme
> ligne" B{1..45} "\nTroisieme ligne" C{1..45})
>
> But, this form work fine.
>
> Le lun. 12 nov. 2018 à 15:44, Chet Ramey a écrit :
>
>> On 11/11/18 3:32 PM, Didou Serge wrote:
>>
>> > Bash Version: 4.4
>> > Patch Level: 7
>> > Release Status: release
>> >
>> > Description:
>> > When use mapfile from normal file that call function that use mapfile,
>> the
>> > first mapfile lost data.
>> >
>> > Repeat-By:
>> > I create 3 functions:
>> > ww(){ echo "$@" | mapfile -C yy -c 1 -t TT ; }
>> > xx(){ mapfile -C yy -c 1 -t TT < <(echo "$@") ; }
>> > yy(){ echo "$@" ;}
>> >
>> > I create 1 normal file:
>> > echo -e "Premiere ligne" A{1..45} "\nDeuxieme ligne" B{1..45}
>> "\nTroisieme
>> > ligne" C{1..45} >fic.txt
>> >
>> [...]
>> > This not work (lost data in second line and after) :
>> > mapfile -C xx -c 1 UU > > 0 0 Premiere ligne A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15
>> A16
>> > A17 A18 A19 A20 A21 A22 A23 A24 A25 A26 A27 A28 A29 A30 A31 A32 A33 A34
>> A35
>> > A36 A37 A38 A39 A40 A41 A42 A43 A44 A45
>> > 0 1 B17 B18 B19 B20 B21 B22 B23 B24 B25 B26 B27 B28 B29 B30 B31 B32 B33
>> > B34 B35 B36 B37 B38 B39 B40 B41 B42 B43 B44 B45
>> > 0 2 ligne C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 C15 C16 C17 C18
>> > C19 C20 C21 C22 C23 C24 C25 C26 C27 C28 C29 C30 C31 C32 C33 C34 C35 C36
>> C37
>> > C38 C39 C40 C41 C42 C43 C44 C45
>>
>> This is a buffering issue caused by nested calls to mapfile in the same
>> process. The first call to mapfile reads a bufferful of data from the
>> input file, and the second mapfile (the one executed as part of the
>> callback) reads data into that same buffer. When the second call finishes,
>> and the first mapfile is called again, the remaining characters in the
>> buffer have already been discarded. It's not safe to call mapfile as part
>> of a callback to a mapfile invocation.
>>
>> 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: [mapfile]: problem reentrance with normal file
But not work under linux...
Le lun. 12 nov. 2018 à 17:00, Didou Serge a écrit :
> I tested with another configuration and ALL work fine:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: cygwin
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='x86_64-unknown-cygwin'
> -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
> -DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS -I.
> -I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4
> -I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4/include
> -I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4/lib -DWORDEXP_OPTION -ggdb
> -O2 -pipe -Wimplicit-function-declaration
> -fdebug-prefix-map=/usr/src/bash-4.4.12-3.x86_64/build=/usr/src/debug/bash-4.4.12-3
> -fdebug-prefix-map=/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4=/usr/src/debug/bash-4.4.12-3
> -Wno-parentheses -Wno-format-security
> uname output: CYGWIN_NT-6.1 EB-5CG63201SJ 2.8.0(0.309/5/3) 2017-04-01
> 20:47 x86_64 Cygwin
> Machine Type: x86_64-unknown-cygwin
>
> Bash Version: 4.4
> Patch Level: 12
> Release Status: release
>
>
>
> Le lun. 12 nov. 2018 à 16:48, Didou Serge a
> écrit :
>
>> Ok, in this case, this should not work either:
>>
>> mapfile -C xx -c 1 UU < <( echo -e "Premiere ligne" A{1..45}
>> "\nDeuxieme ligne" B{1..45} "\nTroisieme ligne" C{1..45})
>>
>> But, this form work fine.
>>
>> Le lun. 12 nov. 2018 à 15:44, Chet Ramey a écrit :
>>
>>> On 11/11/18 3:32 PM, Didou Serge wrote:
>>>
>>> > Bash Version: 4.4
>>> > Patch Level: 7
>>> > Release Status: release
>>> >
>>> > Description:
>>> > When use mapfile from normal file that call function that use mapfile,
>>> the
>>> > first mapfile lost data.
>>> >
>>> > Repeat-By:
>>> > I create 3 functions:
>>> > ww(){ echo "$@" | mapfile -C yy -c 1 -t TT ; }
>>> > xx(){ mapfile -C yy -c 1 -t TT < <(echo "$@") ; }
>>> > yy(){ echo "$@" ;}
>>> >
>>> > I create 1 normal file:
>>> > echo -e "Premiere ligne" A{1..45} "\nDeuxieme ligne" B{1..45}
>>> "\nTroisieme
>>> > ligne" C{1..45} >fic.txt
>>> >
>>> [...]
>>> > This not work (lost data in second line and after) :
>>> > mapfile -C xx -c 1 UU >> > 0 0 Premiere ligne A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15
>>> A16
>>> > A17 A18 A19 A20 A21 A22 A23 A24 A25 A26 A27 A28 A29 A30 A31 A32 A33
>>> A34 A35
>>> > A36 A37 A38 A39 A40 A41 A42 A43 A44 A45
>>> > 0 1 B17 B18 B19 B20 B21 B22 B23 B24 B25 B26 B27 B28 B29 B30 B31 B32
>>> B33
>>> > B34 B35 B36 B37 B38 B39 B40 B41 B42 B43 B44 B45
>>> > 0 2 ligne C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 C15 C16 C17
>>> C18
>>> > C19 C20 C21 C22 C23 C24 C25 C26 C27 C28 C29 C30 C31 C32 C33 C34 C35
>>> C36 C37
>>> > C38 C39 C40 C41 C42 C43 C44 C45
>>>
>>> This is a buffering issue caused by nested calls to mapfile in the same
>>> process. The first call to mapfile reads a bufferful of data from the
>>> input file, and the second mapfile (the one executed as part of the
>>> callback) reads data into that same buffer. When the second call
>>> finishes,
>>> and the first mapfile is called again, the remaining characters in the
>>> buffer have already been discarded. It's not safe to call mapfile as part
>>> of a callback to a mapfile invocation.
>>>
>>> Chet
>>> --
>>> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>>> ``Ars longa, vita brevis'' - Hippocrates
>>> Chet Ramey, UTech, CWRUc...@case.edu
>>> http://tiswww.cwru.edu/~chet/
>>>
>>
Re: [mapfile]: problem reentrance with normal file
Ok, maybe one day we can do it ... Thanks for your clarifications Regards, Serge. Le lun. 12 nov. 2018 à 19:09, Chet Ramey a écrit : > On 11/12/18 12:47 PM, Didou Serge wrote: > > But not work under linux... > > It's probably the difference between using pipes and FIFOs for process > substitution and whether or not the OS makes the underlying file object > seekable. > > -- > ``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/ >
**/ directory wildcards leak file descriptors and memory
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/opt/bash-4.2/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I/opt/readline/include -I. -I./include -I./lib -I/opt/ncurses/include -g -O2 Machine Type: i686-pc-linux-gnu Bash Version: 4.2 Patch Level: 29 Release Status: release Description: If you interrupt the evaluation of **/ wildcard expansion, the file descriptors which were opened will not be closed. Also, memory used will not be released. Repeat-By: ls /**/*.txt # Wait 10 seconds, then press CTRL-C. ls -la /proc/$$/fd/ # To see the memory leak, run 'top' while you do this. The memory # usage will grow, and will not return to normal values when the # operation is interrupted. # I have also seen out of memory and out of file descriptors errors # after waiting for a long time before interrupting the process.
Re: **/ directory wildcards leak file descriptors and memory
On Sat, 23 Jun 2012, Chet Ramey wrote: > On 6/20/12 2:50 PM, Serge van den Boom wrote: > > Bash Version: 4.2 > > Patch Level: 29 > > Release Status: release > > > > Description: > > If you interrupt the evaluation of **/ wildcard expansion, the file > > descriptors which were opened will not be closed. > > Also, memory used will not be released. > > I can't reproduce this: > [...] > > Bash consuming memory is not evidence of a memory leak. The bash malloc > only returns memory to the kernel under certain circumstances; it usually > acts as a cache between the application (bash) and the kernel. You need > to run this using a leak-checking tool like valgrind to determine whether > bash has allocated memory to which it no longer retains a handle. It may be superfluous now, after Andreas' response, but here is some additional information. If you leave the wildcard expansion running for longer, the effect is greater, and out-of-memory errors will be shown when executing a command afterwards: $ echo $BASH_VERSION 4.2.29(1)-release $ echo $$ 16346 $ ls /**/*.txt [after 15 minutes] ^C $ ls bash: fork: Cannot allocate memory bash: fork: Cannot allocate memory bash: fork: Cannot allocate memory [... about 300 more of these ...] bash: fork: Cannot allocate memory bash: fork: Cannot allocate memory bash: fork: Cannot allocate memory bash: cannot make pipe for command substitution: Too many open files [ In a different shell instance (one which is still usable): ] $ ls -fl /proc/16346/fd total 0K dr-x-- 2 svdb users 0 Jun 23 22:44 ./ dr-x-- 6 svdb users 0 Jun 23 22:44 ../ lrwx-- 1 svdb users 64 Jun 23 23:06 0 -> /dev/pts/1 lrwx-- 1 svdb users 64 Jun 23 23:06 1 -> /dev/pts/1 lrwx-- 1 svdb users 64 Jun 23 23:06 2 -> /dev/pts/1 l-wx-- 1 svdb users 64 Jun 23 23:06 3 -> /mnt/hda7/home/svdb/.fluxbox/log lr-x-- 1 svdb users 64 Jun 23 23:06 4 -> // lr-x-- 1 svdb users 64 Jun 23 23:06 5 -> /dev/ lr-x-- 1 svdb users 64 Jun 23 23:06 6 -> /proc/16346/fd/ lr-x-- 1 svdb users 64 Jun 23 23:06 7 -> // lr-x-- 1 svdb users 64 Jun 23 23:06 8 -> /dev/ lr-x-- 1 svdb users 64 Jun 23 23:06 9 -> /proc/16346/fd/ lr-x-- 1 svdb users 64 Jun 23 23:06 10 -> // lr-x-- 1 svdb users 64 Jun 23 23:06 11 -> /dev/ lr-x-- 1 svdb users 64 Jun 23 23:06 12 -> /proc/16346/fd/ lr-x-- 1 svdb users 64 Jun 23 23:06 13 -> // lr-x-- 1 svdb users 64 Jun 23 23:06 14 -> /dev/ lr-x-- 1 svdb users 64 Jun 23 23:06 15 -> /proc/16346/fd/ lr-x-- 1 svdb users 64 Jun 23 23:06 16 -> // lr-x-- 1 svdb users 64 Jun 23 23:06 17 -> /dev/ lr-x-- 1 svdb users 64 Jun 23 23:06 18 -> /proc/16346/fd/ lr-x-- 1 svdb users 64 Jun 23 23:06 19 -> // lr-x-- 1 svdb users 64 Jun 23 23:06 20 -> /dev/ lr-x-- 1 svdb users 64 Jun 23 23:06 21 -> /proc/16346/fd/ lr-x-- 1 svdb users 64 Jun 23 23:06 22 -> // lr-x-- 1 svdb users 64 Jun 23 23:06 23 -> /dev/ lr-x-- 1 svdb users 64 Jun 23 23:06 24 -> /proc/16346/fd/ lr-x-- 1 svdb users 64 Jun 23 23:06 25 -> // lr-x-- 1 svdb users 64 Jun 23 23:06 26 -> /dev/ lr-x-- 1 svdb users 64 Jun 23 23:06 27 -> /proc/16346/fd/ lr-x-- 1 svdb users 64 Jun 23 23:06 28 -> // lr-x-- 1 svdb users 64 Jun 23 23:06 29 -> /dev/ lr-x-- 1 svdb users 64 Jun 23 23:06 30 -> /proc/16346/fd/ lr-x-- 1 svdb users 64 Jun 23 23:06 31 -> // lr-x-- 1 svdb users 64 Jun 23 23:06 32 -> /dev/ lr-x-- 1 svdb users 64 Jun 23 23:06 33 -> /proc/16346/fd/ lr-x-- 1 svdb users 64 Jun 23 23:06 34 -> // lr-x-- 1 svdb users 64 Jun 23 23:06 35 -> /dev/ lr-x-- 1 svdb users 64 Jun 23 23:06 36 -> /proc/16346/fd/ lr-x-- 1 svdb users 64 Jun 23 23:06 37 -> // lr-x-- 1 svdb users 64 Jun 23 23:06 38 -> /dev/ lr-x-- 1 svdb users 64 Jun 23 23:06 39 -> /proc/16346/fd/ lr-x-- 1 svdb users 64 Jun 23 23:06 40 -> // lr-x-- 1 svdb users 64 Jun 23 23:06 41 -> /dev/ lr-x-- 1 svdb users 64 Jun 23 23:06 42 -> /proc/16346/fd/ lr-x-- 1 svdb users 64 Jun 23 23:06 43 -> // lr-x-- 1 svdb users 64 Jun 23 23:06 44 -> /mnt/ lr-x-- 1 svdb users 64 Jun 23 23:06 45 -> /mnt/hda7/ lr-x-- 1 svdb users 64 Jun 23 23:06 46 -> /mnt/hda7/home/ lr-x-- 1 svdb users 64 Jun 23 23:06 47 -> /mnt/hda7/home/svdb/ lr-x-- 1 svdb users 64 Jun 23 23:06 48 -> /mnt/hda7/home/svdb/c/ lr-x-- 1 svdb users 64 Jun 23 23:06 49 -> /mnt/hda7/home/svdb/c/tests/ lr-x-- 1 svdb users 64 Jun 23 23:06 50 -> /mnt/hda7/home/svdb/c/tests/tar/ lr-x-- 1 svdb users 64 Jun 23 23:06 51 -> /mnt/hda7/home/svdb/c/tests/tar/work/ lr-x-- 1 svdb users 64 Jun 23 23:06 52 -> // lr-x-- 1 svdb users 64 Jun 23 23:06 53 -> /mnt/ lr-x-- 1 svdb users 64 Jun 23 23:06 54 -> /mnt/hda7/ lr-x-- 1
Vertical tab on commandline in UTF-8 mode crashes bash.
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: freebsd5.5 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='freebsd5.5' -DCONF_MACHTYPE='i386-unknown-freebsd5.5' -DCONF_VENDOR='unknown' -DLOCALEDIR='/home/svdb/bashtemp/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -I./lib/intl -I/home/svdb/src/bash-3.1/lib/intl -g -O0 uname output: FreeBSD frog.stack.nl 5.5-RELEASE-p1 FreeBSD 5.5-RELEASE-p1 #6: Mon Jun 12 18:16:16 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FROG i386 Machine Type: i386-unknown-freebsd5.5 Bash Version: 3.1 Patch Level: 0 Release Status: release Description: When the LANG environment variable is set to an UTF-8 encoding, giving a command containing a vertical tab character will cause bash to race and eventually crash. This does not happen on all systems; I suspect this has something to do with the locale definitions. It worked on a FreeBSD 5.5 box. On closer investigation it appears the following is happening: parse.y line 2559: while ((character = shell_getc (1)) != EOF && whitespace (character)) will stop at the vertical tab; whitespace() returns false for it. parse.y line 3594: if MBTEST(shellbreak (character)) will see the vertical tab as a word break character; shellbreak() returns true for it. The result is that an empty string is taken as a word and no progress is made. And as for each found word memory is allocated, (parse.y line 3672 and onwards: the_word = (WORD_DESC *)xmalloc (sizeof (WORD_DESC)); the_word->word = (char *)xmalloc (1 + token_index); strcpy (the_word->word, token); ) eventually the process will run out of memory, and it will crash. Repeat-By: On a FreeBSD system: env -i `which bash` --norc -c 'export LANG=en_GB.UTF-8; eval `printf \\\v`' ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bash cores if nscd disabled on Solaris LDAP sasl/gssapi client
Hello bug-bash, please find attached a bashbug report. I am not sure how to follow-up then, could you advise ? Thanks, Serge From: root To: bug-bash@gnu.org Subject: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client Configuration Information [Automatically generated, do not change]: Machine: sparc OS: solaris2.11 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc' -DCONF_OSTYPE='solaris2.11' -DCONF_MACHTYPE='sparc-sun-solaris2.11' -DCONF_VENDOR='sun' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -I./lib/intl -I/share/bld/u/sdussud/workspaces/onnv/sfwNV-clone.1-23961034/usr/src/cmd/bash/bash-3.2/lib/intl -g -O2 uname output: SunOS vertebrae4 5.11 snv_98 sun4u sparc SUNW,UltraAX-i2 Machine Type: sparc-sun-solaris2.11 Bash Version: 3.2 Patch Level: 0 Release Status: release Description: This issue is seen on Solaris 10 or Nevada systems when configrued as Native LDAP name service clients, using sasl/gssapi authentication, also known as per-user credential level. See [1] for more details on the feature. When name service cache daemon, nscd(1M), is not running, all naming lookups are performed by the application itself, in this case bash. But bash core dumps -or loops receiving SEGV without core dumping-, having issues with its malloc/free internal routines as far as I can tell. For the purpose of this bug report, I reproduced the issue on a recent Solaris nevada build (snv_98), with latest bash release: # bash --version GNU bash, version 3.2.25(1)-release (sparc-sun-solaris2.11) Copyright (C) 2005 Free Software Foundation, Inc. # I can provide a gcore of bash while the problem happens. Here are below outputs for pstack, pldd, pmap as well as an truss output extract when the problem occurs, here when doing a getpwuid(3C) call: core 'core.17747' of 17747: bash ff137068 sigacthandler (efe08, f706, 0, f8ca0, 0, 0) --- called from signal handler with signal 982536 (SIG Unknown) --- ff0e62a4 cleanfree (0, 8, ff1e64f8, ff1de63c, f83ec, 2) + 58 ff0e53d8 _malloc_unlocked (20, f7065554, efe00, f706, ff1e0468, ffdf) + 104 ff0e52b8 malloc (20, 0, 1, ff1de63c, f93c8, ff1e4864) + 48 feb1d5f8 get_bigint_attr_from_template (f9d28, ffbfc400, f3848, 6c174, ffbfc400, ffbfc400) + 24 feb1fe78 soft_build_secret_key_object (0, f3848, 0, 2d70, 0, 1f) + 3bc feb20e9c soft_build_object (ffbfc3c4, 6, f4e08, , 0, f4f81) + 11c feb2546c soft_add_object (ffbfc3c4, 6, f36dc, f3108, f4e08, f3108) + 2c feb17c5c C_CreateObject (f3108, ffbfc3c4, 6, f36dc, 72414, 0) + 74 fe9b5ddc init_key_uef (f3108, f36c8, 4553, fea3a798, fea36000, 4798) + 11c fe9b4d2c krb5_c_make_random_key (f1808, 12, f36c8, 0, f3808, fea390d8) + 14c fe9f19d0 krb5_generate_subkey (f1808, f9f94, f9f20, 0, ea338, b9dd8) + 34 fe9f4724 krb5int_generate_and_save_subkey (f1808, f9f08, f9f94, ffbfc638, f368c, 13a) + 28 fe9f4958 krb5_mk_req_extended (f1808, f3360, 2001, f9f88, f9f94, ffbfc680) + 1c8 fe9a5090 make_ap_req_v1 (f1808, f3308, f9b88, f9f88, 11, fecf6450) + 130 fe9a55c0 new_connection (ffbfc934, f9b88, ebf6c, 0, fecf6450, d) + 270 fe9a5f84 krb5_gss_init_sec_context (ffbfc934, 0, ebf6c, f9948, fecf6450, 3a) + 3a8 fe9a2bb4 k5glue_init_sec_context (ffbfc940, 0, 0, 0, f9948, 0) + 50 feca4a44 gss_init_sec_context (ebf68, 0, f840c, ebd28, d, 3a) + 1e8 fece32ec gssapi_client_mech_step (f8408, f8008, 0, , fecbeab4, ffbfcab0) + 520 fed373dc sasl_client_step (f2008, 0, 0, ffbfcabc, ffbfcab0, ffbfcaa8) + 104 fed372a8 sasl_client_start (f2008, 1, ffbfcabc, ffbfcab0, ffbfcab0, ffbfcab4) + 4c8 fef37374 nsldapi_sasl_do_bind (f1408, ffbfcab4, fefa2984, 1, fef998e8, ffbfcb94) + 14c fef37af4 ldap_sasl_interactive_bind_s (f1408, 0, fefa2984, 0, 0, fef998e8) + 1f0 fef8e470 doSASLBind (0, f1408, fef998e8, eed4c, ffbfcb94, 1) + 584 fef8c878 openConnection (ffbfe468, 0, ec488, 32, eed4c, 1) + 1e8 fef8bcd4 makeConnection (fefb9388, ec388, 1, eb3a8, fefb9384, eed4c) + 428 fef8d22c getConnection (0, 0, eb2a8, ffbfede4, 0, eed4c) + 5a4 fef8d384 __s_api_getConnection (0, 0, 0, ffbfede4, 1, eed4c) + 30 fef80040 get_current_session (eed08, 0, c, , 4, fef80c38) + 40 fef80f1c search_state_machine (eed08, eed80, 0, ff3c, fefb6000, 1) + 288 fef82150 ldap_list (0, fefe10ac, eed08, fefdc870, fefe0c2c, 0) + 2bc fef8225c __ns_ldap_list (fefe10ac, ffbff940, fefdc870, fefe0c2c, 0, 0) + 84 fefdbe80 _nss_ldap_lookup (ec288, ffbffb18, fefe10ac, ffbff940, ffbff7dc, fefdc870) + 40 fefda11c getbyuid (ec288, ffbffb18, ffbffb2c, 5f68, fefe, ffbff840) + 88 ff0edb00 nss_search (1, ff1e0570, 5, ffbffb18, ff300240, ff1e76f0) + 1f4 ff0da480 getpwuid_r (1869f, f0014, f0038, 400, ff0da8d4, 104208)
Re: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client
ch_krb5.so #5 0xfe9a55c8 in new_connection () from /usr/lib/gss/mech_krb5.so #6 0xfe9a5f8c in krb5_gss_init_sec_context () from /usr/lib/gss/mech_krb5.so #7 0xfe9a2bbc in k5glue_init_sec_context () from /usr/lib/gss/mech_krb5.so #8 0xfec84a4c in gss_init_sec_context () from /usr/lib/libgss.so.1 #9 0xfecc32f4 in gssapi_client_mech_step () from /usr/lib/sasl/gssapi.so.1 #10 0xfed173e4 in sasl_client_step () from /usr/lib/libsasl.so.1 #11 0xfed172b0 in sasl_client_start () from /usr/lib/libsasl.so.1 #12 0xfef1737c in nsldapi_sasl_do_bind () from /usr/lib/libldap.so.5 #13 0xfef17afc in ldap_sasl_interactive_bind_s () from /usr/lib/libldap.so.5 #14 0xfef6e478 in doSASLBind () from /usr/lib/libsldap.so.1 #15 0xfef6c880 in openConnection () from /usr/lib/libsldap.so.1 #16 0xfef6bcdc in makeConnection () from /usr/lib/libsldap.so.1 #17 0xfef6d234 in getConnection () from /usr/lib/libsldap.so.1 #18 0xfef6d38c in __s_api_getConnection () from /usr/lib/libsldap.so.1 #19 0xfef60048 in get_current_session () from /usr/lib/libsldap.so.1 #20 0xfef60f24 in search_state_machine () from /usr/lib/libsldap.so.1 #21 0xfef62158 in ldap_list () from /usr/lib/libsldap.so.1 #22 0xfef62264 in __ns_ldap_list () from /usr/lib/libsldap.so.1 #23 0xfefbbe88 in _nss_ldap_lookup () from /usr/lib/nss_ldap.so.1 #24 0xfefba124 in getbyuid () from /usr/lib/nss_ldap.so.1 #25 0xff0edb08 in nss_search () from /lib/libc.so.1 #26 0xff0da488 in getpwuid_r () from /lib/libc.so.1 #27 0x00030e68 in get_current_user_info () #28 0x000310a8 in shell_initialize () #29 0x0002f158 in main () (gdb) clear malloc Deleted breakpoint 4 (gdb) continue Continuing. Breakpoint 3, 0xfea9fac0 in soft_build_secret_key_object () from /usr/lib/security/pkcs11_softtoken.so (gdb) clear soft_build_secret_key_object Deleted breakpoint 3 (gdb) continue Continuing. bash-3.2$(gdb) clear malloc Deleted breakpoint 4 (gdb) continue Continuing. Breakpoint 3, 0xfea9fac0 in soft_build_secret_key_object () from /usr/lib/security/pkcs11_softtoken.so (gdb) clear soft_build_secret_key_object Deleted breakpoint 3 (gdb) continue Continuing. bash-3.2$ From man page ld(1) (snv_99 box): -B direct | nodirect These options govern direct binding. -B direct estab- lishes direct binding information by recording the rela- tionship between each symbol reference together with the dependency that provides the definition. In addition, direct binding information is established between each symbol reference and an associated definition within the object being created. The runtime linker uses this information to search directly for a symbol in the asso- ciated object rather than to carry out a default symbol search. Direct binding information can only be established to dependencies specified with the link-edit. Thus, you should use the -z defs option. Objects that wish to interpose on symbols in a direct binding environment should identify themselves as interposers with the -z interpose option. The use of -B direct enables -z lazy- load for all dependencies. The -B nodirect option prevents any direct binding to the interfaces offered by the object being created. The object being created can continue to directly bind to external interfaces by specifying the -z direct option. See Appendix D, Direct Bindings, in Linker and Libraries Guide. . -z interpose Marks the object as an interposer. At runtime, an object is identified as an explicit interposer if the object has been tagged using the -z interpose option. An expli- cit interposer is also established when an object is loaded using the LD_PRELOAD environment variable. Impli- cit interposition can occur because of the load order of objects, however, this implicit interposition is unknown to the runtime linker. Explicit interposition can ensure that interposition takes place regardless of the order in which objects are loaded. Explicit interposition also ensures that the runtime linker searches for symbols in any explicit interposers when direct bindings are in effect. . Could it be the explanation and a possible solution ? Serge Thanks, Serge If it's documented that applications on Solaris may no longer link with their own versions of malloc, that's fine -- I can arrange things so that bash doesn't try to use it's internal malloc on Solaris 10 and 11. Chet
Re: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client
Chet Ramey wrote: Serge Dussud - Sun Microsystems wrote: -z interpose . Could it be the explanation and a possible solution ? Well, let's try it. OK, great. Shall I understand that you're going to make a patch for this, or is there something else ? Serge Chet
Re: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client
Chet Ramey wrote: Serge Dussud - Sun Microsystems wrote: Chet Ramey wrote: Serge Dussud - Sun Microsystems wrote: -z interpose . Could it be the explanation and a possible solution ? Well, let's try it. OK, great. Shall I understand that you're going to make a patch for this, or is there something else ? I was not going to issue a patch to 3.2 for this, but the change to configure.in will be in the next release. ah OK, so I guess I need to work on a customized patched for 3.2 then. Any ideas yet of what the exact change will be in configure.bin so that I can apply to same in our deliveries ? Also, do you or would you have a bug # for reference ? TIA, Serge Chget
write() not retried after EINTR in printf and echo
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-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/opt/bash-4.4.12/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g
-O2 -Wno-parentheses -Wno-format-security
uname output: Linux test 4.4.0-98-generic #121-Ubuntu SMP Tue Oct 10 14:24:03
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.4
Patch Level: 12
Release Status: release
Description:
If during an 'echo' or 'printf', the write() system call returns an
EINTR error, the write() call is not retried.
This can can happen when a system call is interrupted when a
signal is received, which can happen when the user resized the
terminal while the write() call is blocked.
As a consequence, the intended output of 'echo' or 'printf' will be
missing.
Repeat-By:
1. Run the following command in a terminal (at least xterm works):
while :; do builtin echo foo; done | sleep 100
2. Wait a few seconds
3. Resize the terminal (try again if this does not work immediately)
This will send a 'SIGWINCH' signal to bash. (You can also send
it manually.)
4. "bash: echo: write error: Interrupted system call" will appear.
The same thing happens with 'printf' instead of 'echo'. There may be
other bash functionality which suffers from this.
The pipe, the 'sleep 100', and the waiting in step 2, are to fill up
the buffer of the pipe, so that the call to write() will block.
To see that data is actually omitted from the output (and that this
is not only a warning), you could run something like this instead
of step 1:
I=0
while :; do
builtin echo "$I"
I=$(($I + 1))
done | { sleep 5; cat > /tmp/test; }
Trigger the sending of the signal in the first 5 seconds, and then let
it run for a few seconds after. Inspecting /tmp/test will show that
certain numbers in the sequence are missing.
Fix:
I have not examined the actual Bash code, but typically, code
which causes such a problem will look like this:
int writeResult = write(fd, buf, toWrite);
if (writeResult == -1) {
perror("write");
// Handle error here.
}
It should be replaced by something like:
const char *bufPtr = buf;
int leftToWrite = toWrite;
while (leftToWrite > 0) {
int writeResult = write(fd, bufPtr, leftToWrite);
if (writeResult == -1) {
if (errno == EINTR)
continue;
perror("write");
// Handle error here.
}
leftToWrite -= writeResult;
bufPtr += writeResult;
}
