Author Topic: Problems with debugger in version 17.12  (Read 359 times)

Offline mbuckingham

  • Single posting newcomer
  • *
  • Posts: 3
Problems with debugger in version 17.12
« on: June 27, 2018, 10:03:18 am »
I've been using Code:Blocks for several years but have recently installed version 17:12. I've had several problems but the latest is with the debugger. I'm using Windows 7.

It fails to debug the program and gives the message :-
Debugger finished with status 1

The line that runs the debugger is :-
Starting debugger: C:\Program Files\CodeBlocks\MinGW\bin\gdb32.exe -nx -fullname -quiet  -args C:/WorkBase/utils/db01/bin/Debug/db01.exe

To find out what was happening I opened a command box and changed to the folder with gdb32.  There I typed gdb32 to run the debugger. The result was:-


C:\Program Files\CodeBlocks\MinGW\bin>gdb32
  File "c:\python35\lib\site.py", line 176
    file=sys.stderr)
        ^
SyntaxError: invalid syntax


Why am I getting a python error when trying to run GDB?


Malcolm Buckingham

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11144
    • Travis build status
Re: Problems with debugger in version 17.12
« Reply #1 on: June 27, 2018, 10:38:17 am »
Because gdb uses python to enable users to script it.
It seems your gdb doesn't like the python it is finding.
Are there any other executables named gdb in the bin folder?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline mbuckingham

  • Single posting newcomer
  • *
  • Posts: 3
Re: Problems with debugger in version 17.12
« Reply #2 on: June 27, 2018, 11:16:09 am »
I installed Python 3.5 on my PC and that is the one that gives the error. I'm guessing CodeBlocks installed Python36-32 under c:\Users and that is the version it should be using.

There are two PATH environment variables for Windows. The first is under User Variables and the second under System Variables. Windows then combines these to get one long list and puts the user variables AFTER the system variables. This would mean that if CodeBlocks just looks at the PATH variable it will use the Python 3.5 which seems to have a bug in in.

I have to say that all my problems with version 17.12 have been down to paths. I'm going to remove the old Python and see if that fixes things

Thanks
Malcolm

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11144
    • Travis build status
Re: Problems with debugger in version 17.12
« Reply #3 on: June 27, 2018, 11:34:25 am »
And you failed to answer my question...  ::)

In theory there should be a gdb executable that manages the python paths and starts the real gdb and the path to the external python doesn't matter.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline mbuckingham

  • Single posting newcomer
  • *
  • Posts: 3
Re: Problems with debugger in version 17.12
« Reply #4 on: June 27, 2018, 12:10:18 pm »
OK. To answer your question there is one other exe file in C:\Program Files\CodeBlocks\MinGW\gdb32\bin. That is  gdbserver32.exe

Removing Python 3.5 has fixed the problem.

A possibly related issue I had was with as.exe. I develop my C code using the CodeBlocks IDE but compile for release using a DOS batch file. This batch process has to run on both my own PC and a server we use for release software.

Older versions of CodeBlocks did not need the PATH variable to be set. Instead I used the CODEBLOCKS environment variable and both the IDE and batch files worked.

With 17:12 the IDE worked but the batch file did not because as.exe could not find libintl-8.dll. This seemed to be because there are two copies of as.ex; one in C:\Program Files\CodeBlocks\MinGW\bin which also has the DLL, and one in C:\Program Files\CodeBlocks\MinGW\mingw32\bin which doesn't have the DLL.as

This is fixed by adding  c:\program files\codeblocks\mingw\bin to PATH.  Using the CODEBLOCKS variable was slightly easier because it could be set on the fly in the batch file.

Once again thanks for you help,
Malcolm