On Thu, Feb 08, 2018 at 05:51:06PM -0800, Nolan wrote:
> On 02/08/2018 05:04 PM, Eduardo Bustamante wrote:
> > On Thu, Feb 8, 2018 at 4:23 PM, Nolan <4030...@gmail.com> wrote:
> > > I have found a 'result' of a command that cannot be a feature.
> > >
> > > Enter command, command executes, prints e
Configuration Information:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I
On 2/9/18 9:55 AM, mike b wrote:
> Bash Version: 4.3
> Patch Level: 33
> Release Status: release
>
> Description:
> On the system which doesn't provide any locale (other than default, POSIX
> one), Bash is hit with a segfault after the following is executed (I fork
> into another Bash instance so
Core was generated by `bash'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __gconv_close (cd=0x0) at gconv_close.c:35
35gconv_close.c: No such file or directory.
(gdb) bt
#0 __gconv_close (cd=0x0) at gconv_close.c:35
#1 0x7fbf1e17a59f in iconv_close (cd=) at
iconv_close
On 2/9/18 11:21 AM, mike b wrote:
> Core was generated by `bash'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 __gconv_close (cd=0x0) at gconv_close.c:35
> 35 gconv_close.c: No such file or directory.
> (gdb) bt
> #0 __gconv_close (cd=0x0) at gconv_close.c:35
> #1 0x
Indeed, with build from devel it doesn't segfault anymore. Just out of pure
curiosity, which commit introduced a fix for that? Aaand, there's one more
thing that puzzles me a bit:
# echo $BASH_VERSION
5.0.12(1)-alpha
# echo ${LANG:-bleh}
bleh
# LANG=UTF-8
# printf '%s\n' $'\u013b'
Ļ
# unset LANG
#
On 2/9/18 11:53 AM, mike b wrote:
> Indeed, with build from devel it doesn't segfault anymore. Just out of pure
> curiosity, which commit introduced a fix for that?
If the change that I think fix it actually did, it's
5af34ee8a345b6ae2ee097855351e8c317e9d209
http://git.savannah.gnu.org/
On 2/7/18 3:30 PM, Chet Ramey wrote:
>> Unfortunately, the proposed patch does not fix the case for 32 bit
>> architectures.
>
> That's interesting. It seems to me that the kernel should reject attempts
> to set the maximum number of processes larger than 2**(sizeof (pid_t)).
I looked at this on
On 02/09/2018 05:54 AM, Eduardo A. Bustamante López wrote:
On Thu, Feb 08, 2018 at 05:51:06PM -0800, Nolan wrote:
On 02/08/2018 05:04 PM, Eduardo Bustamante wrote:
On Thu, Feb 8, 2018 at 4:23 PM, Nolan <4030...@gmail.com> wrote:
I have found a 'result' of a command that cannot be a feature.
E
