Alex Hudson
2009-06-02 09:20:37 UTC
Hi all.
Those watching svn will have seen a new branch of trunk:
http://svn.gna.org/svn/bongo/experiments/memmgr-glib
The idea for this branch is to change our current memory allocation
system over to a much simpler method based on GLib.
Because we're so close to 0.5 I don't want to destabilise trunk with
this, hence the branch, because this new allocator is managing to show
up bugs I've never seen before. This is good news in a way, though - the
fixes for the bugs can go into trunk, and there's already a pretty nasty
bug in our SQLite wrapper that has been caught.
We don't have much in the way of stats built into this system yet,
although I intend for it to be pretty hot on leak-tracing, and GLib's
malloc() will abort() applications that run out of memory - which is an
interesting policy change we will have to think about.
One thing I've also found is that it's also quite easy to build Bongo
with ElectricFence support to catch out of bounds reads/writes. The way
to do it is to install ElectricFence, and then:
CFLAGS=-lefence ./configure --prefix=...(usual flags)
... or of course do the same but with ./autogen.sh instead of configure.
Then, when you start up Bongo, immediately attach gdb to the
agent/process you want to work with:
gdb ./sbin/bongostore `pgrep bongostore`
... or similar. Then, any out-of-bounds access, be it read or write,
causes an immediate segfault. This will look pretty odd at first: those
on IRC yesterday will know I was agonising over this:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff75b41ee in BongoJsonArrayFree (array=0x7ffff11c0fe8)
at src/libs/json/json.c:534
534 if (array->len > 0) {
(gdb) print *array
$1 = {data = 0x0, len = 0, size = 0, elemSize = 0}
We can see we caught a segfault, which is an access to invalid memory.
However, the array pointer is obviously valid, and the *array structure
also looks valid. What has happened here is that a valid array that we
were using was free()'d in some code previously, and ElectricFence
protected the memory area (free() doesn't give the memory back to the OS
often, so access after a free() often doesn't cause any problems).
Although the code looks entirely valid, there is a bug in there (that
I'm yet to find!).
Cheers,
Alex.
Those watching svn will have seen a new branch of trunk:
http://svn.gna.org/svn/bongo/experiments/memmgr-glib
The idea for this branch is to change our current memory allocation
system over to a much simpler method based on GLib.
Because we're so close to 0.5 I don't want to destabilise trunk with
this, hence the branch, because this new allocator is managing to show
up bugs I've never seen before. This is good news in a way, though - the
fixes for the bugs can go into trunk, and there's already a pretty nasty
bug in our SQLite wrapper that has been caught.
We don't have much in the way of stats built into this system yet,
although I intend for it to be pretty hot on leak-tracing, and GLib's
malloc() will abort() applications that run out of memory - which is an
interesting policy change we will have to think about.
One thing I've also found is that it's also quite easy to build Bongo
with ElectricFence support to catch out of bounds reads/writes. The way
to do it is to install ElectricFence, and then:
CFLAGS=-lefence ./configure --prefix=...(usual flags)
... or of course do the same but with ./autogen.sh instead of configure.
Then, when you start up Bongo, immediately attach gdb to the
agent/process you want to work with:
gdb ./sbin/bongostore `pgrep bongostore`
... or similar. Then, any out-of-bounds access, be it read or write,
causes an immediate segfault. This will look pretty odd at first: those
on IRC yesterday will know I was agonising over this:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff75b41ee in BongoJsonArrayFree (array=0x7ffff11c0fe8)
at src/libs/json/json.c:534
534 if (array->len > 0) {
(gdb) print *array
$1 = {data = 0x0, len = 0, size = 0, elemSize = 0}
We can see we caught a segfault, which is an access to invalid memory.
However, the array pointer is obviously valid, and the *array structure
also looks valid. What has happened here is that a valid array that we
were using was free()'d in some code previously, and ElectricFence
protected the memory area (free() doesn't give the memory back to the OS
often, so access after a free() often doesn't cause any problems).
Although the code looks entirely valid, there is a bug in there (that
I'm yet to find!).
Cheers,
Alex.