Date: Fri, 7 Aug 2015 08:14:11 +0800 From: Kai Zhao <loverszhao@...il.com> To: john-dev@...ts.openwall.com Subject: Re: --test-full=0 crashes the Bitcoin format Alexander, On Fri, Aug 7, 2015 at 12:38 AM, Solar Designer <solar@...nwall.com> wrote: > Kai, magnum - > > Flag bugs aside, this feature as committed to magnum's jumbo triggers > memory corruption: > > [solar@...er run]$ ./john --test-full=0 > [...] > Testing: asa-md5, Cisco ASA [Cisco ASA (MD5 salted) 128/128 AVX 4x3]... PASS > Testing: bfegg, Eggdrop [Blowfish 32/64]... (32xOMP) PASS > Testing: Bitcoin [SHA512 AES 128/128 AVX 2x]... (32xOMP) *** glibc detected *** ./john: double free or corruption (!prev): 0x000000000224a770 *** > ======= Backtrace: ========= > /lib64/libc.so.6(+0x75e66)[0x7f80c1a4ce66] > /lib64/libc.so.6(+0x789b3)[0x7f80c1a4f9b3] > /lib64/libc.so.6(+0x7b880)[0x7f80c1a52880] > /lib64/libc.so.6(realloc+0xe5)[0x7f80c1a52af5] > /usr/lib64/libcrypto.so.10(CRYPTO_realloc+0x5f)[0x7f80c2f3dccf] > /usr/lib64/libcrypto.so.10(lh_insert+0xee)[0x7f80c2fb858e] > /usr/lib64/libcrypto.so.10(+0xe7c71)[0x7f80c2fbac71] > /usr/lib64/libcrypto.so.10(ERR_get_state+0xce)[0x7f80c2fbb10e] > /usr/lib64/libcrypto.so.10(ERR_put_error+0x2f)[0x7f80c2fbb8df] > /usr/lib64/libcrypto.so.10(EVP_DecryptFinal_ex+0x1c1)[0x7f80c2fbd841] > ./john[0x52d66e] > /usr/lib64/libgomp.so.1(+0xe0c5)[0x7f80c1f960c5] > /lib64/libpthread.so.0(+0x79d1)[0x7f80c1d729d1] > /lib64/libc.so.6(clone+0x6d)[0x7f80c1abf8fd] > > This is for today's jumbo built on super after "scl enable devtoolset-3 > bash" (so with gcc 4.9.1). ./configure was run without options (so > OpenMP and OpenCL are enabled, CUDA is disabled). > > Would you debug this, please? > > It's probably some bug unrelated to flags, which merely happened to be > triggered in this run. I'd start by testing if it's triggerable > reliably or not, and whether it's triggerable without OpenMP at all. > Also, whether it's triggerable when the Bitcoin format is test-full'ed > on its own (rather than after lots of other formats). Then try to > trigger it in an --enable-asan build (hopefully, it'd crash on the > actual memory corruption, not on its aftermath as this run did). > > ... After writing the above, I ran the command a few more times. Most > of the time, there's no crash. But I was able to trigger the crash > once more (so 2 times total so far), with GOMP_CPU_AFFINITY=0-31. ASan > should help detect it reliably. > > Alexander I will debug this crash. Thanks, Kai
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.