On Wed, Aug 14, 2002 at 03:16:20AM -0400, Mike Lambert wrote:
> > If the rx info object is going away, then obviously those parts of the
> > patch need not be applied. But in the meantime, it's nice to have a
> > Parrot that doesn't crash.
>
> I agree. My disclaimer about the regex code in my ori
> Somebody gimme a cookie.
/me hands Steve a cookie.
> If the rx info object is going away, then obviously those parts of the
> patch need not be applied. But in the meantime, it's nice to have a
> Parrot that doesn't crash.
I agree. My disclaimer about the regex code in my original email was t
> I have also come to the conclusion that tracking down these memory
> bugs is way too difficult right now. I tracked the above problem back
> from a seg fault, which was resulting from a garbage value in the byte
> code stream, which was triggered by adding a PMC to the free list
> until I added
This is a patch that clears up all of the GC_DEBUG-revealed bugs, at
least on my machine. As I enumerated in my previous email, there are a
lot of different ways to fix these sorts of problems, and this just
kinda picks one for each problem encountered. This patch includes the
stuff done by Jason
In tracing down the next crash bug using GC_DEBUG, I found that the
following code in new_stack is unsafe:
stack->buffer = new_buffer_header(interpreter);
Parrot_allocate(interpreter, stack->buffer,
sizeof(Stack_Entry_t) * STACK_CHUNK_DEPTH);
A GC can be triggered by
At 9:48 PM +0100 8/12/02, Nicholas Clark wrote:
>On Mon, Aug 12, 2002 at 04:04:40PM -0400, Jason Gloudon wrote:
>> On Mon, Aug 12, 2002 at 03:56:27AM -0400, Mike Lambert wrote:
>>
>> Here is a workaround for one hash related GC bug.
> ^^
>
>> + volatile Buffer *for_gc;
>>
Here is another way of resolving this, as I mentioned in the last message.
Having new_hash() initialize the PMC's data pointer so that the hash is
immediately visible to the collector.
--
Jason
Index: parrot/hash.c
===
RCS file:
On Mon, Aug 12, 2002 at 09:48:56PM +0100, Nicholas Clark wrote:
> This is a case of a temporary allocated value being only in a CPU register?
Not in this case. The link to the hash structure from the PMC is not
established, which prevents the custom mark routine in the PMC from identifying
the b
On Mon, Aug 12, 2002 at 04:04:40PM -0400, Jason Gloudon wrote:
> On Mon, Aug 12, 2002 at 03:56:27AM -0400, Mike Lambert wrote:
>
> Here is a workaround for one hash related GC bug.
^^
> + volatile Buffer *for_gc;
> /* hash->buffer.flags |= BUFFER_report_FLAG; */
On Mon, Aug 12, 2002 at 04:23:14PM -0400, Mike Lambert wrote:
> Weird. I had to move the lo_var_ptr initialization code to runcode instead
> of runops, in order to avoid collecting the ARGV pmc. The new code looks
> like:
>
> void *dummy_ptr;
> PMC *userargv;
You sure? That's what I thought at f
> > Anyone more well-versed in these departments than I care to take a look at
> > the potential problems? Just change GC_DEBUG in parrot.h, and you can be
> > on your way. :)
>
> I can't get to it because parrot doesn't survive past initialization
> for me. When it creates the Array PMC for usera
On Mon, Aug 12, 2002 at 04:04:40PM -0400, Jason Gloudon wrote:
> On Mon, Aug 12, 2002 at 03:56:27AM -0400, Mike Lambert wrote:
>
> Here is a workaround for one hash related GC bug.
Nice catch. That, in combination with the patch I just posted, fixes
all but 4 of the failures for me.
On Mon, Aug 12, 2002 at 12:34:28PM -0700, Sean O'Rourke wrote:
> On Mon, 12 Aug 2002, Steve Fink wrote:
> > farther yet. Oh, and I do have your recent patch to set
> > interpreter->lo_var_ptr early.
>
> How early is "early"? It looks like setting lo_var_ptr in Parrot_runcode
> instead of runops
On Mon, Aug 12, 2002 at 03:56:27AM -0400, Mike Lambert wrote:
Here is a workaround for one hash related GC bug.
--
Jason
Index: hash.c
===
RCS file: /cvs/public/parrot/hash.c,v
retrieving revision 1.19
diff -u -r1.19 hash.c
--- h
On Mon, 12 Aug 2002, Steve Fink wrote:
> farther yet. Oh, and I do have your recent patch to set
> interpreter->lo_var_ptr early.
How early is "early"? It looks like setting lo_var_ptr in Parrot_runcode
instead of runops should be necessary/sufficient. If not, does
initializing it to the addres
On Mon, Aug 12, 2002 at 03:56:27AM -0400, Mike Lambert wrote:
> - hashes (these were recently rewritten to use indices, a step forward,
> but they aren't 100% clean yet)
I know of at least one remaining problem with these, but...
> Anyone more well-versed in these departments than I care to take
Mike,
I tried to have a look at the lexicals and subs issues but I am finding
that with the GC_DEBUG flag set to 1, I *always* get a segmentation
fault, even for simple pasm files like :
set I0, 12
end
or just:
end
Is there something I am doing wrong? I did a fresh checkout about an
hou
Hey,
I re-added the GC_DEBUG define today, and weeded out a bunch of issues.
For those who don't remember, GC_DEBUG (currently in parrot.h) causes
various limits and settings and logic to be setup such that GC bugs occur
relatively soon after the offending code. It allocates one header at
a time,
18 matches
Mail list logo
