[Gluster-devel] One more regression

Venky Shankar yknev.shankar at gmail.com
Fri Mar 20 10:03:55 UTC 2015


On Fri, Mar 20, 2015 at 2:13 PM, Emmanuel Dreyfus <manu at netbsd.org> wrote:
> Hello
>
> I cannot keep up with the flow of regression that hit NetBSD since two
> weeks. There have been some new test cases added withuout looking at
> NetBSD result. It may be easy to fix but it is still frustrating.
>
> There have also been real new bugs introduced. The fact that they did
> not appear in Linux is not a guarantee that you will never see them
> bite you later.

This was also seen in Linux. This fix has been sent to counter this
issue: http://review.gluster.org/#/c/9953/

>
> Consider tests/basic/quota.t, il now fails on NetBSD because the
> brick's glusterfsd crashes on a unintialized  client structure (xl=0x3
> below)
>
> Core was generated by `glusterfsd'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0xbb792021 in create_frame (xl=0x3, pool=0xbb188078) at stack.c:45
> 45              stack->ctx = xl->ctx;
> (gdb) bt
> #0  0xbb792021 in create_frame (xl=0x3, pool=0xbb188078) at stack.c:45
> #1  0xb9ada0d4 in server_alloc_frame (req=0xb750e028) at server-helpers.c:384
> #2  0xb9ada257 in get_frame_from_request (req=0xb750e028)
>     at server-helpers.c:424
> #3  0xb9af3f44 in server3_3_statfs (req=0xb750e028) at server-rpc-fops.c:6177
> #4  0xbb71d6a5 in rpcsvc_handle_rpc_call (svc=0xbb1a4218, trans=0xb750d018,
>     msg=0xb75150d8) at rpcsvc.c:690
> #5  0xbb71d932 in rpcsvc_notify (trans=0xb750d018, mydata=0xbb1a4218,
>     event=RPC_TRANSPORT_MSG_RECEIVED, data=0xb75150d8) at rpcsvc.c:784
> #6  0xbb722b7f in rpc_transport_notify (this=0xb750d018,
>     event=RPC_TRANSPORT_MSG_RECEIVED, data=0xb75150d8) at rpc-transport.c:543
> #7  0xbb28e90c in socket_event_poll_in (this=0xb750d018) at socket.c:2290
> #8  0xbb28edc1 in socket_event_handler (fd=24, idx=10, data=0xb750d018,
>     poll_in=1, poll_out=0, poll_err=0) at socket.c:2403
> #9  0xbb7b8730 in event_dispatch_poll_handler (event_pool=0xbb144018,
>     ufds=0xb7510098, i=10) at event-poll.c:391
> #10 0xbb7b8a54 in event_dispatch_poll (event_pool=0xbb144018)
>     at event-poll.c:487
> #11 0xbb789752 in event_dispatch (event_pool=0xbb144018) at event.c:127
> #12 0xb9bd6e99 in changelog_rpc_poller (arg=0xbb1d2018)
>     at changelog-rpc-common.c:29
> (gdb) frame 1
> #1  0xb9ada0d4 in server_alloc_frame (req=0xb750e028) at server-helpers.c:384
> 384             frame = create_frame (client->this, req->svc->ctx->pool);
> (gdb) print *client
> $1 = {scratch_ctx = {lock = {pts_magic = 3, pts_spin = 3 '\003',
>       pts_flags = 8}, count = 3, ctx = 0xc}, ref = {lock = {pts_magic = 3,
>       pts_spin = 14 '\016', pts_flags = 3}, bind = 9, count = 3},
>   bound_xl = 0x11, this = 0x3, tbl_index = 13,
>   client_uid = 0x3 <error: Cannot access memory at address 0x3>, auth = {
>     flavour = 15, len = 3,
>     data = 0x16 <error: Cannot access memory at address 0x16>,
>     username = 0x3 <error: Cannot access memory at address 0x3>,
>     passwd = 0x17 <error: Cannot access memory at address 0x17>}}
>
>
>
> --
> Emmanuel Dreyfus
> manu at netbsd.org
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel


More information about the Gluster-devel mailing list