Re: core dump an alt. alt1 alt.
On Tue, Jun 09, 2020 at 11:46:22AM -0400, Chet Ramey wrote: > > In any event, I believe the changes in the next devel branch push should > fix these. Thanks Chet, that explanation made sense. If i can find the time I will try to test the devel branch. Regards, -- Mike Jonkmans
Re: core dump an alt. alt1 alt.
On 6/9/20 5:19 AM, Mike Jonkmans wrote: > On Mon, Jun 08, 2020 at 08:43:31PM -0400, Chet Ramey wrote: >> >> On 6/8/20 6:54 PM, bash...@jonkmans.nl wrote: >> >>> Bash Version: 4.4 >>> Patch Level: 20 >>> Release Status: release >>> >>> Description: >>> Got a core dump (segmentation fault) when i type: Alt-. Alt-1 Alt-. >> >> You tried to redo `.'. The way this happens is you are in command mode, >> run that yank-last-arg binding (which sets the last vi-mode command to >> `.'), then try to run it again, but miss the timeout described in the last >> paragraph of my previous message, which results in you trying to redo the >> last command (`.') in a context where the binding for `.' is vi-redo. I put >> something in to stop that at the same time I made the other changes >> described in my previous message. > > The problem from the previous message was the trigger to try this. :) I figured. > > Are you sure that it is a timeout problem in this case? > Because if I prepend the followong line to the inputrc: > set keyseq-timeout 0 > the core dump is also generated. It's the same phenomenon. Redoing `.' is what triggers it, but there are a couple of issues here. In vi-mode, without the changes I made, the yank-last-arg puts you into insert mode (like the vi-mode `_' command). The `.' is the last command executed. > > It seems i enter command mode after I press Alt-1. You do. This all presumes that the Alt is converted into ESC by the terminal. The ESC puts you into command mode, and the 1 starts a digit argument. Here's what I think happens: > The following Alt-. probably gets split into Alt(Escape) and a '.' > The Escape breaks off the Alt-1 'mode' and then the '.' becomes vi-redo. > But I fail to see why the vi-redo is bound to vi-redo here. :( That's where it's ambiguous. You have two key sequences, both bound to commands, one of which (ESC) is a prefix of the other (ESC-.). If you set the keyboard timeout to 0, it takes the ESC as a separate key sequence, which is unbound in vi command mode, and reads the `.', which is bound to vi-redo. The last command in vi mode was `.', which vi-redo attempts to redo given the current keymap, which has it bound to vi-redo, and off you go. It may also do this because the ESC gets pushed back on the input stream after breaking out of the digit loop, but I kind of doubt that. In any event, I believe the changes in the next devel branch push should fix these. 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: core dump an alt. alt1 alt.
On Mon, Jun 08, 2020 at 08:43:31PM -0400, Chet Ramey wrote: > > On 6/8/20 6:54 PM, bash...@jonkmans.nl wrote: > > > Bash Version: 4.4 > > Patch Level: 20 > > Release Status: release > > > > Description: > > Got a core dump (segmentation fault) when i type: Alt-. Alt-1 Alt-. > > You tried to redo `.'. The way this happens is you are in command mode, > run that yank-last-arg binding (which sets the last vi-mode command to > `.'), then try to run it again, but miss the timeout described in the last > paragraph of my previous message, which results in you trying to redo the > last command (`.') in a context where the binding for `.' is vi-redo. I put > something in to stop that at the same time I made the other changes > described in my previous message. The problem from the previous message was the trigger to try this. :) Are you sure that it is a timeout problem in this case? Because if I prepend the followong line to the inputrc: set keyseq-timeout 0 the core dump is also generated. It seems i enter command mode after I press Alt-1. The following Alt-. probably gets split into Alt(Escape) and a '.' The Escape breaks off the Alt-1 'mode' and then the '.' becomes vi-redo. But I fail to see why the vi-redo is bound to vi-redo here. :( With this inputrc: set keyseq-timeout 0 set editing-mode vi set keymap vi-command set show-mode-in-prompt on set vi-ins-mode-string "+ " set vi-cmd-mode-string ": " "\e.": yank-last-arg set keymap vi-insert "\e.": yank-last-arg Another, maybe clearer case, typing: Alt-. Esc . a core dump is also generated. My expectation would be that: - Alt-. insert text - Esc goes to vi-command mode - . does vi-redo, which is, insert the same text as Alt-. did Regards, -- Mike Jonkmans
Re: core dump an alt. alt1 alt.
On 6/8/20 6:54 PM, bash...@jonkmans.nl wrote: > Bash Version: 4.4 > Patch Level: 20 > Release Status: release > > Description: > Got a core dump (segmentation fault) when i type: Alt-. Alt-1 Alt-. You tried to redo `.'. The way this happens is you are in command mode, run that yank-last-arg binding (which sets the last vi-mode command to `.'), then try to run it again, but miss the timeout described in the last paragraph of my previous message, which results in you trying to redo the last command (`.') in a context where the binding for `.' is vi-redo. I put something in to stop that at the same time I made the other changes described in my previous message. -- ``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: Core dump
> > array_to_key() {
> ># Converts 1 2 3 -> 1,2,3, (comma at the end)
> >printf '%d,' "$@"
> > }
> >
> > multi_store() {
> >local array_name="$1"; shift
> >local value="$1"; shift
> >if unset -v "$array_name"; then
> > declare -A $array_name
> > declare -- $array_name[$(array_to_key "$@")]="$value"
> >fi
> > }
> >
> > multi_store CHESS_3D queen 2 2 5
>
> Bash version? This was fixed before bash-4.3 was released.
Oh, I thought originally it's latest stable, but on second look that
machine was not updated yet. So both Solaris and linux older that 4.3.
I'm sorry for the noise
--
Vlad
Re: Core dump
On 4/27/17 3:56 PM, Vladimir Marek wrote:
> array_to_key() {
># Converts 1 2 3 -> 1,2,3, (comma at the end)
>printf '%d,' "$@"
> }
>
> multi_store() {
>local array_name="$1"; shift
>local value="$1"; shift
>if unset -v "$array_name"; then
> declare -A $array_name
> declare -- $array_name[$(array_to_key "$@")]="$value"
>fi
> }
>
> multi_store CHESS_3D queen 2 2 5
Bash version? This was fixed before bash-4.3 was released.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: core dump on SIGHUP
This problem can be fixed by applying part of the update from 2.05a to 2.05b
in
lib/malloc/malloc.c. The relevent sections are as follows:
--- bash-2.05a.orig/lib/malloc/malloc.c 2001-10-04 12:13:16.0 +
+++ bash-2.05a/lib/malloc/malloc.c 2005-06-14 17:19:00.0 +
@@ -202,9 +202,16 @@
#define ERR_ASSERT_FAILED 0x08
/* Evaluates to true if NB is appropriate for bucket NU. NB is adjusted
- appropriately by the caller to account for malloc overhead. */
-#define IN_BUCKET(nb, nu) \
- ((nb) (4 (nu)) ((nb) = (8 (nu
+ appropriately by the caller to account for malloc overhead. This only
+ checks that the recorded size is not too big for the bucket. We
+ can't check whether or not it's in between NU and NU-1 because we
+ might have encountered a busy bucket when allocating and moved up to
+ the next size.*/
+#define IN_BUCKET(nb, nu) ((nb) = binsizes[(nu)])
+
+/* Use this when we want to be sure that NB is in bucket NU. */
+#define RIGHT_BUCKET(nb, nu) \
+(((nb) binsizes[(nu)-1]) ((nb) = binsizes[(nu)]))
/* nextf[i] is free list of blocks of size 2**(i + 3) */
@@ -218,6 +225,17 @@
static int pagebucket; /* bucket for requests a page in size */
static int maxbuck;/* highest bucket receiving allocation request. */
+static unsigned long binsizes[NBUCKETS] = {
+ 8UL, 16UL, 32UL, 64UL, 128UL, 256UL, 512UL, 1024UL, 2048UL, 4096UL,
+ 8192UL, 16384UL, 32768UL, 65536UL, 131072UL, 262144UL, 524288UL,
+ 1048576UL, 2097152UL, 4194304UL, 8388608UL, 16777216UL, 33554432UL,
+ 67108864UL, 134217728UL, 268435456UL, 536870912UL, 1073741824UL,
+ 2147483648UL, 4294967295UL
+};
+
+/* binsizes[x] == (1 ((x) + 3)) */
+#define binsize(x) binsizes[(x)]
+
/* Declarations for internal functions */
static PTR_T internal_malloc __P((size_t, const char *, int, int));
static PTR_T internal_realloc __P((PTR_T, size_t, const char *, int, int));
@@ -753,8 +771,10 @@
We sanity-check the value of mh_nbytes against the size of the blocks
in the appropriate bucket before we use it. This can still cause
problems
and obscure errors if mh_nbytes is wrong but still within range; the
- checks against MAGIC1 will probably fail then. Using MALLOC_REGISTER
- will help here, since it saves the original number of bytes requested.
*/
+ checks against the size recorded at the end of the chunk will probably
+ fail then. Using MALLOC_REGISTER will help here, since it saves the
+ original number of bytes requested. */
+
if (IN_BUCKET(nbytes, nunits) == 0)
xbotch (mem, ERR_UNDERFLOW,
free: underflow detected; mh_nbytes out of range, file, line);
@@ -837,8 +857,9 @@
We sanity-check the value of mh_nbytes against the size of the blocks
in the appropriate bucket before we use it. This can still cause
problems
and obscure errors if mh_nbytes is wrong but still within range; the
- checks against MAGIC1 will probably fail then. Using MALLOC_REGISTER
- will help here, since it saves the original number of bytes requested.
*/
+ checks against the size recorded at the end of the chunk will probably
+ fail then. Using MALLOC_REGISTER will help here, since it saves the
+ original number of bytes requested. */
if (IN_BUCKET(nbytes, nunits) == 0)
xbotch (mem, ERR_UNDERFLOW,
realloc: underflow detected; mh_nbytes out of range, file, line);
@@ -851,7 +872,7 @@
nbytes = ALLOCATED_BYTES(n);
/* If ok, use the same block, just marking its size as changed. */
- if (IN_BUCKET(nbytes, nunits))
+ if (RIGHT_BUCKET(nbytes, nunits))
{
m = (char *)mem + tocopy;
*m++ = 0; *m++ = 0; *m++ = 0; *m++ = 0;
---
Tom Robinson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
...
I have seen bash dump core a few times. It is extremely difficult to
reproduce naturally.
The problem occurs when a SIGHUP is received during a malloc by bash.
After examining
the backtrace of the core, I am able to reproduce the problem using gbd.
I have been able to
reproduce this on a number of different platforms. After the SIGHUP, bash
calls a handler
to clean up, write the history, etc. But it calls free() from
history_do_write() which in turn
calls internal_free() where the problem occurs. There is a comment right
before the xbotch()
but I can't tell if that is relevant here.
Any help on this would be appreciated.
Repeat-By:
# gdb bash
:
(gdb) break decode_prompt_string
Breakpoint 1 at 0x80600e0: file parse.y, line 3667.
(gdb) r
Starting program: bash
Breakpoint 1, decode_prompt_string (string=0x10b Address 0x10b out of
bounds)
at parse.y:3667
3667 result = (char *)xmalloc (result_size = PROMPT_GROWTH);
(gdb) c
Continuing.
[EMAIL PROTECTED] bin]# ulimit -c 10
Breakpoint 1, decode_prompt_string (string=0x10b Address 0x10b out of
bounds)
at parse.y:3667
3667 result =
