Re: radosgw segfault in 0.56
On Mon, Jan 7, 2013 at 1:04 PM, Sylvain Munaut
wrote:
> Ok, I tracked this down ...
>
> I'm using lighttpd as a FastCGI front end and it doesn't set
> SCRIPT_URI environment.
>
>
> So the line 1123 in rgw/rgw_rest.cc :
>
> s->script_uri = s->env->get("SCRIPT_URI");
>
> Tries to assign NULL to s->script_uri which crashes with the
> particularly unhelpful stack trace I pasted above ...
Yeah, it's missing a guard here. Strange, I remember fixing this and
others, but I can't find any trace of that. I think setting it to
empty string is ok, though we may want to explore other fixes
(configurable?) -- it affects the Location field in S3 POST response.
Yehuda
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: radosgw segfault in 0.56
Hi, > Yeah, it's missing a guard here. Strange, I remember fixing this and > others, but I can't find any trace of that. I think setting it to > empty string is ok, though we may want to explore other fixes > (configurable?) -- it affects the Location field in S3 POST response. Yes, I've seen it's used there. Since we have dedicated gw machines, they're at the root / so doesn't matter. BTW, do you know why the stack trace sucks so much ? I mean, it looks especially unhelpful, the function where the crash happen isn't even listed in there at all ... Cheers, Sylvain -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: radosgw segfault in 0.56
Hi all, Created branch wip-3735 to capture Sylvain's patch. On Mon, Jan 7, 2013 at 7:21 AM, Sylvain Munaut wrote: > Hi, > >> As far as I know relying on SCRIPT_URI is rather dangerous since it's not >> always there. >> >> There better should be an if/else-satement surrounding that code having it >> defaulting to something else if SCRIPT_URI isn't available. > > I've opened a bug and proposed a patch setting the default value to "" > > http://tracker.newdream.net/issues/3735 > > Cheers, > > Sylvain > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: radosgw segfault in 0.56
Hi, > As far as I know relying on SCRIPT_URI is rather dangerous since it's not > always there. > > There better should be an if/else-satement surrounding that code having it > defaulting to something else if SCRIPT_URI isn't available. I've opened a bug and proposed a patch setting the default value to "" http://tracker.newdream.net/issues/3735 Cheers, Sylvain -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: radosgw segfault in 0.56
On 01/07/2013 12:04 PM, Sylvain Munaut wrote:
Ok, I tracked this down ...
I'm using lighttpd as a FastCGI front end and it doesn't set
SCRIPT_URI environment.
So the line 1123 in rgw/rgw_rest.cc :
s->script_uri = s->env->get("SCRIPT_URI");
Tries to assign NULL to s->script_uri which crashes with the
particularly unhelpful stack trace I pasted above ...
As far as I know relying on SCRIPT_URI is rather dangerous since it's
not always there.
There better should be an if/else-satement surrounding that code having
it defaulting to something else if SCRIPT_URI isn't available.
That's what I still remember from my PHP-days where SCRIPT_URI was
always a hit-and-miss.
Wido
Cheers,
Sylvain
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: radosgw segfault in 0.56
Ok, I tracked this down ...
I'm using lighttpd as a FastCGI front end and it doesn't set
SCRIPT_URI environment.
So the line 1123 in rgw/rgw_rest.cc :
s->script_uri = s->env->get("SCRIPT_URI");
Tries to assign NULL to s->script_uri which crashes with the
particularly unhelpful stack trace I pasted above ...
Cheers,
Sylvain
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: radosgw segfault in 0.56
Hi, > happened to me using ubuntu packages. > usually when you upgrade a package it calls all its dependencies, for > ceph you have to update one by one. > did you try that ? All ceph packages are up to date. Same happens with a custom compiled radosgw from git Cheers, Sylvain -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: radosgw segfault in 0.56
Hi Sylvain, happened to me using ubuntu packages. usually when you upgrade a package it calls all its dependencies, for ceph you have to update one by one. did you try that ? cheers On Thu, Jan 3, 2013 at 1:54 PM, Sylvain Munaut wrote: > Hi, > > > I've just updated a test cluster to 0.56 and I'm getting a segfault > when doing requests on radosgw : > > root@ceph /var/log/ceph # /usr/bin/radosgw -n client.radosgw.gateway -f > *** Caught signal (Segmentation fault) ** > in thread 7fee095f8700 > ceph version 0.56 (1a32f0a0b42f169a7b55ed48ec3208f6d4edc1e8) > 1: /usr/bin/radosgw() [0x4783da] > 2: (()+0xfcb0) [0x7fee1a112cb0] > 3: (()+0x89101) [0x7fee18d87101] > 4: (RGWREST::preprocess(req_state*, RGWClientIO*)+0x36) [0x44c456] > 5: (RGWREST::get_handler(RGWRados*, req_state*, RGWClientIO*, > int*)+0x3f) [0x44d70f] > 6: (RGWProcess::handle_request(RGWRequest*)+0x18b) [0x4730bb] > 7: (RGWProcess::RGWWQ::_process(RGWRequest*)+0x36) [0x474f66] > 8: (ThreadPool::worker(ThreadPool::WorkThread*)+0x4bc) [0x4908fc] > 9: (ThreadPool::WorkThread::entry()+0x10) [0x492710] > 10: (()+0x7e9a) [0x7fee1a10ae9a] > 11: (clone()+0x6d) [0x7fee18df1cbd] > 2013-01-03 16:48:23.937807 7fee095f8700 -1 *** Caught signal > (Segmentation fault) ** > in thread 7fee095f8700 > > > Anyone seeing something similar to this ? > > > It's a bit more complete with gdb : > > #0 0x74f27101 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x0044c456 in RGWREST::preprocess(req_state*, RGWClientIO*) () > #2 0x0044d70f in RGWREST::get_handler(RGWRados*, req_state*, > RGWClientIO*, int*) () > #3 0x004730bb in RGWProcess::handle_request(RGWRequest*) () > #4 0x00474f66 in RGWProcess::RGWWQ::_process(RGWRequest*) () > #5 0x004908fc in ThreadPool::worker(ThreadPool::WorkThread*) () > #6 0x00492710 in ThreadPool::WorkThread::entry() () > #7 0x762aae9a in start_thread () from > /lib/x86_64-linux-gnu/libpthread.so.0 > #8 0x74f91cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6 > #9 0x in ?? () > > > Cheers, > > Sylvain > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
