Buildfarm member mussel (OS X 10.7.3, llvm-gcc 4.2.1, x86_64)seems to be
getting consistent warnings when running the pgcrypto regression tests,
that look like this:

WARNING: detected write past chunk end in ExprContext 0x7fec2b11eb58

Does anyone have an idea why that might be?

cheers

andrew

Search Discussions

  • Marko Kreen at Mar 9, 2012 at 10:43 pm

    On Fri, Mar 09, 2012 at 05:28:20PM -0500, Andrew Dunstan wrote:
    Buildfarm member mussel (OS X 10.7.3, llvm-gcc 4.2.1, x86_64)seems
    to be getting consistent warnings when running the pgcrypto
    regression tests, that look like this:

    WARNING: detected write past chunk end in ExprContext 0x7fec2b11eb58

    Does anyone have an idea why that might be?
    Could it be related to this:

    openssl.c:840: warning: AES_cbc_encrypt is deprecated (declared
    at /usr/include/openssl/aes.h:106)

    basically every API under /usr/include/openssl gives this warning.
    Replaced or heavily hacked openssl library?

    Same for core code:

    be-secure.c:329: warning: SSL_renegotiate is deprecated
    (declared at /usr/include/openssl/ssl.h:1530)

    Could someone take a look whats going on there?

    --
    marko
  • Tom Lane at Mar 10, 2012 at 12:50 am

    Andrew Dunstan writes:
    Buildfarm member mussel (OS X 10.7.3, llvm-gcc 4.2.1, x86_64)seems to be
    getting consistent warnings when running the pgcrypto regression tests,
    that look like this:
    WARNING: detected write past chunk end in ExprContext 0x7fec2b11eb58
    Does anyone have an idea why that might be?
    Worksforme, on an up-to-date Lion system using exactly the same
    compiler version. I do see the deprecation warnings (which Apple
    seems to have plastered on every single OpenSSL function ... doesn't
    leave me with a warm feeling about their future plans).

    I suspect that mussel has an ABI-incompatible openssl library hanging
    around someplace. On my machine "otool -L pgcrypto.so" shows

    /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 44.0.0)

    It'd be interesting to know what it says on mussel.

    regards, tom lane
  • Andrew Dunstan at Mar 10, 2012 at 11:20 pm

    On 03/09/2012 07:50 PM, Tom Lane wrote:
    Andrew Dunstan<andrew@dunslane.net> writes:
    Buildfarm member mussel (OS X 10.7.3, llvm-gcc 4.2.1, x86_64)seems to be
    getting consistent warnings when running the pgcrypto regression tests,
    that look like this:
    WARNING: detected write past chunk end in ExprContext 0x7fec2b11eb58
    Does anyone have an idea why that might be?
    Worksforme, on an up-to-date Lion system using exactly the same
    compiler version. I do see the deprecation warnings (which Apple
    seems to have plastered on every single OpenSSL function ... doesn't
    leave me with a warm feeling about their future plans).

    I suspect that mussel has an ABI-incompatible openssl library hanging
    around someplace. On my machine "otool -L pgcrypto.so" shows

    /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 44.0.0)

    It'd be interesting to know what it says on mussel.

    Robert, please investigate.

    cheers

    andrew
  • Robert Creager at Mar 10, 2012 at 11:45 pm

    On Mar 10, 2012, at 4:19 PM, Andrew Dunstan wrote:
    On 03/09/2012 07:50 PM, Tom Lane wrote:
    Andrew Dunstan<andrew@dunslane.net> writes:
    Buildfarm member mussel (OS X 10.7.3, llvm-gcc 4.2.1, x86_64)seems to be
    getting consistent warnings when running the pgcrypto regression tests,
    that look like this:
    WARNING: detected write past chunk end in ExprContext 0x7fec2b11eb58
    Does anyone have an idea why that might be?
    Worksforme, on an up-to-date Lion system using exactly the same
    compiler version. I do see the deprecation warnings (which Apple
    seems to have plastered on every single OpenSSL function ... doesn't
    leave me with a warm feeling about their future plans).

    I suspect that mussel has an ABI-incompatible openssl library hanging
    around someplace. On my machine "otool -L pgcrypto.so" shows

    /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 44.0.0)

    It'd be interesting to know what it says on mussel.

    Robert, please investigate.
    creagers-imac:pgcrypto Robert$ otool -L pgcrypto.so
    pgcrypto.so:
    /opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)

    via Mac Ports
    cheers

    andrew
  • Tom Lane at Mar 11, 2012 at 12:02 am

    Robert Creager writes:
    On Mar 10, 2012, at 4:19 PM, Andrew Dunstan wrote:
    On 03/09/2012 07:50 PM, Tom Lane wrote:
    I suspect that mussel has an ABI-incompatible openssl library hanging
    around someplace. On my machine "otool -L pgcrypto.so" shows
    /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 44.0.0)
    It'd be interesting to know what it says on mussel.
    creagers-imac:pgcrypto Robert$ otool -L pgcrypto.so
    pgcrypto.so:
    /opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
    Uh-huh. I will bet a good deal that you are compiling against the
    Apple-supplied openssl header files, but then linking against the
    MacPorts openssl shlib, which evidently is configured a bit differently
    than Apple's copy.

    [ pokes around in the mussel build logs ] I see "-L/opt/local/lib"
    in the link commands, which explains why you're linking to that shlib,
    and I don't see anything like "-I/opt/local/include", which is probably
    needed to find the matching header files. There is a
    "-I/opt/local/include/libxml2", but that isn't going to help unless your
    /opt/local layout is really weird.

    What's really odd though is that there is nothing in the configuration
    script that injects any of those switches. I think you've got some
    screwy global configuration on that machine, which you'd be well advised
    to try to get rid of --- it's tough for people to do remote diagnosis of
    buildfarm critters when there's relevant configuration that's not
    exposed in the config script.

    regards, tom lane
  • Robert Creager at Mar 11, 2012 at 1:07 am

    On Mar 10, 2012, at 5:01 PM, Tom Lane wrote:

    What's really odd though is that there is nothing in the configuration
    script that injects any of those switches. I think you've got some
    screwy global configuration on that machine, which you'd be well advised
    to try to get rid of --- it's tough for people to do remote diagnosis of
    buildfarm critters when there's relevant configuration that's not
    exposed in the config script.
    No global config. Changed the path around to have /opt/local after the standard Apple ones, and it appears to be working fine. autoconf must be throwing in that path based on executables found?

    Later,
    Rob
  • Tom Lane at Mar 11, 2012 at 2:16 am

    Robert Creager writes:
    On Mar 10, 2012, at 5:01 PM, Tom Lane wrote:
    What's really odd though is that there is nothing in the configuration
    script that injects any of those switches. I think you've got some
    screwy global configuration on that machine, which you'd be well advised
    to try to get rid of --- it's tough for people to do remote diagnosis of
    buildfarm critters when there's relevant configuration that's not
    exposed in the config script.
    No global config. Changed the path around to have /opt/local after the standard Apple ones, and it appears to be working fine. autoconf must be throwing in that path based on executables found?
    I don't believe autoconf would insert such stuff on its own authority.
    I'm wondering about CPPFLAGS, CFLAGS, LDFLAGS or similar variables being
    set in the environment that the buildfarm script is running in.
    Take a look at ~/.bash_profile and suchlike files.

    (I wonder whether it'd be a good idea for the buildfarm script to
    explicitly clear anything that autoconf pays attention to from its
    startup environment, so that you have to set these variables in the
    buildfarm config to make them have effect. If not that, maybe print
    "env" output to document what the situation is?)

    regards, tom lane
  • Robert Creager at Mar 11, 2012 at 2:52 am

    On Mar 10, 2012, at 7:15 PM, Tom Lane wrote:

    Robert Creager <robert@logicalchaos.org> writes:
    On Mar 10, 2012, at 5:01 PM, Tom Lane wrote:
    What's really odd though is that there is nothing in the configuration
    script that injects any of those switches. I think you've got some
    screwy global configuration on that machine, which you'd be well advised
    to try to get rid of --- it's tough for people to do remote diagnosis of
    buildfarm critters when there's relevant configuration that's not
    exposed in the config script.
    No global config. Changed the path around to have /opt/local after the standard Apple ones, and it appears to be working fine. autoconf must be throwing in that path based on executables found?
    I don't believe autoconf would insert such stuff on its own authority.
    I'm wondering about CPPFLAGS, CFLAGS, LDFLAGS or similar variables being
    set in the environment that the buildfarm script is running in.
    Take a look at ~/.bash_profile and suchlike files.
    Nope. Only PATH is set.


    Later,
    Rob
  • Tom Lane at Mar 11, 2012 at 5:32 am

    Robert Creager writes:
    On Mar 10, 2012, at 7:15 PM, Tom Lane wrote:
    I don't believe autoconf would insert such stuff on its own authority.
    I'm wondering about CPPFLAGS, CFLAGS, LDFLAGS or similar variables being
    set in the environment that the buildfarm script is running in.
    Take a look at ~/.bash_profile and suchlike files.
    Nope. Only PATH is set.
    Hmm ... [ eyeballs the mussel build reports some more ] ... ah-hah,
    look at this (at the bottom of the "configure" step for the last
    failed build):

    configure: using CPPFLAGS= -I/opt/local/include/libxml2
    configure: using LDFLAGS= -L/opt/local/lib -Wl,-dead_strip_dylibs

    versus this in the first successful build:

    configure: using CPPFLAGS= -I/usr/include/libxml2
    configure: using LDFLAGS= -Wl,-dead_strip_dylibs

    I will bet that those -I and -L switches are coming from this part of
    configure.in:

    if test "$with_libxml" = yes ; then
    AC_CHECK_PROGS(XML2_CONFIG, xml2-config)
    if test -n "$XML2_CONFIG"; then
    for pgac_option in `$XML2_CONFIG --cflags`; do
    case $pgac_option in
    -I*|-D*) CPPFLAGS="$CPPFLAGS $pgac_option";;
    esac
    done
    for pgac_option in `$XML2_CONFIG --libs`; do
    case $pgac_option in
    -L*) LDFLAGS="$LDFLAGS $pgac_option";;
    esac
    done
    fi
    fi

    So the answer is that you've got a MacPorts libxml2 installation
    whose xml2-config program inserts these not terribly self-consistent
    switches, resulting in drive-by failure of the openssl configuration.
    When you switched your PATH around, instead of finding the MacPorts
    copy of xml2-config, configure found the one in /usr/bin, which
    provides "-I/usr/include/libxml2" and no particular -L switch;
    hence no openssl problem. You're building with a different libxml2
    than you were before, though.

    Seems to me this is a MacPorts bug: their libxml2 and openssl packagings
    don't play nice together.

    regards, tom lane
  • Andrew Dunstan at Mar 11, 2012 at 2:55 am

    On 03/10/2012 09:15 PM, Tom Lane wrote:
    (I wonder whether it'd be a good idea for the buildfarm script to
    explicitly clear anything that autoconf pays attention to from its
    startup environment, so that you have to set these variables in the
    buildfarm config to make them have effect. If not that, maybe print
    "env" output to document what the situation is?)
    I can put the latter in the next client release, unless people think
    it's a bit insecure to report arbitrary environment values. If we were
    to clear them, which would we clear?

    cheers

    andrew
  • Robert Creager at Mar 11, 2012 at 3:01 am

    On Mar 10, 2012, at 7:54 PM, Andrew Dunstan wrote:


    On 03/10/2012 09:15 PM, Tom Lane wrote:

    (I wonder whether it'd be a good idea for the buildfarm script to
    explicitly clear anything that autoconf pays attention to from its
    startup environment, so that you have to set these variables in the
    buildfarm config to make them have effect. If not that, maybe print
    "env" output to document what the situation is?)
    I can put the latter in the next client release, unless people think it's a bit insecure to report arbitrary environment values. If we were to clear them, which would we clear?
    Why it just report the pertinent ones?


    Rob
  • Tom Lane at Mar 11, 2012 at 5:34 am

    Andrew Dunstan writes:
    On 03/10/2012 09:15 PM, Tom Lane wrote:
    (I wonder whether it'd be a good idea for the buildfarm script to
    explicitly clear anything that autoconf pays attention to from its
    startup environment, so that you have to set these variables in the
    buildfarm config to make them have effect. If not that, maybe print
    "env" output to document what the situation is?)
    I can put the latter in the next client release, unless people think
    it's a bit insecure to report arbitrary environment values. If we were
    to clear them, which would we clear?
    I think it'd be useful to print CPPFLAGS, CFLAGS, and LDFLAGS if the
    environment is supplying values for them (or maybe print their values
    after absorbing whatever is in the buildfarm animal's config).
    Peter might know whether there's anything else of great interest.

    regards, tom lane
  • Peter Eisentraut at Mar 11, 2012 at 12:00 pm

    On sön, 2012-03-11 at 00:34 -0500, Tom Lane wrote:
    I think it'd be useful to print CPPFLAGS, CFLAGS, and LDFLAGS if the
    environment is supplying values for them (or maybe print their values
    after absorbing whatever is in the buildfarm animal's config).
    Peter might know whether there's anything else of great interest.
    The ones that we have designated as pertinent are listed at the bottom
    of configure --help.

    But you can actually see the values that these had in the environment by
    looking in config.log under ac_cv_env_*.
  • Andrew Dunstan at Mar 11, 2012 at 1:20 pm

    On 03/11/2012 08:00 AM, Peter Eisentraut wrote:
    On sön, 2012-03-11 at 00:34 -0500, Tom Lane wrote:
    I think it'd be useful to print CPPFLAGS, CFLAGS, and LDFLAGS if the
    environment is supplying values for them (or maybe print their values
    after absorbing whatever is in the buildfarm animal's config).
    Peter might know whether there's anything else of great interest.
    The ones that we have designated as pertinent are listed at the bottom
    of configure --help.

    But you can actually see the values that these had in the environment by
    looking in config.log under ac_cv_env_*.

    Yeah, so there's nothing really to do here. And in the case of the
    failures we saw, nothing was set, so Tom's analysis of the failure
    coming from Macports libxml2 looks correct.

    cheers

    andrew

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMar 9, '12 at 10:28p
activeMar 11, '12 at 1:20p
posts15
users5
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase