[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5a17c04051ad2960051b14c0875d5dff@smtp.hushmail.com>
Date: Sun, 9 Jun 2013 23:39:43 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Confusing output from memdbg
On 9 Jun, 2013, at 23:29 , magnum <john.magnum@...hmail.com> wrote:
> So for some reason (this on OSX) memdbg does not work like it should, but the pointer becomes NULL. I'll try and see if I get the same behaviour on Bull.
I do. Here's actual output:
$ ../run/john -t=0 -form:opencl
Warning: doing quick benchmarking - the performance numbers will be inaccurate
Device 0: GeForce GTX 570
Local worksize (LWS) 7, Global worksize (GWS) 49
Benchmarking: ssha-opencl, Netscape LDAP {SSHA} [SHA1 OpenCL (inefficient, development use mostly)]... DONE
Many salts: 9800 c/s real, 9800 c/s virtual
Only one salt: 4900 c/s real, 4900 c/s virtual
Mem leak: 6996 bytes, alloc_num 64, file common-opencl.c, line 1267
Device 0: GeForce GTX 570
Local worksize (LWS) 7, Global worksize (GWS) 49
Benchmarking: nt-opencl, NT [MD4 OpenCL (inefficient, development use only)]... DONE
Raw: 4900 c/s real, 4900 c/s virtual
Mem leak: 6155 bytes, alloc_num 75, file common-opencl.c, line 1267
Device 0: GeForce GTX 570
Local worksize (LWS) 7, Global worksize (GWS) 49
Benchmarking: ntlmv2-opencl, NTLMv2 C/R [MD4 HMAC-MD5 OpenCL]... DONE
Many salts: 4900 c/s real, 4900 c/s virtual
Only one salt: 4900 c/s real, 4900 c/s virtual
(...)
Mem leak: 14640 bytes, alloc_num 770, file common-opencl.c, line 1267
Device 0: GeForce GTX 570
Benchmarking: bcrypt-opencl ("$2a$05", 32 iterations) [Blowfish OpenCL]... DONE
Raw: 233 c/s real, 233 c/s virtual
Mem leak: 8579 bytes, alloc_num 797, file common-opencl.c, line 1267
Device 0: GeForce GTX 570
Benchmarking: descrypt-opencl, traditional crypt(3) [DES OpenCL]... DONE
Many salts: 4900 c/s real, 4900 c/s virtual
Only one salt: 4900 c/s real, 4900 c/s virtual
Mem leak: 34653 bytes, alloc_num 806, file common-opencl.c, line 1267
Mem leak: 4194304 bytes, alloc_num 805, file opencl_DES_bs_b.c, line 84
Mem leak: 4259840 bytes, alloc_num 804, file opencl_DES_bs_b.c, line 83
Mem leak: 10616832 bytes, alloc_num 803, file opencl_DES_bs_b.c, line 82
All 38 formats passed self-tests!
------------------------------
MEMDBG: allocation information:
current normal alloc mem (leaks)19070976 max normal mem allocated: 178536487
current 'tiny' alloc mem (leaks) 0 max tiny mem allocated: 5772959
Index : alloc# : Size : File(Line) [first 20 bytes, or size of bytes]
0 : 805 : 4194304 : opencl_DES_bs_b.c(84) .0....m..i...i..EQ.E
1 : 804 : 4259840 : opencl_DES_bs_b.c(83) U*.UU.UU*.U*.UU..U*.
2 : 803 : 10616832 : opencl_DES_bs_b.c(82) ....................
At Program Exit
MemDbg_Validate level 0 checking Passed
I am pretty sure this is a bug in memdbg but I have absolutely no idea why it's never triggered except in this place.
I think the opencl_DES_bs_b.c warnings are legit.
magnum
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.
