User forums > Using Code::Blocks

C::B and Windows 7 64-bit

(1/2) > >>

daniloz:
Hi,

Anyone have any experience in using C::B on Windows 7 64-bit?
I'm considering changing my computer and that's what I'd get...

However, I have a friend who's using C::B on such system and he gets several crashes a day... His has the same config as me (compiled by me), which is:
- C::B trunk r7032
- compiled with MinGW32: gcc version 4.5.1 (tdm-1)
- using wxWidgets 2.8.10, compiled with the same GCC, using the instructions on http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows, i.e.

--- Code: ---mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1  clean
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1

--- End code ---

Thanks for sharing ;-)

oBFusCATed:
Have you tried the nightly builds?
Have you tried to see where are this crashes and report them?

daniloz:

--- Quote from: oBFusCATed on March 04, 2011, 11:10:08 am ---Have you tried the nightly builds?

--- End quote ---
Nope, I have one or two changes that prevents me from going that way...


--- Quote from: oBFusCATed on March 04, 2011, 11:10:08 am ---Have you tried to see where are this crashes and report them?

--- End quote ---
Yes, I've tried to check, but haven't report them yet because I don't have enough information yet.
However, this morning I just catch a freeze using gdb and it seemed to me that the problem is somehow caused by some unicode settings. I know nothing about unicode, but it was a guess based on the trace I saw, here it is:

--- Code: ---Thread 11 (Thread 4296.0x13a8):
#0  Tokenizer::CharInString (this=0x5fef830, ch=3307 L'ë\000',
    chars=0xa6a5b40 L"0\000\061\000\062\000\063\000\064\000\065\000\066\000\067\000\070\000\071\000.\000a\000b\000c\000d
\000e\000f\000A\000B\000C\000D\000E\000F\000X\000x\000L\000l\000")
    at C:/Work/codeblocks_trunk/src/plugins/codecompletion/parser/tokenizer.h:371
#1  0x0a642a9c in Tokenizer::DoGetToken (this=0x5fef830)
    at C:\Work\codeblocks_trunk\src\plugins\codecompletion\parser\tokenizer.cpp:1047
#2  0x0a64383e in Tokenizer::CalcConditionExpression (this=0x5fef830)
    at C:\Work\codeblocks_trunk\src\plugins\codecompletion\parser\tokenizer.cpp:1228
#3  0x0a644491 in Tokenizer::HandleConditionPreprocessor (this=0x5fef830,
    type=ptIf)
    at C:\Work\codeblocks_trunk\src\plugins\codecompletion\parser\tokenizer.cpp:1448
#4  0x0a6423cc in Tokenizer::SkipUnwanted (this=0x5fef830)
    at C:\Work\codeblocks_trunk\src\plugins\codecompletion\parser\tokenizer.cpp:902
#5  0x0a64253f in Tokenizer::SkipUnwanted (this=0x5fef830)
    at C:\Work\codeblocks_trunk\src\plugins\codecompletion\parser\tokenizer.cpp:943
#6  0x0a64253f in Tokenizer::SkipUnwanted (this=0x5fef830)
    at C:\Work\codeblocks_trunk\src\plugins\codecompletion\parser\tokenizer.cpp:943
#7  0x0a642608 in Tokenizer::GetToken (this=0x5fef830)
    at C:\Work\codeblocks_trunk\src\plugins\codecompletion\parser\tokenizer.cpp:963
#8  0x0a62b8d2 in ParserThread::DoParse (this=0x5fef828)
    at C:\Work\codeblocks_trunk\src\plugins\codecompletion\parser\parserthread.cpp:503
#9  0x0a62b67d in ParserThread::Parse (this=0x5fef828)
    at C:\Work\codeblocks_trunk\src\plugins\codecompletion\parser\parserthread.cpp:467
#10 0x0a6577e5 in ParserThread::Execute (this=0x5fef828)
    at C:/Work/codeblocks_trunk/src/plugins/codecompletion/parser/parserthread.h:137
#11 0x00c831fa in cbThreadPool::cbWorkerThread::Entry (this=0x66d7728)
    at C:\Work\codeblocks_trunk\src\sdk\cbthreadpool.cpp:228
#12 0x6277d8c4 in wxmsw28u_gcc_custom!_ZN11wxCondition6SignalEv ()
   from C:\Program Files (x86)\CodeBlocks\wxmsw28u_gcc_custom.dll
#13 0x6277d9f8 in wxmsw28u_gcc_custom!_ZN11wxCondition6SignalEv ()
   from C:\Program Files (x86)\CodeBlocks\wxmsw28u_gcc_custom.dll
#14 0x76921287 in msvcrt!_itow_s () from C:\Windows\syswow64\msvcrt.dll
#15 0x76921328 in msvcrt!_endthreadex () from C:\Windows\syswow64\msvcrt.dll
#16 0x76443677 in KERNEL32!BasepMapModuleHandle ()
   from C:\Windows\syswow64\kernel32.dll
#17 0x08caef20 in ?? ()
#18 0x776e9d42 in ntdll!RtlpNtQueryValueKey ()
   from C:\Windows\SysWOW64\ntdll.dll
#19 0x776e9d15 in ntdll!RtlpNtQueryValueKey ()
   from C:\Windows\SysWOW64\ntdll.dll
#20 0x00000000 in ?? ()

--- End code ---

What catched my attention was ch=3307 L'ë\000'. For me it looks like the "e" character plus umlaut. However, I only have English in my code, no such character. But, windows 7 language was German and somehow I though that C::B was not using the right encoding or something like that.

My workaround was to go to Settings / General Settings / Other Settings and using:
- WINDOWS-1252 as the encoding
- setting "Use this encoding / As default encoding (bypassing C::B's auto-detection)
- and unticking "If conversion fails using the settings above, try system locale settings"

So far, so good...

As I said, this was a long shot and I'm still not sure if this is/was the problem....

oBFusCATed:
I've seen this crash, too, it is pretty random (I think) and hard to reproduce...

If you can crash it 100%, please post the code + your settings

daniloz:

--- Quote from: oBFusCATed on March 04, 2011, 11:45:09 am ---I've seen this crash, too, it is pretty random (I think) and hard to reproduce...

If you can crash it 100%, please post the code + your settings

--- End quote ---
Here, when I have this crash, I have it every time I open the workspace and click on an editor. So, I have to open C::B, close the workspace without clicking on the editor and then reopen and most of the times it works...

However, it is pretty random and only happens when I have a big project open and so on... not easy to minimize the "system"... :-(

Question: Do you have any idea if it's related to unicode? What about my workaround?

Navigation

[0] Message Index

[#] Next page

Go to full version