Hey,
We should probably be using zeroed out memory there anyway. Although the
fact that this only comes up in a specific condition under centos makes me
want to believe redhat's doing something retarded.
I've committed this and pushed to stable. Thanks!
-Dormando
On Sat, 2 Aug 2008, Ricky Zhou wrote:
On 2008-08-02 03:37:48 AM, Ricky Zhou wrote:
I just tried a git bisect, and got:
f3e522bcc5a211198f587bb63ce08f310a0b2783 is first bad commit
Disclaimer: I don't have any C experience
I think the git-bisect (and all of the other weird conditions causing
the bug) were red herrings. Here's what I think the problem is now:
In thread.c:thread_init, there's a:
threads = malloc(sizeof(LIBEVENT_THREAD) * nthreads);
setup_thread is then called on each member of threads. In
setup_threads, me->base is initialized with:
if (! me->base) {
me->base = event_init();
if (! me->base) {
fprintf(stderr, "Can't allocate event base\n");
exit(1);
}
}
So me->base probably didn't get initialized properly because it got
garbage from malloc. When I switched to a calloc, memcached stopped
segfaulting (patch at
http://ricky.fedorapeople.org/memcached/memcached-calloc.patch)
Does this look like the right description of the problem/solution?
Thanks,
Ricky
