Broken file python pbd, bad idea?

I made a python file that crashes my computer, and I’m wondering if trying using the python pbd would help me find what it’s doing, (sure it’s an infinite loop issue) But I would like to see what it’s doing to crash me. Curiosity killed the cat and all.
Was thinking I can put some kind of breakpoint in the part where the loop is? And do we learn about this pbd thing at all in the LMPTHW book? Didn’t know it existed until I started ex4 of the learn C book.

Hey @nellietobey you might have missed Zed talking about his Awesome debug tools on the chat. They might help…

There still on my TODO list so can’t comment on usage.

1 Like

@nellietobey you can submit it to the “find the bug” challenge :bug:

1 Like

yeah, but I don’t want someone to crash trying to run it. I know it’s the infinite loop, just want to find out why it’s crashing on the infinite loop. Maybe submit it as such?

Or is it as simple as an infinite loop that will just fill memory so fast, if you don’t cancel it, it will eat up and freeze… recursions have a depth limit, I thought the __ next __ should have a limit too, or an option for one. Going to go google, My sis told me about a ulimits, I’ll try that, on my laptop, if it fails I don’t want this cpu to get stupid on me.

Trying to watch it now, Thanks!

Give za code! :grinning:

1 Like

It crashes your computer? That’s pretty hard to do with Python so I’m betting there’s not much PDB could do but pinpoint the line where it happens. But, try this:

import pdb

# ... lots of code
pdb.set_trace()
# ... maybe where you think the code explodes

The pdb.set_trace() function stops python and lets you analyze the code and step through it. You can then type help to get commands, and you can type full python to check variables. I’d use the next command to move over lines, step to go into function calls, and just type python to see what a variable is. You can also type most python code to test out new code at that spot.

1 Like

I know it’s the loop, I think it’s happening in two places… I have a couple screenshots. I think adding the prints slowed it down for me to cancel out before lock up. I tried it on my alienware first and complete lock up.
Brain burp on thinking I could add the letter ‘a’ on the string and make it bigger… I got it doing the thing I wanted later.
BAD code, I know it’ll be, ‘she can’t be serious, I’ll run it’… pbd will stop it, ‘next’ in pbd will run the print loops for line 17, 22: Without those the code locks you up, I tried CTRL C really fast on my alienware and still had a lock. (lock without the print(self.line)* stuff, and the pbd.set_trace() in it to slow it down I think??)
BAD:

import pdb
def make_list_comp(something):
	pdb.set_trace()
	return [x for x in something]

class IterTooly(object):
	def __init__(self, start, stop):
		self.start = start
		self.stop = stop
		self.line21 = 0
		self.line17 = 0



	def __iter__(self):
		return self

	def __next__(self):
		print("line 17")
		self.line17 += 1; print(self.line17)
		if self.start > self.stop:
			raise StopIteration
		else:
			print("line 22")
			self.line21 += 1; print(self.line21)
			result = self.start
			self.start += 'a'
			#yield breaks it (from a different run-did not lock up computer)
			return result
            
#quick cancel with print 
fail = IterTooly('boo', 'hoo')
a = make_list_comp(fail)
print(a)

Can you share the GitLab link so we can pull it?

I’ll try to get it on there today. Thanks.

It’s in snippets now.

Wait! @nellietobey can we use this in this weekend’s seminar? We’re doing a series on debugging code and it’d be great to use this code. This bug is awesome. If you do I’ll send you the seminar link so you can watch.

1 Like

Sure thing!
I can’t wait to see what you do with it!

I’m putting a new pic on the gitlab… I didn’t even run it, and my CPU locked up, and I had to power shut down and I got a pic of the boot up thing I was talking about.
I didn’t even touch anything, just had my CPU idling while I was setting up.