On March 30, 2014 at 4:58 AM Dan Fandrich <dan_at_coneharvesters.com>
wrote:
> On Sat, Mar 29, 2014 at 08:19:02PM -0400, dev wrote:
> > On March 29, 2014 at 5:51 AM Dan Fandrich <dan_at_coneharvesters.com>
> > > 815 and 816 were fixed in git in f82e0edc.
> >
> > I think what you are saying is that those tests fail in the release
> > version. However I can get the un-released dev version from the
> > git tree. I'll have to think about that.
>
> Correct, I was acknowledging that it was a known issue. The daily
> builds up
> to the Mar. 29 one have nothing but bug fixes since the release
> version,
> so those would be good to take.
>

cool.

> > > I'm not aware of any issue with
> > > test 1513, and our Solaris 10 autobuilds don't show any problems
> > > with
> > > that test: http://curl.haxx.se/dev/builds.html
> >
> > I don't see Solaris on that page anywhere.
>
> Someone is doing autobuilds on Solaris SPARC, e.g.
> http://curl.haxx.se/dev/log.cgi?id=20140329134252-32382

testcurl: NAME = Tor
testcurl: EMAIL = notused /at/ arntsen.cx
testcurl: DESC = Solaris 10 SPARC Sun C 5.8 + blastwave
testcurl: NOTES =
testcurl: CONFOPTS = --enable-debug --disable-ipv6 --enable-ares
--without-ssl
testcurl: CPPFLAGS =

Sun was bought out by Oracle and they long since dropped support on that
compiler.
I am using Oracle Studio 12.3 which is the latest however I have gcc
4.8.2. The
reference to "blastwave" is heart warming but somewhat out of date also.

My compilers :

node002$ cc -V
cc: Sun C 5.12 SunOS_sparc 2011/11/16

Yes I know it is a pain to keep it patched and up to date and guys like
Darryl
Gove at Oracle will swear up and down that the free download version is
pretty
damn good. Well, I have to trust him, he is the Oracle/Sun compiler
guru.

node002$ /usr/local/gcc4/bin/gcc --version
gcc (Blastwave.org Inc. Mon Oct 21 15:43:56 GMT 2013) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

That is the reference build GCC compiler port listed on the GNU GCC
compiler build stat page so its pretty solid :

  http://gcc.gnu.org/gcc-4.8/buildstat.html

To do valid testing we need OpenSSL also :

node002$ openssl version
OpenSSL 1.0.1e 11 Feb 2013

I think I had better set up an autobuild environment to help out here
with
both compilers and related libs that are recent and up to date. Let's
face
it, curl/libcurl are *essential* components in the open source world and
they must work. Therefore I better step up to the plate and help here if
I want it to be flawless on production Solaris. Sorry I don't have any
Solaris 10 AMD64/x86 hardware up and running at the moment. I can make
that happen pretty fast but the build of the entire software
infrastructure
for all the other pieces would be a month of work. Or more.

> > I'll see if there is an easy way to pull a tarball and then run the
> > autobuild process. Seems as if there is a daily tarball with the
> > url and file name format thus :
> >
> > http://curl.haxx.se/snapshots/curl-7.37.0-20140329.tar.gz
> >
> > I should set up a nightly process to get the tarball from the
> > previous day and run that autobuild. Not too sure if email will
> > get out the door however, that looks like a network and firewall
> > and who knows what else problem to solve. Lovely.
>
> It would be great if you were to add some more autobuilds to help us
> find
> regressions like this in the future! Note that there is also a web
> form you
> can use to submit results instead of mailing them.

I think that sending outbound email won't be a problem after all. I will
do a few dirt simple tests after I reconfig my firewall and then the
nightly builds should go ahread normally.

I just need to figure out how to get the release version. Looks like I
will do a sed/awk/grep foo on this file :

    https://raw.githubusercontent.com/bagder/curl/master/RELEASE-NOTES

Hopefully that file will always be around and then my nightly builds
will "just run".

May take me a day to set this up and then we will have Solaris 10
nightlys
however I may need to go this twice with both Oracle Studio 12.3 as well
as GCC compiler in order to provide reasonable data.

> [snip]
> > ********* System characteristics ********
> > * curl 7.36.0 (sparc-sun-solaris2.10)
> > * libcurl/7.36.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.26 libssh2/1.4.3
> > * Features: IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
> > * Host: node002
> > * System: SunOS node002 5.10 Generic_150400-01 sun4v sparc
> > SUNW,T5240
> > * Server SSL: OFF libcurl SSL: ON
> > * debug build: OFF track memory: OFF
> > * valgrind: OFF HTTP IPv6 ON
> > * FTP IPv6 ON Libtool lib: OFF
> > * Shared build: yes Resolver: stock
> > * SSL library: OpenSSL
> > * Ports:
> > * HTTP/8990 FTP/8992 FTP2/8995 RTSP/9007
> > * TFTP/8997 HTTP-IPv6/8994 RTSP-IPv6/9008 FTP-IPv6/8996
> > * GOPHER/9009 GOPHER-IPv6/9009
> > * SSH/8999 SOCKS/9000 POP3/9001 IMAP/9003 SMTP/9005
> > * POP3-IPv6/9002 IMAP-IPv6/9004 SMTP-IPv6/9006
> > * HTTPTLS/9011 HTTPTLS-IPv6/9012
> > * HTTP-PIPE/9014
> > *****************************************
> > * starts no server
> > test 1513...[return failure immediately from progress callback]
> > ./libtest/lib1513 http://localhost/1513 >log/stdout1513
> > 2>log/stderr1513
> > CMD (1792): ./libtest/lib1513 http://localhost/1513 >log/stdout1513
> > 2>log/stderr1513
> >
> > lib1513 returned 7, when expecting 42
> > exit FAILED
> >
> > - abort tests
> > TESTDONE: 0 tests out of 1 reported OK: 0%
> > TESTFAIL: These test cases failed: 1513
> > TESTDONE: 1 tests were considered during 0 seconds.
> > gmake[1]: *** [quiet-test] Error 1
> > gmake[1]: Leaving directory
> > `/usr/local/build/curl-7.36.0_SunOS5.10_sparcv9.001/tests'
> > gmake: *** [test] Error 2
> > node002$
> > node002$
> >
> > Not really all that helpful is it?
>
> It's a libtest, so there's not much in the way of logging. But, this
> is still
> helpful. 42 is CURLE_ABORTED_BY_CALLBACK, which is the point of this
> test.
> 7 is CURLE_COULDNT_CONNECT, which is what you'd get if the transfer
> was not
> aborted and attempted to use the deliberately invalid URL in the test.

If I knew where to look and can setup the required environment then I
could
single step into the whole thing and nail it down.

> > Let me know what seems reasonable to do here and I will try to get
> > it
> > done.
>
> It appears that for some reason the CURLOPT_PROGRESSFUNCTION callback
> isn't
> being called (or the return code is being ignored) before the transfer
> is
> attempted. You could try this:
>
> 1) Put a breakpoint on progressKiller() and see if it's actually
> called. If so,
> why is the return value ignored.
>
> 2) Put a breakpoint on the call to Curl_pgrsUpdate near the end of
> multi_runsingle in multi.c and see why the callback at line 376 isn't
> being
> called.

okay .. will do and I'll see what I see. I will just try to run lib1513
but there
is a LOT going on :

node002$ ldd ./tests/libtest/.libs/lib1513
        libcurl.so.4 => /usr/local/lib/libcurl.so.4
        libidn.so.11 => /usr/local/lib/libidn.so.11
        libintl.so.8 => /usr/local/lib/libintl.so.8
        libc.so.1 => /lib/64/libc.so.1
        libiconv.so.2 => /usr/local/lib/libiconv.so.2
        libssh2.so.1 => /usr/local/lib/libssh2.so.1
        libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0
        libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0
        libldap.so.5 => /usr/lib/64/libldap.so.5
        libz.so.1 => /usr/local/lib/libz.so.1
        librt.so.1 => /lib/64/librt.so.1
        libsocket.so.1 => /lib/64/libsocket.so.1
        libnsl.so.1 => /lib/64/libnsl.so.1
        libdl.so.1 => /lib/64/libdl.so.1
        libsasl.so.1 => /usr/lib/64/libsasl.so.1
        libmd.so.1 => /lib/64/libmd.so.1
        libnspr4.so => /usr/lib/mps/64/libnspr4.so
        libplc4.so => /usr/lib/mps/64/libplc4.so
        libnss3.so => /usr/lib/mps/64/libnss3.so
        libssl3.so => /usr/lib/mps/64/libssl3.so
        libaio.so.1 => /lib/64/libaio.so.1
        libmp.so.2 => /lib/64/libmp.so.2
        libscf.so.1 => /lib/64/libscf.so.1
        libpthread.so.1 => /lib/64/libpthread.so.1
        libnssutil3.so => /usr/lib/mps/sparcv9/libnssutil3.so
        libplds4.so => /usr/lib/mps/sparcv9/libplds4.so
        libthread.so.1 => /lib/64/libthread.so.1
        libdoor.so.1 => /lib/64/libdoor.so.1
        libuutil.so.1 => /lib/64/libuutil.so.1
        libgen.so.1 => /lib/64/libgen.so.1
        libm.so.2 => /lib/64/libm.so.2
        /platform/SUNW,T5240/lib/sparcv9/libc_psr.so.1
        /platform/SUNW,T5240/lib/sparcv9/libmd_psr.so.1

Should be fun.

> It sounds like some kind of race condition somewhere, but it shouldn't
> be too
> difficult to get to the root of.

Well thank you for the pointers ( no pun intended ) and I will start
hunting
around. Also I will look into getting a nightly build going within my
environment and give serious thought to getting a Solaris AMD64/x86
server
up and running.

Dennis
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-03-30