The 18 June 2006 build is out.

[Denis]

I can't debug programm with this nightly build.
I created new console project, built it, set break point to "std::cout << "Hello world!" << std::endl;" line and pressed "Debug / Continue" button. Then I got debugger message "No source file named d:/GCC/test2/main.cpp". What I did wrong? Last time I tryed RC2, it worked without problem.

PS: WinXP SP2, MinGW 3.4.2 

[kkez]

If you press "Abort", the crash handler will simply return control to the system exception handler (reading what's displayed in the message helps), so after you do that, the application *will* crash.

That's not true, after clicking two or three times on abort C::B doesn't crash.

What makes you say that?

It doesn't crash on some circunstances, when it's really not the place for a crash (ie the example i made before, inside the openfilename dlgbox. I can prove it if you want, what did you use to make that gif?

[MortenMacFly]

I can't debug programm with this nightly build.

You'll need at least GDB version 6.3. Search the forum for this keyword for additional information.
With regards, Morten.

[Michael]

[...]MinGW 3.4.2

Hello,

I would advice you to also upgrade GCC to 3.4.4 or 3.4.5.

Best wishes,
Michael

[Pecan]

If you press "Abort", the crash handler will simply return control to the system exception handler (reading what's displayed in the message helps), so after you do that, the application *will* crash.

That's not true, after clicking two or three times on abort C::B doesn't crash.

BTW, i always get a crash handler dialogbox doing this:
1) File->Open...
2) create a new folder
3) insert a name and press enter
4) click 3 or 4 times on "Abort", C::B will continue to run

Is there a possibility that this behavior is caused by the SIGTRAP's that are buried in ntdll.dll?
When running CodeBlocks under GDB, I get these traps when using system calls such as open/save/etc.
A simple C continues GDB and the program continues.

This sounds like what is happening. Just a guess.

[Pecan]

For those of you getting the crash... try the following in order to identify the Signal...
Run Codeblocks.exe from within console (dos) with GDB

"gdb codeblocks.exe"
"run"
(when the crash occurs it will tell you what signal occured. Do..)
"bt all" (meaning backtrace)
"q"  (meaning quit)

Then paste the results to the forum

EDIT: These sigtraps happend after I installed MSVC on my laptop about a year ago. My old system, which has never had MSVC on it, does *not* get these sigtraps when running GDB.

[Denis]

MortenMacFly, Thanks! Sorry for I didn't use forum search before posting

[royalbox]

@Pecan
I've been learning c++ with code::blocks for about a year, but I don't know what GDB is. Is is something to do with debugging? If you or someone could give a bit more info on it I'll give it a try. I tried it anyway but the computer didn't understand what it was. I'd like to help sort this out.

[Pecan]

@Pecan
I've been learning c++ with code::blocks for about a year, but I don't know what GDB is. Is is something to do with debugging? If you or someone could give a bit more info on it I'll give it a try. I tried it anyway but the computer didn't understand what it was. I'd like to help sort this out.

GDB is the gnu debugger used by codebocks and minGW. It will be in your mingw bin directory.

When I debug codeblocks, I always run it from within a dos box (console) so I can see the traps/errs code lines that caused the error. GDB will stop the system when an trap occurs.

I use the following statements to run gdb:

Code Select Expand


PATH=%PATH%;c:\usr\codeblocks\bin                                         <== bin directory contains mingw gdb etc
c:\usr\codeblocks\bin\gdb c:\Usr\Proj\cbBeta\trunk\src\devel\codeblocks.exe


The above will start CodeBlocks and stop with the gdb prompt "(gdb)"
Type "run" and codeblocks will run while gdb monitors it's every move.

If an error occurs, CodeBlocks will halt, and the dos box will show the Signal that occured.
Type "bt all" (meaning) show the stack and all variables on the stack. (assuming compilation was with debugging flag on)
If CodeBlocks was compiled with the debugging flag checked, it will also show the line the error occured on.

Type "q" to quit CodeBlocks and gdb.

Attached is a pdf of gdb commands that you can print out and tri-fold for reference.


[attachment deleted by admin]

[royalbox]

@@Pecan
Thanks very much for the info.

I'm using the code::blocks nightlies and the MSVC 2005 compiler. I only have mingwm10.dll. I'll go to the home page and see what I need to get.

[thomas]

Is there a possibility that this behavior is caused by the SIGTRAP's that are buried in ntdll.dll?

Who could tell what is possible...   I don't believe so, though.

The exceptions that are caught (according to MSDN) are:
EXCEPTION_ACCESS_VIOLATION
EXCEPTION_ARRAY_BOUNDS_EXCEEDED
EXCEPTION_BREAKPOINT
EXCEPTION_DATATYPE_MISALIGNMENT
EXCEPTION_FLT_DENORMAL_OPERAND
EXCEPTION_FLT_DIVIDE_BY_ZERO
EXCEPTION_FLT_INEXACT_RESULT
EXCEPTION_FLT_INVALID_OPERATION
EXCEPTION_FLT_OVERFLOW
EXCEPTION_FLT_STACK_CHECK
EXCEPTION_FLT_UNDERFLOW
EXCEPTION_ILLEGAL_INSTRUCTION
EXCEPTION_IN_PAGE_ERROR
EXCEPTION_INT_DIVIDE_BY_ZERO
EXCEPTION_INT_OVERFLOW
EXCEPTION_INVALID_DISPOSITION
EXCEPTION_NONCONTINUABLE_EXCEPTION
EXCEPTION_PRIV_INSTRUCTION
EXCEPTION_SINGLE_STEP
EXCEPTION_STACK_OVERFLOW

It does not say anything about traps caused by file I/O or anything. If it were related to I/O then we should have seen that crash before, shouldn't we. Remember that I have been using the crash handler 10-12 hours daily for 46 days 66 days without ever seeing such a thing (and a few other people have used it for the same time).

[royalbox]

@Pecan
I downloaded and installed gdb-5.2.1-1.exe. This is the output I get after typing 'run':

Code Select Expand


Starting program: C:\Program Files\Code Blocks\codeblocks.exe
---Type <return> to continue, or q <return> to quit---

Program received signal SIGSEGV, Segmentation fault.
0x77ea3c00 in _libkernel32_a_iname ()
(gdb)

code::blocks doesn't get past the splash screen.
I tried this on the last nightly that works on my system just to test. Am I doing something wrong?

EDIT:
This was the output before typing 'run':

Code Select Expand


This GDB was configured as "i686-pc-mingw32"...(no debugging symbols found)...

Do I need a debug version of the nightly? I'm not up on debugging yet, I keep putting it off.

[Michael]

@Pecan
I downloaded and installed gdb-5.2.1-1.exe. This is the output I get after typing 'run':

Hello,

You should download gdb 6.3.x. gdb 5.2.x does not work (pending breakpoints).

Best wishes,
Michael

[Pecan]

@Pecan
I downloaded and installed gdb-5.2.1-1.exe. This is the output I get after typing 'run':

Code Select Expand


Starting program: C:\Program Files\Code Blocks\codeblocks.exe
---Type <return> to continue, or q <return> to quit---

Program received signal SIGSEGV, Segmentation fault.
0x77ea3c00 in _libkernel32_a_iname ()
(gdb)


Are you running under cygwin or some other non-windows shell?

You must have downloaded the wrong gdb. It should be gdb 6.3 for windows.

Look here: http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks
It has a link to download MinGW for MS Windows.

pecan

[Pecan]

These sigtraps happend after I installed MSVC on my laptop about a year ago. My old system, which has never had MSVC on it, does *not* get these sigtraps when running GDB.

@royalbox, et.al. with crash

For the machine that gets these crashes; have you ever installed Microsoft debugger, Visual Studio, .Net, or any of the MS compiler/debugger toolkits?

thanks
pecan