[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070511234242.GA15712@openwall.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
