I still get access violations. I thought that perhaps something on my system was messed up so I booted to another partition that is almost a basic OS install plus a couple of apps. It has never seen code::blocks before. I installed 18 June 2006 build plus the latest mingwm10.dll and wxmsw26u_gcc_cb.dll that I downloaded a couple of nights ago. Opening code::blocks for the first time brings up the compiler dialog. I select my compiler (which is installed on another partition) close the tips dialog, click the open button and get a big dialog entitled "whoa" claiming an access violation.
I've seen a couple of other people mention this now. I'm stuck with 2006/06/10 which seems to be the last stable version which doesn't have this major bug or the other bug where you couldn't save files properly.
Are any of the devs looking into this?
I still get access violations.Well, without a crash report or clear steps to reproduce how should the devs take care? For me C::B simply works - I cannot reproduce this issue. Could you try to compile C::B yourself to see if it's a nightly issue? That would really help.
Are any of the devs looking into this?
did you log in as the system administrator or do you have the privilege to fully control the system? I *guess* that may be the problem.I'm running Windows always in restricted (non-admin) mode. Here it works. I would wonder if access limitation were the reason for such crashes... but who knows? ;-)
did you log in as the system administrator or do you have the privilege to fully control the system? I *guess* that may be the problem.I'm running Windows always in restricted (non-admin) mode. Here it works. I would wonder if access limitation were the reason for such crashes... but who knows? ;-)
With regards, Morten.
did you log in as the system administrator or do you have the privilege to fully control the system? I *guess* that may be the problem.It's my own machine and I only run as administator.
Well, without a crash report or clear steps to reproduce how should the devs take care?Tell me where the crash report is and I'll post it. Clear steps to reproduce? I'm sorry, but I don't see how my post could have been any clearer bar adding pictures. Please tell me which steps you didn't understand and I'll try again.
here it is!This screenshot is not very useful since it does not tell an awful lot.
and the folder cb-crash-recover is empty.I have not had a crash in many weeks now, but when I initially wrote this crash handler, it worked reliably. The code that's writing the backup copies has not been changed since then. All that was changed is that the crash handler is now generally enabled in the nightly builds thanks to dynamic linkage (which it was not before).
This screenshot is not very useful since it does not tell an awful lot.yes, you are right :?
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.Every time I press 'Abort' two or three times to keep the program running, I am pretty sure here.
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.
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.
switch(MessageBox(0, buf.c_str(), _T("Woah!"), MB_ABORTRETRYIGNORE))
{
case IDABORT:
return EXCEPTION_CONTINUE_SEARCH;
break;That's not true, after clicking two or three times on abort C::B doesn't crash.
What makes you say that?
This gives control to the next handler. Unless you have installed a system-wide exception handler of your own, there is none other than the default handler left, which will show "The application has crashed..." and will terminate Code::Blocks.
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?What makes you say that?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.
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.
[...]MinGW 3.4.2
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
@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.
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
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.
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)
This GDB was configured as "i686-pc-mingw32"...(no debugging symbols found)...
@Pecan
I downloaded and installed gdb-5.2.1-1.exe. This is the output I get after typing 'run':
@Pecan
I downloaded and installed gdb-5.2.1-1.exe. This is the output I get after typing 'run':CodeStarting 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)
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.
"C:\mingw\bin\gdb.exe" "C:\Program Files\Code Blocks\codeblocks.exe"Starting program: C:\Program Files\Code Blocks\codeblocks.exe
---Type <return> to continue, or q <return> to quit---
---Type <return> to continue, or q <return> to quit---Program received signal SIGSEGV, Segmentation fault.
0x77ea3c00 in RpcRaiseException () from C:\WINDOWS\system32\rpcrt4.dllNo symbol table is loaded. Use the "file" command.and got:CodeProgram received signal SIGSEGV, Segmentation fault.
0x77ea3c00 in RpcRaiseException () from C:\WINDOWS\system32\rpcrt4.dll
EDIT:
The bad news is, I tried the same thing on my working 2006/06/10 code::blocks and got exactly the same result!
It would be interesting to see what the others are running code::blocks on. Mine is XP home SP2 with all recent hotfixes.
It would be interesting to see what the others are running code::blocks on. Mine is XP home SP2 with all recent hotfixes.
Could you try installing XP sp2 without the hot fixes then run CodeBlocks?
The hotfixes may be the problem.
just guessing.
I am not sure about this, because I too have Windows XP SP2 with all the hotfixes (I always keep my OS up-to-date :)), but never had such problems.
May be there is some kind of libraries/applications conflicts, or partially corrupted OS, or something other.
The official supported compiler to build Code::Blocks with is GCC (or MinGW). At the present time, GCC is also the only compiler known to successfully build Code::Blocks without modifications.I've been happilly using MSVC 2005. so, I go to the MinGW site to see what I need. So much writing, so many downloads, I just left.
Very first thing I read is:QuoteThe official supported compiler to build Code::Blocks with is GCC (or MinGW). At the present time, GCC is also the only compiler known to successfully build Code::Blocks without modifications.I've been happilly using MSVC 2005. so, I go to the MinGW site to see what I need. So much writing, so many downloads, I just left.
@killerbot
Thanks for you're help but I don't even know wwhat any of that stuff is or why I need it.
I'm sorry but I really haven't got the inclination to read and learn a lot of stuff that I don't really want to know which is distracting me from learning what I was enjoying learning --C++ and the Win32 API.
I'm going to stick with the version that works.
Sorry all.
wxWidgets 2.6.3 DownloadsDo I need wxALL, wxMSW, wx GTK, I guess not wxMac, sxX11, I guess not other ports. Or do I need a release version? I know nothing about wxWidgets. I'ts not something I've even looked at within code::blocks, I just know it's there.
* Source Archives
o wxALL (Other formats: bz2, zip)
o wxMSW(Other formats: zip)
o wxGTK
o wxMac
o wxX11
o Other ports (Motif, OS/2, MGL, Base) and releases ...
PS.: In the forums there are helpful posts Smile.Yes, I'm sure there are but as I said, it's not something that interests me enough to spend the time looking.
http://www.mingw.org/download.shtml* gcc-core : the core of the GCC suite
MinGW (GCC 3.4.4/5)
What, binary or source? gcc-objc, gcc-ada, gcc-core, gcc-g++, gcc-g77, I guess not gcc-java.
http://www.mingw.org/download.shtml
MinGW (GCC 3.4.4/5)
What, binary or source? gcc-objc, gcc-ada, gcc-core, gcc-g++, gcc-g77, I guess not gcc-java.
I don't know what those terms mean, I've only being learning c++ for about a year and visual basic for about a year before that. It really isn't as easy as your list suggests if you don't know what all these versions are for and, more to the point, don't really want to know.
Program received signal SIGSEGV, Segmentation fault.I then typed
0x77ea3c00 in RpcRaiseException () from C:\WINDOWS\system32\rpcrt4.dll
bt allNo symbol "all" in current context.
@Michael
Alright, well lets see.
http://wxwidgets.org/downloads/#latest_stable :QuotewxWidgets 2.6.3 DownloadsDo I need wxALL, wxMSW, wx GTK, I guess not wxMac, sxX11, I guess not other ports. Or do I need a release version? I know nothing about wxWidgets. I'ts not something I've even looked at within code::blocks, I just know it's there.
* Source Archives
o wxALL (Other formats: bz2, zip)
o wxMSW(Other formats: zip)
o wxGTK
o wxMac
o wxX11
o Other ports (Motif, OS/2, MGL, Base) and releases ...QuotePS.: In the forums there are helpful posts Smile.Yes, I'm sure there are but as I said, it's not something that interests me enough to spend the time looking.
I see you have svn listed there. I've never had the need to use svn. It's a term I've seen around a bit over the years but I don't really know what it is. If it means spending time reading about it and learning to to use it just so that I try and find out why I'm getting an access violation then, well, I just can't. My mind will start to wander before I've read a couple of sentences.
Thank you though, I know you're only trying to help.
Right, I tried it with gdb. As before, I clicked on the 'open' icon and got:QuoteProgram received signal SIGSEGV, Segmentation fault.I then typed
0x77ea3c00 in RpcRaiseException () from C:\WINDOWS\system32\rpcrt4.dllCodeand got:bt allQuoteNo symbol "all" in current context.