[Gluster-devel] Modifying GlusterFS to cope with C99 inline semantics

Atin Mukherjee amukherj at redhat.com
Tue Jul 28 03:39:44 UTC 2015



On 07/28/2015 04:49 AM, Jeff Darcy wrote:
>>> My opinion: don't try to second guess the compiler/optimizer; stop using
>>> inline. Full Stop.
>>
>> To this end, I've submitted a patch which removes all instances in .c
>> files.
>>
>>     http://review.gluster.org/#/c/11769/
> 
> 
> Regression tests blew up in snapshot code.  It's really hard to see how
> this is related to anything in the patch itself, especially because only
> one of the un-inlined functions was in snapshot code.  Here's a partial
> backtrace:
> 
> #0  0x00007fe845d4ce2c in vfprintf () from /d/crap/lib64/libc.so.6
> #1  0x00007fe845d74752 in vsnprintf () from /d/crap/lib64/libc.so.6
> #2  0x00007fe845d54223 in snprintf () from /d/crap/lib64/libc.so.6
> #3  0x00007fe83c62af79 in glusterd_volume_stop_glusterfs (volinfo=0x1f844b0,
>     brickinfo=0x1f8e2b0, del_brick=_gf_false)
>     at /home/jenkins/root/workspace/rackspace-regression-2GB/xlators/mgmt/glusterd/src/glusterd-utils.c:1757
> #4  0x00007fe83c637e15 in glusterd_brick_stop (volinfo=0x1f844b0,
>     brickinfo=0x1f8e2b0, del_brick=_gf_false)
>     at /home/jenkins/root/workspace/rackspace-regression-2GB/xlators/mgmt/glusterd/src/glusterd-utils.c:5443
> #5  0x00007fe83c6c286c in glusterd_snap_volume_remove (rsp_dict=0x7fe82800182c,
>     snap_vol=0x1f844b0, remove_lvm=_gf_false, force=_gf_false)
>     at /home/jenkins/root/workspace/rackspace-regression-2GB/xlators/mgmt/glusterd/src/glusterd-snapshot.c:2897
> #6  0x00007fe83c6c2e17 in glusterd_snap_remove (rsp_dict=0x7fe82800182c,
>     snap=0x1f7c1d0, remove_lvm=_gf_false, force=_gf_false)
>     at /home/jenkins/root/workspace/rackspace-regression-2GB/xlators/mgmt/glusterd/src/glusterd-snapshot.c:3005
> #7  0x00007fe83c6eee54 in glusterd_compare_and_update_snap (
>     peer_data=0x7fe828005acc, snap_count=2, peername=0x7fe828003100 "127.1.1.1",
>     peerid=0x7fe8280059b0 "\270\300\262u\233+ at Q\264U\325\177\367\261", <incomplete sequence \352\224>)
>     at /home/jenkins/root/workspace/rackspace-regression-2GB/xlators/mgmt/glusterd/src/glusterd-snapshot-utils.c:1849
> #8  0x00007fe83c6ef11b in glusterd_compare_friend_snapshots (
>     peer_data=0x7fe828005acc, peername=0x7fe828003100 "127.1.1.1",
>     peerid=0x7fe8280059b0 "\270\300\262u\233+ at Q\264U\325\177\367\261", <incomplete sequence \352\224>)
>     at /home/jenkins/root/workspace/rackspace-regression-2GB/xlators/mgmt/glusterd/src/glusterd-snapshot-utils.c:1904
> 
> Based on how variables are set in frame 7, it looks like we must have
> taken the "goto remove_my_data" path at line 1776, but *snap hasn't
> really been initialized to a sufficient degree - hence the crash.
> 
> (gdb) p *snap
> $1 = {lock = -1379869184, volumes = {next = 0x1f1ac6000, prev = 0xc100},
>   snap_list = {next = 0x15800, prev = 0x1f7c1d000},
>   snapname = "\000\336\300\255\336\000\000\000\000`\254\361\001\000\000\000\000\301\000\000\000\000\000\000\000X\001\000\000\000\000\000\000\320\301\367\001\000\000\000\000\336\300\255\336\000\000\000\000`\254\361\001\000\000\000\000\301\000\000\000\000\000\000\000X\001\000\000\000\000\000\000\320\301\367\001\000\000\000\000\336\300\255\336\000\000\000\000`\254\361\001\000\000\000\000\301\000\000\000\000\000\000\000X\001\000\000\000\000\000\000\320\301\367\001\000\000\000\000\336\300\255\336\000\000\000\000`\254\361\001\000\000\000\000\301\000\000\000\000\000\000\000X\001\000\000\000\000\000\000\320\301\367\001\000\000\000\000\336\300\255\336\000\000\000\000`\254\361\001\000\000\000\000\301\000\000\000\000\000\000\000X\001\000\000\000\000\000\000\320\301\367\001\000\000\000\000"...,
>   snap_id = "\000\000\301\000\000\000\000\000\000\000X\001\000\000\000",
>   description = 0x1f7c1d000 <error: Cannot access memory at address 0x1f7c1d000>,
>   time_stamp = -256, snap_restored = (_gf_true | unknown: 4294967294),
>   snap_status = 4294967295, shandle = 0xffffffffffffffff}
> 
> Were these code paths ever even tested?  I'm going to move on to
> other things.  Perhaps somebody who knows the snapshot code could
> figure out how it strangled itself this time.
IMO this is a different issue, not related to inline semantics.  Anand
has already posted a patch [1] to address it.

[1] http://review.gluster.org/#/c/11757/

___________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 

-- 
~Atin


More information about the Gluster-devel mailing list