Closed GoogleCodeExporter closed 9 years ago
Please provide a core-dump if you can. Otherwise I won't be able to spot where
the
crash is caused.
Pyrit does not restart from the beginning if you restart a batch. It just
doesnt know
in advance if a workunit has been completed or not. You'll see that it skips
workunits at a very fast rate if you already computed some of them...
Original comment by lukas.l...@gmail.com
on 29 Nov 2009 at 6:28
i set ulimit -c, start pyrit batch and it crashs again at 17.5%. Dump is about
64M, i
bzipped it to 17M, then I split into 2 file xaa and xab because it is to much
big for
a single attach. I post xaa now then xab. I hope it helps.
Original comment by pyrit.lo...@gmail.com
on 29 Nov 2009 at 10:45
Attachments:
here the second part of zipped core dump, file named xab.
Original comment by pyrit.lo...@gmail.com
on 29 Nov 2009 at 10:51
Attachments:
This seems to be a refcount-bug. Can you reproduce the problem without using
CUDA
(remove _cpyrit_cuda.so from /usr/lib*/python*/site-packages/cpyrit) ?
Original comment by lukas.l...@gmail.com
on 1 Dec 2009 at 8:43
(By the way, today i got seg fault again).
I have /usr/lib/python2.5/cpyrit/_cpyrit_cuda.so.
Well, pyrit batch was running, I stopped it and renamed the file as
_cpyrit_cuda.so.old and run "pyrit batch" again.
Now k/s degradate from ~8720 to ~2470. I can leave it run all night long and
report
you result as soon as I can.
Tomorrow I will rerun pyrit "degradated" (it will need more than one day to
complete
batch) on a new set of passwords and I report you if crash again or not.
Original comment by pyrit.lo...@gmail.com
on 1 Dec 2009 at 10:24
I also get this error when I use pyrit with crunch or cowpatty. It seems to
happen
randomly, exactly as described above.
Original comment by shaneb...@gmail.com
on 2 Dec 2009 at 10:32
ok, finally pyrit without _cpyrit_cuda.so completed the job (30 hours).
It get one error BECAUSE disk full (my fault to leave too much data on disk).
After i clean disk and re-run pyrit batch, it completed the activity without
crash.
Well, *apparently* pyrit without _cpyrit_cuda.so works without problems, but
this is
just ONE test and not several tests.
As I said, also pyrit with _cpyrit_cuda.so sometime (I mean: rarely) complete
activity without problems.
So, I can't say that problem is 100% inside _cpyrit_cuda.so, even if it is
higltly
probable.
If there is some other activities I can do to help in trouble shooting, let me
know.
Original comment by pyrit.lo...@gmail.com
on 3 Dec 2009 at 2:20
i see the last post in mainpage related to "Revision 193: Fixed possible
refcount-corruption".
Is r193 related to solve this issue 76?
Original comment by pyrit.lo...@gmail.com
on 10 Dec 2009 at 9:39
No, not really. I havent yet been able to spot the error or reproduce the crash
Original comment by lukas.l...@gmail.com
on 14 Dec 2009 at 7:50
Now pc is 2 days that is running without problems. To compensate the possible
segfault I do script like this:
rm -rf .pyrit/* ; pyrit -e ESSID create_password ; pyrit -f list1.txt
import_passwords; pyrit batch; pyrit batch; pyrit batch; pyrit -e ESSID -f
hash1.cow
export_cowpatty
rm -rf .pyrit/* ; pyrit -e ESSID create_password ; pyrit -f list2.txt
import_passwords; pyrit batch; pyrit batch; pyrit batch; pyrit -e ESSID -f
hash2.cow
export_cowpatty
etc etc
I add that the PC runs with open case to increase air circulation.
Original comment by pyrit.lo...@gmail.com
on 15 Dec 2009 at 5:25
why don't you just use 0.2.5svn and execute
pyrit -e ESSID -i listX.txt -o hashX.cow passthrough
Original comment by lukas.l...@gmail.com
on 15 Dec 2009 at 9:42
I got crash again, but triple command "pyrit batch" compensate the problem.
By the way, "pyrit -f listX.txt create_password" needs 50 minutes, but "pyrit
batch"
needs 8 hours.
about 0.2.5svn, I am reluctant to use not stable soft: Whit upper script, if
"pyrit
batch" crashs is enough to redo it, but what if "pyrit -e ESSID -i listX.txt -o
hashX.cow passthrough" crashs at 90%? it means i will loose all the job done
till
that moment and I have to redo from beginning all the task?
Anyway, ok, I will move to 0.2.5 r193 and I will follow your suggestion, I
understand
that feedback from us is precious to you to find and correct bugs, so I will do
my
part to test and do bugreport.
Stay tuned.
Original comment by pyrit.lo...@gmail.com
on 16 Dec 2009 at 10:02
ok, 0.2.5svn r193 downoloaded, compiled, installed (both pyrit and cpyrit-cuda).
I runned "time pyrit -e ESSID -i listX.txt -o hashX.cow passthrough" and gone
to sleep.
This morning, I see segfault again after 153 minutes.
So, problem is again somewhere.
Now I set "ulimit -c 500000" and rerun the upper command, I hope to got
seg-fault
again so I can send you core dump.
Original comment by pyrit.lo...@gmail.com
on 17 Dec 2009 at 9:45
well, it got crash again, this time only after 15min.
Please find the core dump in attach.
I hope this bug will be solved, so I can use the new feature "pyrit -e ESSID -i
listX.txt -o hashX.cow passthrough" without problems
Original comment by pyrit.lo...@gmail.com
on 17 Dec 2009 at 8:57
Attachments:
I have attached a screenshot of my segmentation fault error. Maybe this will
help
somehow. I am running at 35,000 PMKs, and sometimes it will run through 100-500
million keys before it gives the error, other times it may not get through
500k. I
wish it would at least show the amount of keys it processed before the error,
as I
have no way of knowing because the error covers up the number (as seen in the
screenshot).
Original comment by Atomi...@gmail.com
on 18 Dec 2009 at 8:57
Attachments:
[deleted comment]
other info: I run pyrit batch, but it seems to freeze.
I explain better: for example, pyrit crashs at 4000/12228, so I re run pyrit
batch
but the "4000" does not increase also after several minutes (30-40).
I duno how to do, I also tryed to recompile/reinstall 0.2.4 (both Cpyrit-CUDA
and
Pyrit) but when I run again pyrit, I still see 0.2.5-svn r193 into header.
I duno what to do, hightly probability I am doing somethin wrong, but I need PC
crunchs hash during weekend, so I "ghost back" my S.O. partition to have back a
"clean and working" 0.2.4. (hopefully I did a ghost some days ago).
Original comment by pyrit.lo...@gmail.com
on 18 Dec 2009 at 10:21
Im here again.
Well, now I am running r208 and thye command "time pyrit -e ESSID -i listX.txt
-o
hashX.cow passthrough" don't fall in segmentation fault.
r208 appear to be more stable than r193 I tested last time.
I will do run a 8-days-long-test of neverending passthrough command then I will
report you the result of stability of r208.
See you in 10 days.
Original comment by pyrit.lo...@gmail.com
on 28 Jan 2010 at 9:01
I'm back with report.
Well, I moved to r209, then I runned long session of passthrough: there was
about 5
segfault on 20. Now I reset "ulimit -c unlimited" and run another sessions of
passthrough.
I will report core dump for analysis.
Original comment by pyrit.lo...@gmail.com
on 5 Feb 2010 at 10:54
got many (5) core dumps. here one.
Original comment by pyrit.lo...@gmail.com
on 8 Feb 2010 at 7:08
Attachments:
core dump number 2.
Original comment by pyrit.lo...@gmail.com
on 8 Feb 2010 at 7:19
Attachments:
To do process several listX.txt -> hashX.cow using
"pyrit -e ESSID -i listX.txt -o hashX.cow passthrough"
with pyrit r209 did dump again and again and again, I have several core dump
for you.
to minimize the lose of time, the only workaround is replicate "pyrith batch"
command
as follow:
"rm -rf .pyrit/blobspace/* ; pyrit -e ESSID create_password ; pyrit -i list1.txt
import_unique_passwords; pyrit batch; pyrit batch; pyrit batch; pyrit -e ESSID
-o
hash1.cow export_cowpatty"
Tell me if the 2 previous core dump are enough: if not, I will post more core
dump.
Original comment by pyrit.lo...@gmail.com
on 11 Feb 2010 at 9:14
I'll have time to look at the dumps this weekend.
Original comment by lukas.l...@gmail.com
on 11 Feb 2010 at 9:17
Please try using a more recent python interpreter.
I've checked the code and found a list of memory-pointers to get corrupted. As
this
list is managed by python-interpreted code only, I currently suspect either a
bug in
python 2.5.2 or some concurrency problems while we let go of the GIL.
Please try using e.g. backtrack4 for some time which you dont have to install
on your
hd and which comes with a more recent version of python
Original comment by lukas.l...@gmail.com
on 13 Feb 2010 at 3:16
I will go to upgrade my debian stable to debian testing to move form python 2.5
to
python 2.6. After that, I will run again some long test session and I will
report you
results.
By the way:
A. have I to rebuild r209 after upgraded from python 2.5 to python 2.6?
B. have I to move from r209 to r212 (the last at the moment of this post) ?
Original comment by pyrit.lo...@gmail.com
on 13 Feb 2010 at 3:33
yes, you'll have to rebuild. ('/usr/bin/env python' should be python2.6)
r209 will be ok
Original comment by lukas.l...@gmail.com
on 13 Feb 2010 at 3:51
ok, here the situation: upgrade from debian stable to debian testing make
"dirty" my
pc with some dependences not sutisfied - not important to me at the moment -
The good news is that I have now python 2.6 on the pc, I rebuild pyrit r209 and
it
running since yesterday evening without segmentation fault.
I will leave it running for some days, and I will report coredump if any.
by the way: moving from r208 to 209 (compiled with python 2.5) gave more
frequent
instability and core dump: maybe from r208 to r209 the code got same
changes-with-inside-bug that is "mascherate and compensated" by python 2.6?
This is
just a suspect, but I report you the same.
Original comment by pyrit.lo...@gmail.com
on 15 Feb 2010 at 10:16
In these last days, pyrit r209 compiled with python2.6 runned without problems
- aka
segmentation fault -.
To me, this issue can be closed.
Original comment by pyrit.lo...@gmail.com
on 17 Feb 2010 at 9:52
closed
Original comment by lukas.l...@gmail.com
on 17 Feb 2010 at 10:49
"('/usr/bin/env python' should be python2.6)"
Can someone explain how to do this please? I've updated python from 2.5 to 2.6
Original comment by Atomi...@gmail.com
on 3 Mar 2010 at 10:08
this will usually end up looking python in your PATH. If you have 2.5 and 2.6
installed at the same time, you probably should not change the system-wide
python
version, as other packages (e.g. the package manager) will probably stop
working....
1. Run "/usr/bin/env python -V" to see if Python 2.6 is already your system-wide
interpreter
2. If you are still on 2.5 by default, you can execute pyrit with
"/usr/bin/python2.6
/usr/bin/pyrit". Similar, you have to compile it with "/usr/bin/python2.6
./setup.py"...
Original comment by lukas.l...@gmail.com
on 3 Mar 2010 at 10:32
Original issue reported on code.google.com by
pyrit.lo...@gmail.com
on 29 Nov 2009 at 5:36