Again, the full backtrace will throw more light as to which FOP invoked the resolver.. please post it
Avati On Sun, Jul 3, 2011 at 3:04 PM, Emmanuel Dreyfus <[email protected]> wrote: > Emmanuel Dreyfus <[email protected]> wrote: > > > Same problem here: > > Well it is not the same problem at all, I changed the subjet to reflect > that > > > Program terminated with signal 11, Segmentation fault. > > #0 0xba4cf88b in resolve_loc_touchup (frame=0xbad002f0) > > at ../../../../libglusterfs/src/mem-pool.h:127 > > > > Here is it: > > > > static inline > > char * gf_strdup (const char *src) > > { > > > > char *dup_str = NULL; > > size_t len = 0; > > > > len = strlen (src) + 1; > > > > src is not a C string. We got there through resolve_loc_touchup(): > > > > if (!path) > > path = gf_strdup (resolve->path); > > > > And here is resolve, where path is NULL. > > > > (gdb) print *((server_state_t *)frame->root->state)->resolve_now > > $5 = {type = 0, fd_no = 18446744073709551615, ino = 0, gen = 0, par = 0, > > gfid = '\0' <repeats 15 times>, pargfid = '\0' <repeats 15 times>, > > path = 0x0, bname = 0x0, resolved = 0x0, op_ret = 0, op_errno = 0, > > deep_loc = {path = 0x0, name = 0x0, ino = 0, inode = 0x0, > > parent = 0x0}, components = 0x0, comp_count = 0} > > > > Perhaps gf_strdup could return NULL when it gets a NULL string? This is > > what strdup(3) does AFAIK. But I suspect that resolve_loc_touchup() > > lacks a check for error for resolve->path being NULL. > > > -- > Emmanuel Dreyfus > http://hcpnet.free.fr/pubz > [email protected] > > _______________________________________________ > Gluster-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/gluster-devel >
_______________________________________________ Gluster-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/gluster-devel
