[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnash-dev] GC: status report
From: |
strk |
Subject: |
[Gnash-dev] GC: status report |
Date: |
Sat, 16 Jun 2007 11:38:25 +0200 |
As of current HEAD, the GC version of gnash triggers NO memory corruptions
in our testsuite. Still there are two failures under misc-ming.all:
FAIL: place_and_remove_object_testrunner: _root.sh1 != undefined
[place_and_remove_object_test.c:76]
FAIL: place_and_remove_object_testrunner: expected: undefined obtained: _level0
[place_and_remove_object_test.c:77]
I'll track them out, anyway the point is that our testsuite seems unable to
find more memory corruption, so it's time to try it against other movies,
your offline tests for example.
Finding memory corruptions is the best way to make the GC version more stable.
Basically, if gnash segfaults (and doesn't with the RC version)
the procedure I use to find out what's being NOT properly marked is running
valgrind,
which gives you useful information about illegal memory accesses, in particular
which
piece of code allocated what is being referenced now. That place of code is
usually
a class method, with the class failing to properly mark that resource as
reachable.
Reports welcome :)
--strk;
() ASCII Ribbon Campaign
/\ Keep it simple!
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gnash-dev] GC: status report,
strk <=