Re: Bash patches format
On 2018-05-30 09:04, Marty E. Plummer wrote: > Maintainers, I'd really like to hear your thoughts on this matter. If > the diffs are produced as -p1 unified diffs, then downstreams who do > convert from -p0 context won't have to, and distros who work around it > won't either. Speaking as maintainer of bash in MacPorts, I never had problems with the format of the bash patches. I have no preference whether patches need -p0 or -p1, as long as all patches are published with the same level. I think unified diffs are more common than context diffs these days. However, as long as the bash patches can be applied cleanly with patch(1), I see no reason to change anything. Rainer
Re: login shell crash on Mac OS X while closing file descriptors
On 2010-08-24 15:59 , Chet Ramey wrote: Well, if they cause bash to crash, I suppose removing that code (or removing the #define) is a good place to start. That code has been there for a very long time. Maybe if you changed it to turn on the FD_CLOEXEC bit instead of closing the fd we could solve the problem. There is a SET_CLOSE_ON_EXEC(fd) macro you can use to do that. I now applied a patch locally which replaces close() with SET_CLOSE_ONEXEC(). Resolves the problem for me and is probably a better solution than removing the code completely. Thanks, Rainer
login shell crash on Mac OS X while closing file descriptors
Hi,
I am the maintainer of bash in MacPorts, a package management system for
Mac OS X. I am currently debugging crashes with bash 4.1.7 when being
run as a login shell under certain conditions. The original report was
here: http://trac.macports.org/ticket/25693
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: darwin10.4.0
Compiler: /usr/bin/gcc-4.2
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='darwin10.4.0' -DCONF_MACHTYPE='i386-apple-darwin10.4.0'
-DCONF_VENDOR='apple' -DLOCALEDIR='/opt/local/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DMACOSX -I. -I. -I./include
-I./lib -I/opt/local/include -pipe -O2 -arch x86_64
uname output: Darwin Dysnomia.local 10.4.0 Darwin Kernel Version 10.4.0:
Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386
Machine Type: i386-apple-darwin10.4.0
Bash Version: 4.1
Patch Level: 7
Release Status: release
I cannot reproduce this very good, but it happens for me now with
iTerm.app and '/opt/local/bin/bash -l' as command. A crash report is
attached to this message.
The important part of this report is:
BUG IN CLIENT OF LIBDISPATCH: Do not close random Unix descriptors
I tracked this down to the shell initialization in the main function,
where bash closes any open file descriptors in the range from 3 to 19.
Apparently this causes problems with libdispatch, Apple's threading
library, as it works fine if I comment this section out.
This is the code in question:
| #define CLOSE_FDS_AT_LOGIN
| #if defined (CLOSE_FDS_AT_LOGIN)
| /*
|* Some systems have the bad habit of starting login shells with
lots of open
|* file descriptors. For instance, most systems that have picked up the
|* pre-4.0 Sun YP code leave a file descriptor open each time you
call one
|* of the getpw* functions, and it's set to be open across execs. That
|* means one for login, one for xterm, one for shelltool, etc.
|*/
| if (login_shell interactive_shell)
| {
| for (i = 3; i 20; i++)
| close (i);
| }
| #endif /* CLOSE_FDS_AT_LOGIN */
I am not sure how to proceed so I am asking for advice. Should I just
remove this code with a patch and let bash ignore any open file
descriptors? Would that be bad? Any other ideas?
Rainer
Process: bash [418]
Path:/opt/local/bin/bash
Identifier: bash
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: ??? [417]
Date/Time: 2010-08-20 19:34:27.967 +0200
OS Version: Mac OS X 10.6.4 (10F569)
Report Version: 6
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0001, 0x
Crashed Thread: 1 Dispatch queue: com.apple.libdispatch-manager
Application Specific Information:
BUG IN CLIENT OF LIBDISPATCH: Do not close random Unix descriptors
Thread 0: Dispatch queue: com.apple.main-thread
0 libSystem.B.dylib 0x7fff8439d8e6 read + 10
1 bash0x000100054754 _evalfile + 996
2 bash0x000100054bd1 maybe_execute_file +
49
3 bash0x00011638 run_startup_files +
568
4 bash0x000131a8 main + 4264
5 bash0x00011054 start + 52
Thread 1 Crashed: Dispatch queue: com.apple.libdispatch-manager
0 libSystem.B.dylib 0x7fff843ae1b0 _dispatch_mgr_invoke
+ 749
1 libSystem.B.dylib 0x7fff843adc34
_dispatch_queue_invoke + 185
2 libSystem.B.dylib 0x7fff843ad75e
_dispatch_worker_thread2 + 252
3 libSystem.B.dylib 0x7fff843ad088 _pthread_wqthread +
353
4 libSystem.B.dylib 0x7fff843acf25 start_wqthread + 13
Thread 2:
0 libSystem.B.dylib 0x7fff843aceaa __workq_kernreturn +
10
1 libSystem.B.dylib 0x7fff843ad2bc _pthread_wqthread +
917
2 libSystem.B.dylib 0x7fff843acf25 start_wqthread + 13
Thread 1 crashed with X86 Thread State (64-bit):
rax: 0x0009 rbx: 0x rcx: 0x7fff844e9840
rdx: 0x
rdi: 0x0009 rsi: 0x rbp: 0x0001002f4e90
rsp: 0x0001002f4cf0
r8: 0x0001 r9: 0x0001002f4e50 r10: 0x0001002f4e20
r11: 0x7fff708714b8
r12: 0x7fff70859978 r13: 0x7fff70859d48 r14: 0x
r15: 0x7fff70859d88
rip: 0x7fff843ae1b0 rfl: 0x00010246 cr2: 0x000100039970
Binary Images:
0x1 -0x100099fe7 +bash ??? (???)
1E9C0EAD-E5A5-B773-3E66-EE7B5417FF24 /opt/local/bin/bash
0x1000bf000 -0x1000e9ff7 +libncurses.5.dylib 5.0.0
(compatibility 5.0.0) 9829BCEB-0A54-5FA7-788E-0F0593301164
/opt/local/lib/libncurses.5.dylib
0x1000f5000 -0x10011dff7
login shell crash on Mac OS X while closing file descriptors
Hi,
I am the maintainer of bash in MacPorts, a package management system for
Mac OS X. I am currently debugging crashes with bash 4.1.7 when being
run as a login shell under certain conditions. The original report was
here: http://trac.macports.org/ticket/25693
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: darwin10.4.0
Compiler: /usr/bin/gcc-4.2
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='darwin10.4.0' -DCONF_MACHTYPE='i386-apple-darwin10.4.0'
-DCONF_VENDOR='apple' -DLOCALEDIR='/opt/local/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DMACOSX -I. -I. -I./include
-I./lib -I/opt/local/include -pipe -O2 -arch x86_64
uname output: Darwin Dysnomia.local 10.4.0 Darwin Kernel Version 10.4.0:
Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386
Machine Type: i386-apple-darwin10.4.0
Bash Version: 4.1
Patch Level: 7
Release Status: release
I cannot reproduce this very good, but it happens for me now with
iTerm.app and '/opt/local/bin/bash -l' as command.
The important part of the crash report attached to the ticket above is:
| Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
| Exception Codes: 0x0001, 0x
| Crashed Thread: 1 Dispatch queue: com.apple.libdispatch-manager
|
| Application Specific Information:
| BUG IN CLIENT OF LIBDISPATCH: Do not close random Unix descriptors
I tracked this down to the shell initialization in the main function,
where bash closes any open file descriptors in the range from 3 to 19.
Apparently this causes problems with libdispatch, Apple's threading
library, as it works fine if I comment this section out.
This is the code in question:
| #define CLOSE_FDS_AT_LOGIN
| #if defined (CLOSE_FDS_AT_LOGIN)
| /*
|* Some systems have the bad habit of starting login shells with
lots of open
|* file descriptors. For instance, most systems that have picked up the
|* pre-4.0 Sun YP code leave a file descriptor open each time you
call one
|* of the getpw* functions, and it's set to be open across execs. That
|* means one for login, one for xterm, one for shelltool, etc.
|*/
| if (login_shell interactive_shell)
| {
| for (i = 3; i 20; i++)
| close (i);
| }
| #endif /* CLOSE_FDS_AT_LOGIN */
I am not sure how to proceed so I am asking for advice. Should I just
remove this code with a patch and let bash ignore any open file
descriptors? Would that be bad? Any other ideas?
Rainer
Re: free: called with unallocated block argument
Chet Ramey wrote: p...@arcturus.universe wrote: Bash Version: 4.0 Patch Level: 0 Release Status: release Description: Problem with auto completion : ls[space][TAB] gives the follwing abort : malloc: /Users/chet/src/bash/src/parse.y:5561: assertion botched free: called with unallocated block argument last command: ls Aborting...Abandon If /etc/bash_completion is suppressed, problem disapears. My bash_completion is : $Id: bash_completion,v 1.872 2006/03/01 16:20:18 ianmacd Exp $ Repeat-By: ls[space] [TAB] or cd[space][TAB] and several other commands. My fault; I dropped a line from a submitted patch. The attached patch corrects it for me; see if it works for you. Had the same problem with bash 4.0 when using bash-completion, your attached patch fixed it. Thanks. Rainer
