Re: [perl #43105] [PATCH] function mmd.c::mmd_expand_y: newly allocated memory unitialized
On Monday 04 June 2007 11:10:01 Bernhard Schmalhofer via RT wrote: > This answers the question. So I propose to apply Mehmet's patch and > add to pdd07 something like: Thanks, both Mehmet's and your patches applied in r18832. -- c
[perl #43105] [PATCH] function mmd.c::mmd_expand_y: newly allocated memory unitialized
> > What happens when NULL is not a consective series of '\0' chars? > > I think that it breaks. > > > Are there such platforms and are they releavant for parrot? > > I believe that this assumption is endemic in Perl 5, and it's never > hindered > Perl 5's portability. The C FAQ gives examples of platforms where NULL > is not > all bits zero - http://c-faq.com/null/machexamp.html - and I've never > encountered anyone using them. This answers the question. So I propose to apply Mehmet's patch and add to pdd07 something like: --- pdds/pdd07_codingstd.pod(Revision 18803) +++ pdds/pdd07_codingstd.pod(Arbeitskopie) @@ -62,6 +62,9 @@ integral type (no smaller than typedef C in Parrot), then back to its original type, without loss. +Also C code may assume that there is a single NULL pointer representation +and that it consists of a number, usually 4 or 8, of '\0' chars in memory. + C code that makes assumptions beyond these must depend on the configuration system, either to not compile an entire non-portable source where it will not work, or to provide an appropriate #ifdef macro. Regards, Bernhard -- /* Bernhard.Schmalhofer at gmx.de */
Re: [perl #43105] [PATCH] function mmd.c::mmd_expand_y: newly allocated memory unitialized
Nicholas Clark schrieb: On Sun, Jun 03, 2007 at 08:00:18AM -0700, Bernhard Schmalhofer via RT wrote: I have looked at the 'more_memory.patch' and I'm wondering about the portability. In that patch loops where pointers are explicitly set to NULL are replaced with a memset( start, 0, len); What happens when NULL is not a consective series of '\0' chars? I think that it breaks. Are there such platforms and are they releavant for parrot? I believe that this assumption is endemic in Perl 5, and it's never hindered Perl 5's portability. The C FAQ gives examples of platforms where NULL is not all bits zero - http://c-faq.com/null/machexamp.html - and I've never encountered anyone using them. (As an aside, I think that Perl 5 also (mostly?) doesn't assume 2s complement storage of integers. IIRC a bug report from a Ahmdal mainframes gave the impression that it was using sign and magnitude. However, we've not heard about anyone using Ahmdal mainframes in years. Likewise no-one has missed the removal of memory model support from Configure, so presumably no-one is compiling on a PDP-11 anymore. We did discover nasal daemons, or something similarly painful, on Irix64, until we removed assumptions about signed integer overflow. (It's undefined behaviour. It will bite)) Nicholas Clark
Re: [perl #43105] [PATCH] function mmd.c::mmd_expand_y: newly allocated memory unitialized
On Sun, Jun 03, 2007 at 08:00:18AM -0700, Bernhard Schmalhofer via RT wrote: > I have looked at the 'more_memory.patch' and I'm wondering about the > portability. > In that patch loops where pointers are explicitly set to NULL > are replaced with a > memset( start, 0, len); > > What happens when NULL is not a consective series of '\0' chars? I think that it breaks. > Are there such platforms and are they releavant for parrot? I believe that this assumption is endemic in Perl 5, and it's never hindered Perl 5's portability. The C FAQ gives examples of platforms where NULL is not all bits zero - http://c-faq.com/null/machexamp.html - and I've never encountered anyone using them. (As an aside, I think that Perl 5 also (mostly?) doesn't assume 2s complement storage of integers. IIRC a bug report from a Ahmdal mainframes gave the impression that it was using sign and magnitude. However, we've not heard about anyone using Ahmdal mainframes in years. Likewise no-one has missed the removal of memory model support from Configure, so presumably no-one is compiling on a PDP-11 anymore. We did discover nasal daemons, or something similarly painful, on Irix64, until we removed assumptions about signed integer overflow. (It's undefined behaviour. It will bite)) Nicholas Clark
[perl #43105] [PATCH] function mmd.c::mmd_expand_y: newly allocated memory unitialized
> I grepped for other files that can make use of mem_sys_*_zeroed > variants. I attached a patch that affects objects.c, vtables.c, > gc/register.c and stm/waitlist.c. I have looked at the 'more_memory.patch' and I'm wondering about the portability. In that patch loops where pointers are explicitly set to NULL are replaced with a memset( start, 0, len); What happens when NULL is not a consective series of '\0' chars? Are there such platforms and are they releavant for parrot? -- /* Bernhard.Schmalhofer at gmx.de */
Re: [perl #43105] [PATCH] function mmd.c::mmd_expand_y: newly allocated memory unitialized
On 6/2/07, chromatic <[EMAIL PROTECTED]> wrote:
On Friday 01 June 2007 16:29:08 Mehmet Yavuz Selim Soyturk wrote:
> After a suggestion of Bernhard at #parrot, I added a function named
> C to parrot:
>
> void * mem__sys_realloc_zeroed(void *from, size_t size, size_t
> old_size)
>
> It zeroes the contents of C from C.
> I had to cast C to a C to suppress a warning from gcc
> about pointer arithmetics, but I don't know if it's a good solution:
>
> memset((char*)ptr + old_size, 0, size - old_size);
>
> > I thought that might happen. I prefer this memset() patch, but if it
> > doesn't work everywhere, your patch should work.
>
> I attached a patch that makes use of C and
> C.
Thanks, applied as r18757.
-- c
I grepped for other files that can make use of mem_sys_*_zeroed
variants. I attached a patch that affects objects.c, vtables.c,
gc/register.c and stm/waitlist.c.
--
Mehmet
Index: src/objects.c
===
--- src/objects.c (revision 18722)
+++ src/objects.c (working copy)
@@ -1376,7 +1376,7 @@
PMC *
Parrot_find_method_with_cache(Interp *interp, PMC *_class, STRING *method_name /* NN */)
{
-UINTVAL type, bits, i;
+UINTVAL type, bits;
Caches *mc;
Meth_cache_entry *e, *old;
@@ -1396,26 +1396,20 @@
if (type >= mc->mc_size) {
if (mc->idx) {
-mc->idx = (Meth_cache_entry ***)mem_sys_realloc(mc->idx,
-sizeof (Meth_cache_entry ***) * (type + 1));
+mc->idx = (Meth_cache_entry ***)mem_sys_realloc_zeroed(mc->idx,
+sizeof (Meth_cache_entry ***) * (type + 1),
+sizeof (Meth_cache_entry ***) * mc->mc_size);
}
else {
-mc->idx = (Meth_cache_entry ***)mem_sys_allocate(
+mc->idx = (Meth_cache_entry ***)mem_sys_allocate_zeroed(
sizeof (Meth_cache_entry ***) * (type + 1));
}
-
-for (i = mc->mc_size; i <= type; ++i)
-mc->idx[i] = NULL;
-
mc->mc_size = type + 1;
}
if (!mc->idx[type]) {
-mc->idx[type] = (Meth_cache_entry **)mem_sys_allocate(
+mc->idx[type] = (Meth_cache_entry **)mem_sys_allocate_zeroed(
sizeof (Meth_cache_entry *) * TBL_SIZE);
-
-for (i = 0; i < TBL_SIZE; ++i)
-mc->idx[type][i] = NULL;
}
e = mc->idx[type][bits];
Index: src/gc/register.c
===
--- src/gc/register.c (revision 18722)
+++ src/gc/register.c (working copy)
@@ -141,7 +141,6 @@
void
create_initial_context(Interp *interp)
{
-int i;
static INTVAL num_regs[] ={32,32,32,32};
/* Create some initial free_list slots. */
@@ -149,10 +148,8 @@
#define INITIAL_FREE_SLOTS 8
interp->ctx_mem.n_free_slots = INITIAL_FREE_SLOTS;
interp->ctx_mem.free_list=
-(void **)mem_sys_allocate(INITIAL_FREE_SLOTS * sizeof (void *));
+(void **)mem_sys_allocate_zeroed(INITIAL_FREE_SLOTS * sizeof (void *));
-for (i = 0; i < INITIAL_FREE_SLOTS; ++i)
-interp->ctx_mem.free_list[i] = NULL;
/*
* For now create context with 32 regs each. Some src tests (and maybe other
* extenders) are assuming the presence of these registers
Index: src/vtables.c
===
--- src/vtables.c (revision 18722)
+++ src/vtables.c (working copy)
@@ -90,13 +90,9 @@
table and we could get bigger without blowing much memory
*/
const INTVAL new_max = interp->n_vtable_alloced + 16;
-const INTVAL new_size = new_max * sizeof (VTABLE *);
-INTVAL i;
-interp->vtables = (VTABLE **)mem_sys_realloc(interp->vtables, new_size);
-/* Should set all the empty slots to the null PMC's
- vtable pointer */
-for (i = interp->n_vtable_max; i < new_max; ++i)
-interp->vtables[i] = NULL;
+const INTVAL new_size = new_max * sizeof (VTABLE *);
+const INTVAL old_size = interp->n_vtable_max * sizeof (VTABLE *);
+interp->vtables = (VTABLE **)mem_sys_realloc_zeroed(interp->vtables, new_size, old_size);
interp->n_vtable_alloced = new_max;
}
Index: src/stm/waitlist.c
===
--- src/stm/waitlist.c (revision 18722)
+++ src/stm/waitlist.c (working copy)
@@ -41,12 +41,9 @@
}
if (thr->used_entries >= thr->entry_count) {
-size_t i;
-thr->entries = mem_sys_realloc(thr->entries,
-sizeof (*thr->entries) * thr->entry_count * 2);
-for (i = thr->entry_count; i < thr->entry_count * 2; ++i) {
-thr->entries[i] = NULL;
-}
+thr->entries = mem_sys_realloc_zeroed(thr->entries,
+sizeof (*thr->entries) * thr->entry_count * 2,
+sizeof (*thr->entries) * thr->entry_count);
thr->entry_count *= 2;
}
Re: [perl #43105] [PATCH] function mmd.c::mmd_expand_y: newly allocated memory unitialized
On Friday 01 June 2007 13:39:32 Mehmet Yavuz Selim Soyturk wrote:
> Function mmd_expand_y in src/mmd.c allocates new memory for the mmd
> table, but does not initialize the newy allocated memory to NULL,
> which causes segfaults for some cases. The attached patch solves that
> problem.
I thought that might happen. I prefer this memset() patch, but if it doesn't
work everywhere, your patch should work.
-- c
=== src/mmd.c
==
--- src/mmd.c (revision 3732)
+++ src/mmd.c (local)
@@ -623,19 +623,22 @@
static void
mmd_expand_y(Interp *interp, INTVAL func_nr, INTVAL new_y)
{
-funcptr_t *new_table;
-UINTVALnew_size;
+UINTVALnew_size, i, x, y;
MMD_table * const table = interp->binop_mmd_funcs + func_nr;
assert(table->x);
-new_size = sizeof (funcptr_t) * table->x * new_y;
+x= table->x;
+y= table->y;
+new_size = sizeof (funcptr_t) * x * new_y;
if (table->mmd_funcs)
table->mmd_funcs = mem_sys_realloc(table->mmd_funcs, new_size);
else
table->mmd_funcs = (funcptr_t *)mem_sys_allocate(new_size);
+memset(table->mmd_funcs + x * y, 0, x * (new_y - y));
+
table->y = new_y;
}
[perl #43105] [PATCH] function mmd.c::mmd_expand_y: newly allocated memory unitialized
# New Ticket Created by "Mehmet Yavuz Selim Soyturk"
# Please include the string: [perl #43105]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43105 >
Function mmd_expand_y in src/mmd.c allocates new memory for the mmd
table, but does not initialize the newy allocated memory to NULL,
which causes segfaults for some cases. The attached patch solves that
problem.
--
Mehmet
Index: src/mmd.c
===
--- src/mmd.c (revision 18722)
+++ src/mmd.c (working copy)
@@ -624,18 +624,30 @@
mmd_expand_y(Interp *interp, INTVAL func_nr, INTVAL new_y)
{
funcptr_t *new_table;
-UINTVALnew_size;
+UINTVAL x;
+UINTVAL y;
+UINTVAL i;
+UINTVAL new_size;
MMD_table * const table = interp->binop_mmd_funcs + func_nr;
assert(table->x);
+
+x = table->x;
+y = table->y;
-new_size = sizeof (funcptr_t) * table->x * new_y;
+new_size = sizeof (funcptr_t) * x * new_y;
if (table->mmd_funcs)
-table->mmd_funcs = mem_sys_realloc(table->mmd_funcs, new_size);
+new_table = mem_sys_realloc(table->mmd_funcs, new_size);
else
-table->mmd_funcs = (funcptr_t *)mem_sys_allocate(new_size);
-
+new_table = (funcptr_t *)mem_sys_allocate(new_size);
+
+/* Initialize the newly allocated space with NULLs */
+for (i = x * y; i < x * new_y; i++) {
+new_table[i] = NULL;
+}
+
+table->mmd_funcs = new_table;
table->y = new_y;
}
