Author Topic: The 18 June 2006 build is out.  (Read 39099 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5267
The 18 June 2006 build is out.
« on: June 18, 2006, 06:39:52 pm »
Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

A link to the unicode windows wxWidget dll for Code::Blocks : http://download.berlios.de/codeblocks/wxmsw26u_gcc_cb_wx2.6.3p2.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://download.berlios.de/codeblocks/mingwm10.7z

For support of ansi builds, a link to the ansi windows wxWidget dll (2.6.2) for Code::Blocks : http://download.berlios.de/codeblocks/wxmsw26_gcc_cb.7z

The 18 June 2006 build is out.
  - Windows : http://download.berlios.de/codeblocks/CB_20060618_rev2580_win32.7z
  - Linux :
         http://download.berlios.de/codeblocks/CB_20060618_rev2580_Ubuntu6.06.deb
         http://download.berlios.de/codeblocks/CB_20060618_rev2580_fc4+5.rpm


Resolved Fixed:

  • debian changelog change
  • fixed wrong message for cleaning workspace
  • made icons for find/replace consistent
  • added icons for find next / find previous

Regressions/Confirmed/Annoying/Common bugs:

  • toolbar-images-not-changing-state (is a wx problem/Win XP problem)
  • there are several issues with Code Completion (is being redesigned : work in progress)
  • menu items with icon not correctly aligned (since wx263)

« Last Edit: June 18, 2006, 08:54:05 pm by killerbot »

Offline visualphoenix

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: The 18 June 2006 build is out.
« Reply #1 on: June 19, 2006, 12:03:28 am »
Has anyone noticed that trying to directly open a .workspace causes codeblocks to hang?
Ubuntu Dapper Command Line: # codeblocks engine.workspace

hansoon

  • Guest
Re: The 18 June 2006 build is out.
« Reply #2 on: June 19, 2006, 02:26:22 am »
How can i do to use arrow keys with NumLock off?

royalbox

  • Guest
Re: The 18 June 2006 build is out.
« Reply #3 on: June 19, 2006, 02:31:44 am »
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?
« Last Edit: June 19, 2006, 02:36:15 am by royalbox »

Offline oz

  • Multiple posting newcomer
  • *
  • Posts: 47
Re: The 18 June 2006 build is out.
« Reply #4 on: June 19, 2006, 03:15:46 am »
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.

Not only there, it could be happen anywhere. :(

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?

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.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9609
Re: The 18 June 2006 build is out.
« Reply #5 on: June 19, 2006, 09:02:49 am »
I still get access violations.
Are any of the devs looking into this?
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.
With regards, Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9609
Re: The 18 June 2006 build is out.
« Reply #6 on: June 19, 2006, 09:04:14 am »
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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oz

  • Multiple posting newcomer
  • *
  • Posts: 47
Re: The 18 June 2006 build is out.
« Reply #7 on: June 19, 2006, 09:57:12 am »
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.

Yes, hopefully that is the problem, because if I changed a computer lab at school, it never happened any more, same as some personal labtops. it only happens in one lab. but unfortunately, it really does not generate any report, because C::B will not crash. as I said, it keep working as normal, only the window will pop up again and again. right, I will show you the picture next time 8)

here it is! and the folder cb-crash-recover is empty.

[attachment deleted by admin]
« Last Edit: June 19, 2006, 11:34:22 am by oz »

royalbox

  • Guest
Re: The 18 June 2006 build is out.
« Reply #8 on: June 19, 2006, 01:39:06 pm »
Quote
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.

Quote
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.

I appreciate you're all working on this for free and for the fun of it, but clearly something is wrong when more than one person has the same problem.
« Last Edit: June 19, 2006, 01:44:24 pm by royalbox »

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: The 18 June 2006 build is out.
« Reply #9 on: June 19, 2006, 01:41:17 pm »
Quote
here it is!
This screenshot is not very useful since it does not tell an awful lot.

The primary purpose of the crash handler is to allow you avoid a crash and to do a graceful shutdown and to preserve as much data as possible, in defiance of any real occurring crashes.
Nothing sucks as bad as losing your work if you haven't saved for an hour and you encounter a 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.
If you click on "Ignore", the crash handler will increment EP before returning control, this will in most cases cause the program to continue "just normal", but it will of course not write out a RPT.

It is generally still recommended that you save your work and close the application, even if everything seems to be "normal" afterwards, as you really cannot have a clue what internal effects the crash might have had.

Quote
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).
If the crash recovery folder is empty, then you probably did not have any documents open.

Administrator or not should not matter for writing out the backups, since it writes to your "MyFiles" folder -- unless something is horribly screwed up, you always have access to that location.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

royalbox

  • Guest
Re: The 18 June 2006 build is out.
« Reply #10 on: June 19, 2006, 02:01:41 pm »
Please tell me how to generate a crash report. If I click abort, a common dialog will open with the caption "open program". I saved a file to the desktop, but it was empty. Before CB closes it says that this file has been modified, save the changes? Whether I choose OK or Cancel, the file is empty. Please tell me how I can generate a crash report, thanks.

EDIT:
The dialog is just code::blocks continuing to carry out the 'open' command -- because it didn't abort. I assumed it was to save a crash report.
« Last Edit: June 19, 2006, 02:50:20 pm by royalbox »

Offline oz

  • Multiple posting newcomer
  • *
  • Posts: 47
Re: The 18 June 2006 build is out.
« Reply #11 on: June 19, 2006, 02:10:51 pm »
This screenshot is not very useful since it does not tell an awful lot.
yes, you are right :?

Quote
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.

I forgot what happened when I pressed the other buttons, but I will try next time. Oh, I remebered it crashed once by choosing another option, certainly there is a crash report, but I cannot remeber clearly. I will post the report next time.

Offline kkez

  • Almost regular
  • **
  • Posts: 153
    • WinapiZone
Re: The 18 June 2006 build is out.
« Reply #12 on: June 19, 2006, 02:44:16 pm »
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
« Last Edit: June 19, 2006, 02:51:51 pm by kkez »

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: The 18 June 2006 build is out.
« Reply #13 on: June 19, 2006, 03:32:46 pm »
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? First...

Code: [Select]
switch(MessageBox(0, buf.c_str(), _T("Woah!"), MB_ABORTRETRYIGNORE))
    {
        case IDABORT:
        return EXCEPTION_CONTINUE_SEARCH;
        break;
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.


And second...

"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

royalbox

  • Guest
Re: The 18 June 2006 build is out.
« Reply #14 on: June 19, 2006, 05:29:18 pm »
Quote
That's not true, after clicking two or three times on abort C::B doesn't crash.

What makes you say that?

I say this too, and the reason I say it, is because that is what happens. You click on abort and code::blocks carries on running.

Quote
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.

See, the problem here is that you're looking at the code and saying it's not possible that code::blocks doesn't abort. Myself and the other posters are physically clicking abort and seeing that code::blocks doesn't abort. Either we're making it up or it is happening. I can't prove that I'm not making it up but I ask you to consider the possibility that I'm not, and perhaps we can work together to try and find the answer.