Just in case someone has an idea why this happens: From time to time on
NetBSD, gluster randomly crashes because "this" gets replaced by process
environment. Here is an example:
#3 0xbb75afb2 in dict_get (this=0xbb140628,
key=0xbb23669a "transport.address-family") at dict.c:380
(gdb) list
375 if (!this || !key) {
376 gf_log_callingfn ("dict", GF_LOG_INFO,
377 "!this || key=%s", (key) ? key :
"()");
378 return NULL;
379 }
380 if (this->hash_size < 0) abort();
381
382 LOCK (&this->lock);
383
384 pair = _dict_lookup (this, key);
Note I added the if (this->hash_size < 0) abort(); to catch the problem early.
"this" is completely corrupted:
(gdb) print *this
$2 = {is_static = 1 '\001', hash_size = -1082130687, count = -1082130674,
refcount = -1082130649, members = 0xbf7fff2e, members_list = 0xbf7fff39,
extra_free = 0xbf7fff41 "HARNESS_VERSION=3.26",
extra_stdfree = 0xbf7fff56 "SU_FROM=root", lock = {pts_magic = 3212836707,
pts_spin = 112 'p', pts_flags = -1082130523},
members_internal = 0xbf7fffb6, free_pair = {hash_next = 0xbb185411,
prev = 0x0, next = 0x0, value = 0x0, key = 0x0},
free_pair_in_use = _gf_false}
Hex output give a better hint at the problem:
(gdb) x/10wx this
0xbb140628: 0xbf7ffeed 0xbf7fff01 0xbf7fff0e 0xbf7fff27
0xbb140638: 0xbf7fff2e 0xbf7fff39 0xbf7fff41 0xbf7fff56
0xbb140648: 0xbf7fff63 0xbf7fff70
(gdb) x/1s 0xbf7ffeed
0xbf7ffeed: "MAIL=/var/mail/root"
(gdb) x/1s 0xbf7fff01
0xbf7fff01: "BLOCKSIZE=1k"
(gdb) x/1s 0xbf7fff0e
0xbf7fff0e: "PWD=/autobuild/glusterfs"
Oddly, rebooting the machine fixes the problem.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@xxxxxxxxxx
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
