Date: Sat, 12 May 2007 03:42:42 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Re: Potfile size limitation? On Fri, May 11, 2007 at 03:16:35PM +0000, -. -PhanTom-. - wrote: > > > (gdb) bt > > > #0 0x61016525 in stack_info::walk () ... > Solar Designer <solar@...> writes: > > Well, this is not useful. It appears that gdb traps the fault that > > occurs during Cygwin's backtrace dump rather than the one in John ... > Ok, so is there any more I can do in this regard? Well, we could agree on and share an exact debugging build for Windows, then try to investigate the problem based on Cygwin's backtrace dump, but I'm not willing to go into debugging on Windows myself now - no time for that, considering that the issue is rather minor (not relevant to most John users). We might get back to it when testing the next major release candidate, which will likely have some changes in the password file and john.pot loader. > So this issue seems to be related to windows/cygwin only. That's quite likely, but we haven't proven it yet. I was not using your john.pot file to test, and neither I nor you tested on 32-bit non-Windows (instead we tested on 64-bit Linux). Maybe you could try on 32-bit Linux? You might not need another Linux install for that if you have 32-bit compatibility libraries on your existing one. You'd likely need to add "-m32" to all of CFLAGS, ASFLAGS, and LDFLAGS, then build with "make clean linux-x86-sse2". > Similar to what I experienced on my Ubuntu machine. > I copied the john.pot over, and did a show. > JTR used up 96-98% of RAM during the show (machine has 1 Gb) Yes, the memory usage overhead is larger on 64-bit systems. That's because pointers become 64-bit and require 64-bit alignment. The advantage is that even larger amounts of data may be loaded (if needed and if memory permits), whereas 32-bit systems are limited to a few gigabytes (up to 4 GB, and usually less than that in practice). BTW, you could reduce memory usage a bit with --save-memory=3 - this should disable the natural alignments on architectures that allow unaligned accesses (at a performance cost), including x86 and x86-64. > So maybe there is room for improving the memory usage during the show > procedure? Or is it as good as it can be? Indeed there's room for improvement, but it'd come at extra code complexity. Most users of John don't have john.pot files nearly this large, and even yours fits into memory of typical machines these days. So a possible improvement in this area does not appear to be worth the effort and code complexity. -- Alexander Peslyak <solar at openwall.com> GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15 http://www.openwall.com - bringing security into open computing environments -- To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply to the automated confirmation request that will be sent to you.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ