Jeremy, Thank you very much for your response, Did I tell you it took around 3 hours to get the failure point? It also brought the CPU to it's knees, xload reported like 20 bars. Also, libcrypto.a is only about 5MB when it has been successfully compiled, mine was growing over 11GB when it stopped.
I have successfully compiled it on another server, with a lower patch set. We are in the process of trying to discover what OS Patch caused the issue. See comments below > -----Original Message----- > From: Jeremy Hunt [mailto:jere...@optimation.com.au] > Sent: Tuesday, July 17, 2012 10:02 PM > To: openssl-users@openssl.org > Cc: Barone, Philip > Subject: Re: Make issue with openssl-1.0.0f and openssl-1.0.0j > > > The error message is all important. > > ar: ../../libcrypto.a: cannot write: Bad address > > Bad address is an invalid pointer, cannot write means some access or > system error, which an invalid pointer can be an instance of. > > Seeing as you can use ar to read to this file, I assume it is there, > even though it is truncated (which is a clue in itself). > [Barone, Philip] This compile is being performed in a ClearCase vob, a version control system that my company uses, perhaps you have heard of it. Anyway, in the course of this compile as the file grows and whatever else goes on, access to this file area does seem to change. The view that the compile is performed in, after it stops, can no longer stat libcrypto.a. I am guessing because it has grown too large, not because there is not enough space in the filesystem. File system space is very large now, 64GB. I can access the file fine if I open another window and set the view again. Of course the make had never completed so is incomplete. This is what I get when I try to stat libcrypto.a in the bad view Server1> ls -la ls: libcrypto.a: Value too large for defined data type total 985 In the new window it works fine Server1> ls -la libcrypto.a -rw-rw-r-- 1 pbarone dags 11534025632 Jul 16 15:06 libcrypto.a > Check that the address used (../../libcrypto.a) points to it from > /vobs/IAS_Software_3/COTS/openssl/openssl-1.0.0j/crypto/sha, though it > looks right and I would expect the ar command would create a new one if > it didn't find it. > [Barone, Philip] Yep, like above, it's accessible from the new window but gets the "Value too large" error from the bad view. > Make sure that the components sha_dgst.o sha1dgst.o sha_one.o > sha1_one.o sha256.o sha512.o sha1-sparcv9.o sha256-sparcv9.o sha512- > sparcv9.o have all been created, though I would expect the make would > have failed earlier if any didn't exist. > [Barone, Philip] They are all there Server1> find . -name '*.o' |more ./crypto/md4/md4_dgst.o ./crypto/md4/md4_one.o ./crypto/md5/md5_dgst.o ./crypto/md5/md5_one.o ./crypto/objects/o_names.o ./crypto/objects/obj_dat.o ./crypto/objects/obj_lib.o ./crypto/objects/obj_err.o ./crypto/objects/obj_xref.o ./crypto/sha/sha_dgst.o ./crypto/sha/sha1dgst.o ./crypto/sha/sha_one.o ./crypto/sha/sha1_one.o ./crypto/sha/sha256.o ./crypto/sha/sha512.o ./crypto/sha/sha1-sparcv9.o ./crypto/sha/sha256-sparcv9.o ./crypto/sha/sha512-sparcv9.o ./crypto/cryptlib.o ./crypto/mem.o ./crypto/mem_dbg.o ./crypto/cversion.o ./crypto/ex_data.o ./crypto/cpt_err.o ./crypto/ebcdic.o ./crypto/uid.o ./crypto/o_time.o ./crypto/o_str.o ./crypto/o_dir.o ./crypto/sparcv9cap.o ./crypto/sparccpuid.o > Make sure that you have read access to the components and that you have > write access to /vobs/IAS_Software_3/COTS/openssl/openssl-1.0.0j though > I expect you will, unless you use two user ids to build software with > and an earlier make was interrupted, in which case user id 1 may have > write access to libcrypto.a and you don't. > [Barone, Philip] This is ok > Make sure you have no disk write errors in your system logs. There was > some talk of the file system being full, if this was an issue, how much > space do you have left, under Solaris some percentage (I think it is > 10%) is left as only writeable by "root" user to try and stop system > crashes due to full file systems. Is this disk a virtual or remotely > mounted file system? There may be an issue due to that. > [Barone, Philip] Plenty of space now in these latest tests > You might also like to try writing to libcrypto.a with ar too to see if > there is an error. The build has been interrupted, so the file has to > be > removed anyway, so nothing lost if you corrupt it further. If you can. > try writing to it (with ar) from the directory you had problems with > /vobs/IAS_Software_3/COTS/openssl/openssl-1.0.0j/crypto/sha. > [Barone, Philip] I would try this suggestion but am not sure how to write using ar. Do I just use the exact same command line but add another .o or something on the end? e.g. ar r ../../libcrypto.a sha_dgst.o sha1dgst.o sha_one.o sha1_one.o some_other_file.o I am sure this will fail, it may cause the "Value too large" error in the new view, rendering it unusable afterwards and in the bad view not even start because of the already existing "Value too large" error. > If you can find nothing wrong, then try unpacking openssl-1.0.0j > somewhere else (with lots of room) and rebuilding, see if that works > [Barone, Philip] I did this on another server that was at the same OS patch level and it failed the same way and on a system with an older patch set and it worked! We are now currently looking at OS patches that may be causing this. > Good luck, I hope that little task list helps you find your problem. > > Jeremy > > Barone, Philip wrote: > >> -----Original Message----- > >> From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > >> us...@openssl.org] On Behalf Of Jakob Bohm > >> Sent: Tuesday, July 17, 2012 1:03 PM > >> To: openssl-users@openssl.org > >> Subject: Re: Make issue with openssl-1.0.0f and openssl-1.0.0j > >> > >> On 7/17/2012 6:22 PM, Barone, Philip wrote: > >>> Hi, > >>> I am having issues make'ing openssl-1.0.0j, f fails as well, on > >>> Solaris Patch level "5.10 Generic_147440-13 sparc". It works fine > at > >>> OS patch level "5.10 Generic_125100-10 sparc". > >>> I am compiling this using "solaris64-sparcv9-cc" like I have always > >> done. > >>> It fails trying to create libcrypto.a, > >>> I notice that libcrypto.a is over 11GB when the make finally quits. > >>> This is what it looks like when it quits: > >>> ... > >>> /apps/sun_studio_10_p2/SUNWspro/bin/cc -I.. -I../.. -I../asn1 - > >> I../evp > >>> -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN > >>> -DHAVE_DLFCN_H -xtarget=ultra -xarch=v9 -xO5 -xstrconst -xdepend - > Xa > >>> -DB_ENDIAN -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM - > DSHA512_ASM > >>> -DAES_ASM -c -o sha512-sparcv9.o sha512-sparcv9.s > >>> ar r ../../libcrypto.a sha_dgst.o sha1dgst.o sha_one.o sha1_one.o > >>> sha256.o sha512.o sha1-sparcv9.o sha256-sparcv9.o sha512-sparcv9.o > >>> ar: ../../libcrypto.a: cannot write: Bad address > >>> make[2]: *** [lib] Error 2 > >>> make[2]: Leaving directory > >>> `/vobs/IAS_Software_3/COTS/openssl/openssl-1.0.0j/crypto/sha' > >>> make[1]: *** [subdirs] Error 1 > >>> make[1]: Leaving directory > >>> `/vobs/IAS_Software_3/COTS/openssl/openssl-1.0.0j/crypto' > >>> make: *** [build_crypto] Error 1 > >>> I was wondering if there are any other Solaris guys out there that > >> may > >>> have input on this? > >>> > > [Barone, Philip] > > Jakob, Thanks for the quick reply, see my responses below. > > > >> Not a Solaris guy, but here are two things to check with this > >> set of error messages: > >> > >> 1. Is the disk full due to this unreasonably large .a file? > >> > > [Barone, Philip] > > > > I did have disk space issues at first, because of the size, but was > able to free up more than enough space to get this to run to > completion. > > > > > >> 2. Does the 11GB .a file contain multiple copies of each .o > >> file, perhaps every version you ever compiled? (You can test > >> this with the command $ ar -t libcrypto.a > >> > > [Barone, Philip] > > > > This does not appear to be the issue either > > > > Server1> ar -t libcrypto.a > > cryptlib.o > > mem.o > > mem_dbg.o > > cversion.o > > ex_data.o > > cpt_err.o > > ebcdic.o > > uid.o > > o_time.o > > o_str.o > > o_dir.o > > sparcv9cap.o > > sparccpuid.o > > o_names.o > > obj_dat.o > > obj_lib.o > > obj_err.o > > obj_xref.o > > md4_dgst.o > > md4_one.o > > md5_dgst.o > > md5_one.o > > > > > >> If the second is true, then there is a bug in how make > >> invokes ar when an .o file has been recompiled. The > >> workaround would then be to do a clean build every time. > >> > >> Enjoy > >> > >> Jakob > >> -- > >> Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com > >> Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 > >> This public discussion message is non-binding and may contain > errors. > >> WiseMo - Remote Service Management for PCs, Phones and Embedded > >> > >> > ______________________________________________________________________ > >> OpenSSL Project > http://www.openssl.org > >> User Support Mailing List openssl- > us...@openssl.org > >> Automated List Manager > majord...@openssl.org > > > ______________________________________________________________________ > > OpenSSL Project > http://www.openssl.org > > User Support Mailing List openssl- > us...@openssl.org > > Automated List Manager > majord...@openssl.org > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
