You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Simon Walter <si...@gikaku.com> on 2018/01/01 13:37:21 UTC
[users@httpd] apr_bucket_split data remains
I am interested in how apr_bucket_split(e, point) works.
It seems that after splitting e, it still contains everything after
point. Only when flattened is this data "removed" from e.
If that is correct, then is it also correct to assume that I would need
to use apr_bucket_read with snprintf and make a copy of the data in
order to display it accurately?
Is there another way to show the contents of buckets after they've been
split/manipulated?
I need to flatten the brigade (or flush it to a socket? that's a
different question), but for debugging purposes, to check my logic, I am
trying to see the contents of individual buckets.
Kind regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] apr_bucket_split data remains
Posted by Simon Walter <si...@gikaku.com>.
On 01/02/2018 09:10 PM, Yann Ylavic wrote:
> printf("%.*s", (int)len, str)
Now I understand that part of the man page. Very nice of you, Yann.
Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] apr_bucket_split data remains
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Jan 2, 2018 at 12:45 PM, Simon Walter <si...@gikaku.com> wrote:
>
> It looks like apr_bucket_read returns the memory location of the
> original string and does no manipulation like null termination when
> splitting.
>
> So I guess that I cannot simply call printf, and that I must either use
> putchar with a loop or snprintf, strncpy, memcpy, etc.
Or you could use a format like "printf("%.*s", (int)len, str)" to take
the length returned by apr_bucket_read into account.
Regards,
Yann.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] apr_bucket_split data remains
Posted by Eric Covener <co...@gmail.com>.
On Tue, Jan 2, 2018 at 6:45 AM, Simon Walter <si...@gikaku.com> wrote:
> Yes, thanks for looking at it, Eric. It is correct after I flatten it:
>
> output:
> _ASCII_String0_!__ASCII_String4_!ASCII_String1_!_ASCII_String2_!_ASCII_String3_!
>
> but not when reading the bucket with apr_bucket_read(Index, &TestBuffer,
> &Length, APR_BLOCK_READ):
>
> Marker: 1
> CurrBucket: _ASCII_String1_!
> Length: 1
>
> Bucket1 is not just "_".
Sorry, I lost track of the pre/post flatten aspect.
> It looks like apr_bucket_read returns the memory location of the
> original string and does no manipulation like null termination when
> splitting.
> So I guess that I cannot simply call printf, and that I must either use
> putchar with a loop or snprintf, strncpy, memcpy, etc.
Ah yes, that makes sense. See for example what very little happens
when you split or read from a heap bucket:
APU_DECLARE_NONSTD(apr_status_t) apr_bucket_simple_split(apr_bucket *a,
apr_size_t point)
{
apr_bucket *b;
if (point > a->length) {
return APR_EINVAL;
}
apr_bucket_simple_copy(a, &b);
a->length = point;
b->length -= point;
b->start += point;
APR_BUCKET_INSERT_AFTER(a, b);
return APR_SUCCESS;
}
static apr_status_t heap_bucket_read(apr_bucket *b, const char **str,
apr_size_t *len, apr_read_type_e block)
{
apr_bucket_heap *h = b->data;
*str = h->base + b->start;
*len = b->length;
return APR_SUCCESS;
}
For the transient bucket query, you could try allocating the strings
on the stack, then return and try to read them (without using string
literals or strdup to potentially confuse things)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] apr_bucket_split data remains
Posted by Simon Walter <si...@gikaku.com>.
Yes, thanks for looking at it, Eric. It is correct after I flatten it:
output:
_ASCII_String0_!__ASCII_String4_!ASCII_String1_!_ASCII_String2_!_ASCII_String3_!
but not when reading the bucket with apr_bucket_read(Index, &TestBuffer,
&Length, APR_BLOCK_READ):
Marker: 1
CurrBucket: _ASCII_String1_!
Length: 1
Bucket1 is not just "_".
It looks like apr_bucket_read returns the memory location of the
original string and does no manipulation like null termination when
splitting.
So I guess that I cannot simply call printf, and that I must either use
putchar with a loop or snprintf, strncpy, memcpy, etc.
One of the reasons for this exercise is to understand the difference
between transient and immortal buckets. I don't get memory errors when
running valgrind and mis-matching the transient, immortal, and even pool
buckets with the memory they were used to create them.
I don't want to embark on using this library without a good
understanding of what is going on. I have a better idea now, but still
many questions remain.
I looked at http://www.apachetutor.org/dev/brigades, but that doesn't
explain much. The tests in the source code archive helped a bit. Is
there any good reading about this on the interwebs? ;)
Simon
On 01/02/2018 12:51 AM, Eric Covener wrote:
>> I see such code as the example you gave in various places. However, this
>> bit of code (attached) shows me that I cannot simply printf the data.
>> Again, I am probably doing something wrong.
>>
>
> The output looks right to me but maybe I am misunderstanding the
> intent of the example.
>
> output: _ASCII_String0_!__ASCII_String4_!ASCII_String1_!_ASCII_String2_!_ASCII_String3_!
> ^ extra underscore is b1
> ^ b4 inserted heree
> ^
> b1_1 and the missing underscore from the split and
>
>
> You start with b0,b1,b2,b3 and iterate over the brigade.
>
> While looking at b1, you split it at index 1 into two buckets. b1 is
> now just "_" and b1_1 is the rest.
>
> b0, b1, b1_1, b2, b3
>
> You then insert b4 after b1:
>
> b0, b1, b1_1, b2, b3
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
Re: [users@httpd] apr_bucket_split data remains
Posted by Eric Covener <co...@gmail.com>.
> I see such code as the example you gave in various places. However, this
> bit of code (attached) shows me that I cannot simply printf the data.
> Again, I am probably doing something wrong.
>
The output looks right to me but maybe I am misunderstanding the
intent of the example.
output: _ASCII_String0_!__ASCII_String4_!ASCII_String1_!_ASCII_String2_!_ASCII_String3_!
^ extra underscore is b1
^ b4 inserted heree
^
b1_1 and the missing underscore from the split and
You start with b0,b1,b2,b3 and iterate over the brigade.
While looking at b1, you split it at index 1 into two buckets. b1 is
now just "_" and b1_1 is the rest.
b0, b1, b1_1, b2, b3
You then insert b4 after b1:
b0, b1, b1_1, b2, b3
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] apr_bucket_split data remains
Posted by Simon Walter <si...@gikaku.com>.
On 01/01/2018 10:44 PM, Eric Covener wrote:
> On Mon, Jan 1, 2018 at 8:37 AM, Simon Walter <si...@gikaku.com> wrote:
>> I am interested in how apr_bucket_split(e, point) works.
>>
>> It seems that after splitting e, it still contains everything after
>> point. Only when flattened is this data "removed" from e.
>>
>> If that is correct, then is it also correct to assume that I would need
>> to use apr_bucket_read with snprintf and make a copy of the data in
>> order to display it accurately?
>>
>> Is there another way to show the contents of buckets after they've been
>> split/manipulated?
>>
>> I need to flatten the brigade (or flush it to a socket? that's a
>> different question), but for debugging purposes, to check my logic, I am
>> trying to see the contents of individual buckets.
>>
>
> I don't think that's right. For example mod_substitute does this to
> remove the pattern that matched from the input:
>
> #define SEDRMPATBCKT(b, offset, tmp_b, patlen) do { \
> apr_bucket_split(b, offset); \
> tmp_b = APR_BUCKET_NEXT(b); \
> apr_bucket_split(tmp_b, patlen); \
> b = APR_BUCKET_NEXT(tmp_b); \
> apr_bucket_delete(tmp_b); \
> } while (0)
>
>
> The dump_brigade macro in .gdbinit in the source tree will help here.
> You can also use the code there to add your own trace.
>
I see such code as the example you gave in various places. However, this
bit of code (attached) shows me that I cannot simply printf the data.
Again, I am probably doing something wrong.
Re: [users@httpd] apr_bucket_split data remains
Posted by Eric Covener <co...@gmail.com>.
On Mon, Jan 1, 2018 at 8:37 AM, Simon Walter <si...@gikaku.com> wrote:
> I am interested in how apr_bucket_split(e, point) works.
>
> It seems that after splitting e, it still contains everything after
> point. Only when flattened is this data "removed" from e.
>
> If that is correct, then is it also correct to assume that I would need
> to use apr_bucket_read with snprintf and make a copy of the data in
> order to display it accurately?
>
> Is there another way to show the contents of buckets after they've been
> split/manipulated?
>
> I need to flatten the brigade (or flush it to a socket? that's a
> different question), but for debugging purposes, to check my logic, I am
> trying to see the contents of individual buckets.
>
I don't think that's right. For example mod_substitute does this to
remove the pattern that matched from the input:
#define SEDRMPATBCKT(b, offset, tmp_b, patlen) do { \
apr_bucket_split(b, offset); \
tmp_b = APR_BUCKET_NEXT(b); \
apr_bucket_split(tmp_b, patlen); \
b = APR_BUCKET_NEXT(tmp_b); \
apr_bucket_delete(tmp_b); \
} while (0)
The dump_brigade macro in .gdbinit in the source tree will help here.
You can also use the code there to add your own trace.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org