pyrit crashs (segmentation fault) during long batch sessions (7-8 hours)

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Charge essid and long password list (more than 200 million that needs 7-8
hour to be completed)
2.launch command °pyrit bench°
3. wait till seg fault appens.

What is the expected output? What do you see instead?
expected output: job complete at 100%. what i see: pyrit stop after some
time with segmentation fault: sometime at 98% or 15% or 44% or else. Rarely
the °pyrit batch° command complete with success.

What version of the product are you using? On what operating system?
0.2.4 on debian lenny stable 32 bit version.

Please provide any additional information below.
CPU phenom2 4core@2.8Ghz, 2GRam , GPU NVIDIA 9800 GTX+
My comment: I still not understand if it is SOFTware or HARDware problem,
so I don't want to say pyrit is guilty. I left case open so there is a
better air circulation: if I touch the heat fan metal part with finger, I
can see temperature is just warm, so I can say it should not be a over heat
problem. 
How can I do bug report? there is some log I can send you? if yes, where it
is located? Or maybe there is a flag to activate? i.e. °pyrit
-do_verbose_log batch° ?

by the way, If pyrit crashs an I launch it again, it will RESTART to
process the passwords since the number one? there is not an option to avoid
that the job already done will be redone again? Something like a option as:
-restart_form_last_password_before_crash of
-delete_password_after_calculate_hash

Original issue reported on code.google.com by pyrit.lo...@gmail.com on 29 Nov 2009 at 5:36

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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:

• xaa

[GoogleCodeExporter]

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:

• xab

[GoogleCodeExporter]

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

• Changed state: Accepted

[GoogleCodeExporter]

(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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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:

• core.3451.7z

[GoogleCodeExporter]

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:

• seg_fault.jpg

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

got many (5) core dumps. here one.

Original comment by pyrit.lo...@gmail.com on 8 Feb 2010 at 7:08

Attachments:

• core.14073.7z

[GoogleCodeExporter]

core dump number 2.

Original comment by pyrit.lo...@gmail.com on 8 Feb 2010 at 7:19

Attachments:

• core.15502.7z

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

closed

Original comment by lukas.l...@gmail.com on 17 Feb 2010 at 10:49

• Changed state: WontFix

[GoogleCodeExporter]

"('/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

[GoogleCodeExporter]

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