2

When I set a breakpoint in my program and run the debugger, it just stalls on "Listening on port ..." without stopping at a breakpoint, allowing me to view local variables (nor does it even display them in the first place) and so forth.

I've tried the suggested solutions from another question (Debugger not working in cs50 online ide) but it did not fix the issue.

Here is what appears when I run the program with a breakpoint; most options are faded out and local variables are not visible.

Debugger stalled

1

I think this is a common problem, you are not the first to post this issue and I have had similar issues. I never really fixed the problem but it resolved itself after some time.

You can still use GDB in the console for debugging your code. I strongly suggest you read the man page, and watch the videos if you haven't, so you know how to use it properly.

I know the console version isn't as friendly as the UI presented by the IDE, however, it would be more useful to learn the console version as you may have no choice to use it when you start doing professional work. Using GDB may also be an interview question. It only takes a few minutes to get what you need to be proficient with it.

| improve this answer | |
  • Thank you for replying. I use GDB on my own system; and I'm somewhat comfortable with it. I was just hoping to use the GUI version for completion's sake. Feels like it's a feature on various graphical IDEs, although I imagine (or hope) that most IDEs have a console also. I guess I'll run update50 and see if it's working again tomorrow. Thankfully I haven't had a bug complex enough to warrant substantial use of the debugger just yet. It's a shame that the CS50 IDE has had so many issues recently, however. Thank you again for the advice! – Gabriel Doyle-Finch Aug 23 '16 at 19:48
  • I will admit, using the built in debugger in the IDE is nice, but like learning C, the lower you start, the better and more appreciative you'll be when you get to the luxuries of programming. It's mentioned in another video later on in the course based on your screenshot that uses a more featured language. David shows how nice it is to be able to type a one liner for what might take 50 in C, but also shows you how much longer it takes for the one liner to run vs the C code. At that point, you'll have to decide if it is worth it. Good luck with the course! – Bob R. Aug 24 '16 at 23:55
1

I had the same problem. The only way I've been able to use the graphical interface is to run debug50 ./programname from the terminal.

An alternative would be to use gdb from the terminal which there's a CS50 section on: https://www.youtube.com/watch?v=y5JmQItfFck

| improve this answer | |
0

I was having the same exact problem. On Pset4 Whodunit there're some questions and it is asked to run in debug (never tried, before, actually).. Also, the video with Dan is running on IDE 37, while at the moment running version is 57, so maybe something changed.. ie. now the button is called simply "Run".

Anyway, looking on supported languages list (https://docs.c9.io/v1.0/docs/supported-languages) I've noticed C is not included, while C++ is. Editor parser is set as "C and C++" so I was thinking that for IDE both are considered as the same lang.

BUT, I tried to change the "Runner:" inside console debugger to C++ instead of C(GDB) and seems it works now:

see there

| improve this answer | |
  • That would make a lot of sense. Strange, though, considering that C is the primary language in CS50 and yet the IDE's debugger doesn't support it! I suppose it is wise to focus on GDB usage in the terminal for more command line discipline anyhow. I thought that the broken debugger was going to become a pset at some point. Debug the debugger. – Gabriel Doyle-Finch Aug 25 '16 at 11:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .