[9fans] realloc

[9fans] realloc

[Sergey Reva]

Hello Fans

I use realloc to increase buffer, and 3-5 cucle of resizing work fine,
but others produce this:

corrupt tail magic0
pool sbrkmem block 38178
hdr 0a110c09 00000020 00001429 00000000 00640064 00640064
tail 0a110c09 00000020 00001429 00000000 00640064 00640064 | ef100064 00000020
user data 64 00 64 00  64 00 64 00 | 64 00 10 ef  20 00 00 00
panic: pool panic
8.out 2318: suicide: sys: trap: fault read addr=0x0 pc=0x0000375b

What useful information I can get from this? What meaning of fields in this
output?
--
http://rs-rlab.narod.ru                          mailto:rs_rlab@mail.ru

Re: [9fans] realloc

[Sergey Reva]

Hello Fans

And also (sometimes):
2726.1 dsize >= getdsize(b): assertion failed
8.out 2726: suicide: sys: trap: fault read addr=0x0 pc=0x00003735

but generated by msize (which called before realloc):

abort()+0x0 /sys/src/libc/9sys/abort.c:6
_threadassert(s=0x1d6fa)+0x79 /sys/src/libthread/debug.c:50
_assert(s=0x1d6fa)+0x17 /sys/src/libc/port/_assert.c:11
poolmsize(p=0x1a5b8,v=0x3d730)+0x150 /sys/src/libc/port/pool.c:1356
msize(v=0x3d738)+0x1c /sys/src/libc/port/malloc.c:271
insrune(del=0x0,r=0x77)+0x8c /usr/rlab/????/main.c:96
threadmain()+0x27b /usr/rlab/????/main.c:146
mainlauncher(arg=0x22b48)+0x18 /sys/src/libthread/main.c:56
launcher386(arg=0x22b48,f=0xdd54)+0x10 /sys/src/libthread/386.c:10
0xfefefefe ?file?:0
--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] realloc

[Charles Forsyth]

normally it would be a fair assumption that you
are scribbling over the heap.  apart from
the obvious ways of doing so (off by some, etc.)
since you're using threads,
you might also check that you don't put too much data
on a thread's stack (they don't grow and the default
might be fairly modest).

Re: [9fans] realloc

[Russ Cox]

you scribbled past the end of the buffer with an extra 0064.
the ef100064 should be more like ef1000be.  look in the
archives for the explanation of these dumps that i gave
a week ago in the tip o' the day thread.

your other problems may well go away once you fix this.

russ


On Sat, 26 Feb 2005 19:37:30 +0200, Sergey Reva <rs_rlab@mail.ru> wrote:
> Hello Fans
>
> I use realloc to increase buffer, and 3-5 cucle of resizing work fine,
> but others produce this:
>
> corrupt tail magic0
> pool sbrkmem block 38178
> hdr 0a110c09 00000020 00001429 00000000 00640064 00640064
> tail 0a110c09 00000020 00001429 00000000 00640064 00640064 | ef100064 00000020
> user data 64 00 64 00  64 00 64 00 | 64 00 10 ef  20 00 00 00
> panic: pool panic
> 8.out 2318: suicide: sys: trap: fault read addr=0x0 pc=0x0000375b
>
> What useful information I can get from this? What meaning of fields in this
> output?
> --
> http://rs-rlab.narod.ru                          mailto:rs_rlab@mail.ru
>
>

Re: [9fans] realloc

[Sergey Reva]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

Hello Russ,

Saturday, February 26, 2005, 9:18:18 PM, you wrote:
RC> your other problems may well go away once you fix this.

How fix this?

text_count++;
size=msize(Text);
if (size<=(text_count*2))
   Text=realloc(Text,size+BLOCKSIZE);

This code cause my problem... (other part of function still not implemented)
I wrote program which test this function, it's add 100 times some
symbol to buffer... and get same result... then port it to Windows and
get full work program... :-/

Thanks for help
--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

[-- Attachment #2: main.c --]
[-- Type: application/octet-stream, Size: 1200 bytes --]

#include <u.h>					//for Plan 9
#include <libc.h>					//for Plan 9

//#include <stdlib.h>					//for windows
//#include <stdio.h>					//for windows
//#include <malloc.h>					//for windows
//#define Rune unsigned short			//for windows
//#define ulong unsigned long			//for windows
//#define msize _msize				//for windows
//#define print printf				//for windows

#define BLOCKSIZE 16

Rune *Text;
ulong text_count=0;
ulong text_pos=0;
Rune add=L'A';

void insrune(Rune r,int del)
{
	ulong size;

	if (del!=0)
	{
		if (del<0)
		{
			//Remove
			if (text_pos>0)
				memmove(Text+text_pos*2-1,Text+text_pos*2+2,(text_count-text_pos-abs(del))*2);
			text_pos--;
		}
		else
		{
			//Delete
		}
		text_count--;
	}
	else
	{
		text_count++;

		size=msize(Text);
		if (size<=(text_count*2))
		{
			Text=realloc(Text,size+BLOCKSIZE);
		}
		
		memmove(Text+text_pos+2,Text+text_pos,text_count-text_pos);
		*((Rune*)(Text+text_pos))=r;

		text_pos++;
	}
}

void main(int argc,char *argv[])
{
	int i;
	Text=malloc(0);

	for (i=0;i<100;i++)
	{
		insrune(add,0);
		print("%d\t%.*S\n",i,text_count,Text);
		print("%d\n",msize(Text));
	}

	free(Text);
}

Re: [9fans] realloc

[rog]

> This code cause my problem...

i'm not surprised, i'm afraid. this is really horrible code.
you need to sort out your ideas about how C pointers work.
for instance, given that Text is an array of runes,

		*((Rune*)(Text+text_pos))=r;

is exactly equivalent to:

		Text[text_pos] = r;

i haven't time to work out exactly how you're going wrong,
(you *are* scribbling over the end of a malloc block)
but here's a likely candidate:

	memmove(Text+text_pos+2,Text+text_pos,text_count-text_pos);

you're using text_pos in two different ways here:
as an index into a array of Runes, and as a byte offset
as expected by memmove.

i *think* you're probably trying to write code something like:

	if(text_count >= msize(Text) / sizeof(Rune))
		Text = realloc(Text, (text_count+BLOCKSIZE)*sizeof(Rune));
	memmove(Text+textpos+1, Text+textpos, (text_count-text_pos)*sizeof(Rune));
	Text[text_pos] = r;
	text_pos++;
	text_count++;

which seems to work ok.

if you're going to write Plan 9 code, it would a good idea to look at
some existing Plan 9 code (try /sys/src/cmd, for starters) and copy
the style, as far as you can, in particular regarding naming
conventions and code layout.  there's loads of inspiration there.  it
*is* possible to write simple, understandable code.

  cheers,
    rog.

Re: [9fans] realloc

[Sergey Reva]

Hello rog,

Wednesday, March 2, 2005, 8:16:36 PM, you wrote:
rvc> i haven't time to work out exactly how you're going wrong,
rvc> (you *are* scribbling over the end of a malloc block)
rvc> but here's a likely candidate:
rvc> 	memmove(Text+text_pos+2,Text+text_pos,text_count-text_pos);
Really wrong... now I see...
But why stk() in acid show last executed function (in my program) as
realloc?

Thanks!
-- 
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] realloc

[Charles Forsyth]

>>But why stk() in acid show last executed function (in my program) as realloc?

that's the first point at which the run-time system detected
that some hidden values it had planted at malloc/realloc had
been overwritten.  in general unless the allocated area lies
right at the limit of the process's data space you won't
get a trap because memmove is still accessing valid memory locations
even if the locations and the data are not what you really intended.
nothing untoward happened under windows because windows does
not (apparently) attempt to detect this common programming error,
or if it does, the scheme it uses was ineffective in your case.