On Sun, Oct 2, 2011 at 8:42 PM, Jeffrey Walton <[email protected]> wrote:
> > > On Oct 2, 3:30 pm, David Irvine <[email protected]> wrote: > > On Sun, Oct 2, 2011 at 7:39 PM, Jeffrey Walton <[email protected]> > wrote: > > > > > On Sep 27, 4:41 pm, David Irvine <[email protected]> wrote: > > > > Hi > > > > > > I am testing gcc 4.6 and found what appears to be a bug. If I use > > > > CryptoPP::AutoSeededX917RNG< CryptoPP::AES > > > > > g_srandom_number_generator; > > > > (any cypher fails) > > > > > > Then it's a segfault (see below) > > > > > > However switching to (which I do not want to do, or more likely > > > > cannot) > > > > CryptoPP::AutoSeededRandomPool g_srandom_number_generator; > > > > > > Is fine, if not as secure. > > > > > ######################################################################## > > > > System is Linux > > > > Linux di-ubuntu-64 3.0.0-11-generic #18-Ubuntu SMP Tue Sep 13 > 23:38:01 > > > > UTC 2011 x86_64 x86_64 x86_64 GNU/Linux > > > > Ubuntu oneiric (development branch) > > > > > > I am not wishing to make too much of this as this is a beta release > > > > OS, but it seems more of a cryptopp issue I think. Is anyone else > > > > using ? > > > > gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 > > > > Copyright (C) 2011 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 > > > > > > Segfault below > > > > > > #0 0x000000000071c3ad in > > > > CryptoPP::BufferedTransformation::ChannelPut2(std::string const&, > > > > unsigned char const*, unsigned long, int, bool) > > > > () > > > > #1 0x00000000007b543e in > > > > > > CryptoPP::X917RNG::GenerateIntoBufferedTransformation(CryptoPP::BufferedTransformation&, > > > > std::string const&, unsigned long long) () > > > > #2 0x000000000071c88e in > > > > CryptoPP::RandomNumberGenerator::GenerateBlock(unsigned char*, > > > > unsigned long) () > > > > #3 0x00000000007b576b in > > > > CryptoPP::X917RNG::X917RNG(CryptoPP::BlockTransformation*, unsigned > > > > char const*, unsigned char const*) () > > > > #4 0x0000000000743cc5 in > > > > CryptoPP::AutoSeededX917RNG<CryptoPP::Rijndael>::Reseed(unsigned char > > > > const*, unsigned long, unsigned char const*, unsigned char const*) () > > > > #5 0x0000000000743ed8 in > > > > CryptoPP::AutoSeededX917RNG<CryptoPP::Rijndael>::Reseed(bool, > unsigned > > > > char const*, unsigned long) () > > > > #6 0x0000000000744000 in > > > > > CryptoPP::AutoSeededX917RNG<CryptoPP::Rijndael>::AutoSeededX917RNG(bool, > > > > bool) () > > > > #7 0x00000000006eddc0 in __static_initialization_and_destruction_0 > > > > (__initialize_p=1, __priority=65535) > > > > at /home/dirvine/Devel/MaidSafe-Common/maidsafe_common_lib/src/ > > > > maidsafe/common/crypto.cc:61 > > > > #8 0x00000000006ede24 in _GLOBAL__sub_I_crypto.cc(void) () > > > > at /home/dirvine/Devel/MaidSafe-Common/maidsafe_common_lib/src/ > > > > maidsafe/common/crypto.cc:299AES/CTR IV custom increment > > > > #9 0x00000000007e9ded in __libc_csu_init () > > > > #10 0x00007ffff70a02a0 in __libc_start_main (main=0x5f3114 <main(int, > > > > char**)>, argc=1, ubp_av=0x7fffffffe118, > > > > init=0x7e9d90 <__libc_csu_init>, fini=<optimized out>, > > > > rtld_fini=<optimized out>, stack_end=0x7fffffffe108) at libc-start.c: > > > > 185 > > > > #11 0x00000000005f305d in _start () > > > > (gdb) quit > > > I would guess that g_srandom_number_generator is in one compilation > > > unit, and the code using it is in another. Ie, > > > g_srandom_number_generator is in my_rng.cpp, and the code using it is > > > in my_key_gen.cpp. In this case, you would be violating C++'s static > > > non-local rules. > > > > > The fix is relatively easy. Offer a static/global function to serve up > > > a static local: > > > > > RandomNumberGenerator& GetRandomNumberGenerator() > > > { > > > static AutoSeededX917RNG< CryptoPP::AES > s_prng; > > > return s_prng; > > > } > > > > > Jeff > > > > Thanks Jeff. It's possibly the case,, although this was initialised in > the > > same file it was used, however what I noticed was that > > merely initialising the rng and never calling it anywhere would cause > this > > issue. > > > > To be a bit more exact this was in a my_rng.cc which was compiled into a > lib > > that was then linked to another file.cc (or object, but you know what I > > mean). The file.oo did have some cryptopp code in there (AES, HASH etc. > but > > no explicit RNG calls). This is why it took a wee while to figure it out. > It > > looks like there may have been a static somewhere I had not seen (inside > > cryptopp) or something very similar. > I believe Crypto++ is fairly safe in its use of globals. They are > used, and they are easy to audit: searh for "g_*" in the source files. > > > I have tried your suggestion and looks a good, although it does still > > segfault in some circumstances (I am tracking that down just now). I > think > > it may be a threading issue though, but will post again if it turns out > to > > be more (which I doubt). > Crypto++ objects are thread safe, meaning they do not depend on global > data which might become corrupted across calls in different threads. > You still have to lock on concurrent access to an object. > > For what it worth, Wei uses a different technique for initializing a > singleton (his method results in a memory leak under 'worst case', if > I recall correctly). > > If you suspect you might have threading issues, Helgrind would > probably be very useful. But you need a good test program to get the > most out of it. > valgrind --tool=helgrind my_test_program > > Jeff > > Doing that right now Jeff, thanks For anyone who is interested the (offending) code is located here https://github.com/maidsafe/MaidSafe-Common David -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com.
