Nikola Vladov | 10 Jun 08:33 2009
Picon

memalloc.c patch

On Wed, Jun 10, 2009 at 03:04:56PM +1000, Herbert Xu wrote:
> Can you separate these two changes into two patches? It's much
> easier to track down problems if each patch does a single thing.

Bellow are the patches.  In the first we can change space[4] also
to space[1].  The second is good for systems which uses malloc
based on mmap and after
   void *x = malloc(4000);
   free(x);
the region is _unmapped_.  One can check this with a simple program
and strace.

diff -urN dash-0.5.5.1_orig/src/memalloc.c dash-0.5.5.1/src/memalloc.c
--- dash-0.5.5.1_orig/src/memalloc.c	Wed Jan 14 01:37:13 2009
+++ dash-0.5.5.1/src/memalloc.c	Wed Jun 10 09:09:23 2009
 <at>  <at>  -97,18 +97,19  <at>  <at> 
  */

 /* minimum size of a block */
-#define MINSIZE SHELL_ALIGN(504)
+/* #define MINSIZE SHELL_ALIGN(504) */
+typedef struct { void *next; size_t size; } __alloc_t;
+#define MINSIZE (512  -SHELL_ALIGN(sizeof(void*) + sizeof(__alloc_t)))

 struct stack_block {
 	struct stack_block *prev;
-	char space[MINSIZE];
+	char space[4];
 };

(Continue reading)

Stefan Potyra | 10 Jun 09:53 2009
Picon
Picon
Picon

Re: Debian Bug#429251: [PATCH] honor tab as IFS whitespace when splitting fields

Hi,

Am Wednesday 10 June 2009 07:48:45 schrieben Sie:
> On Sat, May 30, 2009 at 10:33:00PM +0200, Stefan Potyra wrote:
> > Hi Herbert,
> >
> > thanks for your work wrt dash!
> >
> > forwarding the patch for debian bug 429251 to you, since I just found out
> > that I dropped the CC.
> >
> > Hope, that it's better this time.
>
> Thanks for the patch!
>
> Could you resend it and cc dash <at> vger.kernel.org?
>

Of course, here you are.

Cheers,
     Stefan.
Attachment (dash_ifs_read.patch): text/x-diff, 5230 bytes
Jesper Bengtsson | 22 Jun 10:13 2009
Picon

Parameter expansion fails when assigning a local variable

Hi,

I've found a problem with expanding $ <at> .
If I declare a local variable and assigns the expanded positional parameters:
        local v="$ <at> "
It fails with something like:
        local: 20: \/: bad variable name

If I split declaration and assignment into two lines it will work:
        local v
        v="$ <at> "

I've tried this on dash 0.5.5.1 and 0.5.3 and both fail in the same way.
I've also tried on bash and ash (Busybox) and both handles declaration and assignment on one line.

I'm attaching a small script that shows the problem.

Best regards,
Jesper Bengtsson
Attachment (dash-arg-bug.sh): application/octet-stream, 503 bytes
Herbert Xu | 22 Jun 10:57 2009
Picon
Picon

Re: Parameter expansion fails when assigning a local variable

Jesper Bengtsson <jesper.bengtsson <at> axis.com> wrote:
> 
> I've found a problem with expanding $ <at> .
> If I declare a local variable and assigns the expanded positional parameters:
>        local v="$ <at> "
> It fails with something like:
>        local: 20: \/: bad variable name

This is expected behaviour.  local is just like any other utility
in how it handled parameters.  So "$ <at> " will have been split before
it reaches local.  To get what you want, you should use "$*".

> I've tried this on dash 0.5.5.1 and 0.5.3 and both fail in the same way.
> I've also tried on bash and ash (Busybox) and both handles declaration and assignment on one line.

Bash and older versions of dash (like the one in Busybox) has a
hack that disables field splitting for local and certain other
commands.  This is not guaranteed by POSIX.

Cheers,
--

-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert <at> gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Nikola Vladov | 23 Jun 12:06 2009
Picon

redirect bug

May be this is a bug:

echo XX > uu
cat <> uu

dash truncates file uu.  The open flag O_TRUNC must be removed.
I'm not 100% shure what POSIX say about: program <> file

Nikola
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Herbert Xu | 27 Jun 14:39 2009
Picon
Picon

Re: [JOBS] Do not close stderr when /dev/tty fails to open

On Sat, May 23, 2009 at 12:23:08PM +1000, Herbert Xu wrote:
> On Sun, Feb 22, 2009 at 07:33:04PM +0800, Herbert Xu wrote:
> > [JOBS] Do not close stderr when /dev/tty fails to open
> 
> Turns out that there was more to this than jobs.c  The use of
> savefd in redir ended up closing the wrong file descriptor too,
> albeit in a harmless manner.  I'm going to throw this fix in.
> 
> commit 3db215abfe4c0079cc932d7070ad675e5f6273ea
> Author: Herbert Xu <herbert <at> gondor.apana.org.au>
> Date:   Sat May 23 12:21:26 2009 +1000
> 
>     [REDIR] Fix incorrect savefd conversions

Doh, that patch make it even worse.  Here's the corrected fix.

commit 6c0398654015de53269a2ef32eae3c7b560875dd
Author: Herbert Xu <herbert <at> gondor.apana.org.au>
Date:   Sat Jun 27 20:38:23 2009 +0800

    [REDIR] Fix incorrect savefd conversions

    When I added savefd we may end up closing stderr if that is how
    we get to the tty.  This patch fixes by adding a second argument
    to indicate what fd should be closed which lets jobs.c get around
    the problem.

    Signed-off-by: Herbert Xu <herbert <at> gondor.apana.org.au>

diff --git a/ChangeLog b/ChangeLog
(Continue reading)

Herbert Xu | 27 Jun 15:01 2009
Picon
Picon

Re: Dash Escape characters problem

On Wed, May 27, 2009 at 10:02:43AM +0200, Sven Anders wrote:
> Hello!
> 
> [ Sorry! I'm not sure, if the last messages reached you, so it resent it here... ]
> 
> 
> I upgraded from dash 0.5.4 to 0.5.5.1 and have to report a regression.
> 
> I want to color some output using escape sequences:
> 
> $./dash-0.5.4/src/dash
> >S="echo -n \\033[0;32mOK\\033[0;39m"; $S
> OK
> 
> ** The "OK" is displayed in green color
> 
> 
> 
> $./dash-0.5.5.1/src/dash
> > S="echo -n \\033[0;32mOK\\033[0;39m"; $S
> 033[0;32mOK033[0;39m
> 
> ** The dash does output the escape sequence itself

Thanks for the report.

I've just fixed it as follows:

commit 0d7d66039b614b642c775432fd64aa8c11f9a64d
Author: Herbert Xu <herbert <at> gondor.apana.org.au>
(Continue reading)

Herbert Xu | 27 Jun 15:32 2009
Picon
Picon

Re: memalloc.c patch

On Wed, Jun 10, 2009 at 09:33:35AM +0300, Nikola Vladov wrote:
>
> diff -urN dash-0.5.5.1_orig/src/memalloc.c dash-0.5.5.1/src/memalloc.c
> --- dash-0.5.5.1_orig/src/memalloc.c	Wed Jan 14 01:37:13 2009
> +++ dash-0.5.5.1/src/memalloc.c	Wed Jun 10 09:09:23 2009
>  <at>  <at>  -97,18 +97,19  <at>  <at> 
>   */
>  
>  /* minimum size of a block */
> -#define MINSIZE SHELL_ALIGN(504)
> +/* #define MINSIZE SHELL_ALIGN(504) */
> +typedef struct { void *next; size_t size; } __alloc_t;
> +#define MINSIZE (512  -SHELL_ALIGN(sizeof(void*) + sizeof(__alloc_t)))

I'm a little uneasy about this calculation.  This is very much
dependent on the underlying malloc implementation.  For all we
know, this could turn out to be better or worse if libc changes
under us.

However, I suppose making it slightly smaller can't hurt that
much.  While if the underlying malloc keeps metadata inline then
we gain 512 bytes per amlloc.

But how about rewriting the above as just

	512 - sizeof(void *) * 2

It would be a lot simpler :)

>  struct stack_block {
(Continue reading)

Herbert Xu | 27 Jun 18:05 2009
Picon
Picon

Re: memalloc.c patch ( 4*sizeof(void*) )

On Sat, Jun 27, 2009 at 06:29:33PM +0300, Nikola Vladov wrote:
>
> "2" above is too small.  SHELL_ALIGN is 2*sizeof(void *).
>
> Then we must have
>          buf_size + shell_align + malloc_meta_data <= 512.

shell_align doesn't add anything if the value is already aligned.

> I have tested next and they works OK.
>    MINSIZE (512  -SHELL_ALIGN(sizeof(void*) * 3))
>    MINSIZE (512  -sizeof(void*) * 4)

OK, and you've also tested 512 - sizeof(void *) * 2 to make sure
that it doesn't work? If so we should pick the * 3 variant.

> For malloc which uses sbrk (like DL-malloc) the above does not
> help.  In my opinion in this case we have to use
> fist 512, sacond 1024, third 2048, all other 4096 chuks.

Does it hurt though? If not we should just make this unconditional.

PS Please do reply-to-all instead of reply-to-author.

Thanks,
--

-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert <at> gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
(Continue reading)

Nikola Vladov | 27 Jun 18:45 2009
Picon

Re: memalloc.c patch ( 3*sizeof(void*) )

On Sun, Jun 28, 2009 at 00:05:07AM +0800, Herbert Xu wrote:
> > "2" above is too small.  SHELL_ALIGN is 2*sizeof(void *).
> >
> > Then we must have
> >          buf_size + shell_align + malloc_meta_data <= 512.
> 
> shell_align doesn't add anything if the value is already aligned.

It's depends.  Next is from stalloc
	blocksize = aligned;
		if (blocksize < MINSIZE)
			blocksize = MINSIZE;
		len = sizeof(struct stack_block) - MINSIZE + blocksize;
		      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                  

When I speak for shell_align I mean ^^^^ above.

> > I have tested next and they works OK.
> >    MINSIZE (512  -SHELL_ALIGN(sizeof(void*) * 3))
> >    MINSIZE (512  -sizeof(void*) * 4)
> 
> OK, and you've also tested 512 - sizeof(void *) * 2 to make sure
> that it doesn't work? If so we should pick the * 3 variant.

"2" does not work.  "3" works actually good.  I supposes
that malloc uses 2*sizeof(void*) meta-data.
SHELL_ALIGN(sizeof(void*) * 3) is 
16 bytes on i386
24 bytes on x86_64

(Continue reading)


Gmane