serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Zhakov <i...@visualsvn.com>
Subject Re: [serf-dev] [serf] r2489 committed - In preparation of serf 1.4.0, remove the get_remaining function from t...
Date Sat, 12 Sep 2015 16:30:24 GMT
On 12 September 2015 at 19:08, Greg Stein <gstein@gmail.com> wrote:
>
> On Sep 12, 2015 11:01 AM, "Ivan Zhakov" <ivan@visualsvn.com> wrote:
>>
>> On 12 September 2015 at 15:08, Greg Stein <gstein@gmail.com> wrote:
>> > [redirected to dev@serf]
>> >
>> > On Mon, Apr 6, 2015 at 8:32 AM, Bert Huijben <bert@qqmail.nl> wrote:
>> >
>> >> > -----Original Message-----
>> >> > From: serf-dev@googlegroups.com [mailto:serf-dev@googlegroups.com]
On
>> >> > Behalf Of serf@googlecode.com
>> >> > Sent: maandag 6 april 2015 11:25
>> >> > To: serf-dev@googlegroups.com
>> >> > Subject: [serf-dev] [serf] r2489 committed - In preparation of serf
>> >> 1.4.0,
>> >> > remove the get_remaining function from t...
>> >> >
>> >> > Revision: 2489
>> >> > Author:   lieven.govaerts
>> >> > Date:     Mon Apr  6 09:24:18 2015 UTC
>> >> > Log:      In preparation of serf 1.4.0, remove the get_remaining
>> >> > function
>> >> > from the
>> >> > bucket API.
>> >> >
>> >> > This reverts most of r2008, r2009, r2010 and r2198. From r2008 I kept
>> >> > the
>> >> > read_bucket_v2 function, which is needed for set_config.
>> >>
>> >> If we still keep the read_bucket_v2 feature, what is the reason for
>> >> just
>> >> removing get_remaining?
>> >>
>> >>
>> >> We still have to handle the linkage problems if we use the
>> >> read_bucket_v2() system for versioning, but we leave out the tests that
>> >> were added to find problems caused by different function pointers.
>> >>
>> >>
>> >> The reason we see errors on this feature on several platforms is just
>> >> this
>> >> linkage problem, while the get_remaining code itself is pretty stable
>> >> as
>> >> far as I can tell. I'm guessing that the reason for removing the code
>> >> is
>> >> that we see this errors.
>> >>
>> >>
>> >> Our scons scripts make us link both the static library and shared
>> >> library
>> >> versions of the same functions, and then a simple pointer comparison on
>> >> a
>> >> function pointer isn't going to work as expected.
>> >>
>> >>
>> >> And with a shared library build, there are other possible problems:
>> >> sometimes you get a pointer to a wrapping function... or the pointer
>> >> value
>> >> is not guaranteed because the code might be moved under some
>> >> circumstances
>> >> (unload+load of library)
>> >>
>> >
>> > So you're saying that a pointer to a specific function might have *two*
>> > values under Windows? Within a single executable? That A could see a
>> > different value from B?
>> >
>> This is not Windows specific problem, the original problem report was on
>> Linux:
>> "Buckets v2 check doesn't work on Linux in the test suite
>> (test_aggregate_buckets fails)" [1]
>>
>> Bert commented  that serf on Windows had similiar problems, but I
>> don't know details.
>> [1] https://issues.apache.org/jira/browse/SERF-134
>
> That JIRA indicates there are multiple copies of the function, which is
> clearly wrong.
I don't know details, but it seems related how linker, loader and
relocation works on Linux:
http://reverseengineering.stackexchange.com/questions/1992/what-is-plt-got

-- 
Ivan Zhakov

Mime
View raw message