Author Topic: The 07 September 2013 build (9295) is out. (Read 165727 times)

killerbot · « **on:** September 08, 2013, 10:12:44 am »

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works.

A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2812_gcc471-TDM.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc471-TDM.7z
And the exception handler dll (for better crash reports) : http://prdownload.berlios.de/codeblocks/exchndl_gcc471-TDM.7z

The 07 September 2013 build is out.
- Windows :
http://prdownload.berlios.de/codeblocks/CB_20130907_rev9295_win32.7z
- Linux :
none

Resolved Fixed:

applied patch by LETARTARE: http://forums.codeblocks.org/index.php/topic,18250.msg124828.html#msg124828
Move occurrence highlighting from cbEditor into a plugin
pumped underlying squirrel scripting lib from v2.2.4 to v2.2.5 (stable)
add compiler warning : -Wnon-virtual-dtor (Warn if a class has virtual functions but no virtual destructor)
debugger: initial re-implementation of locals and function arguments
Modify the plugin to create two special watches one for locals and one
for arguments. Modify drivers accordingly (CDB does nothing
Enable the options for locals and arguments in the settings
debugger: make locals/args read only (users won't be able to change their values)
Add two new popup menu items in the watches window -> one to switch the
flag for a particular watch and one to update a particular watch manually
debugger: allow the user to control which watches should be updated automatically and which shouldn't

Regressions/Confirmed/Annoying/Common bugs:

killerbot · « **Reply #1 on:** September 08, 2013, 10:13:33 am »

aka : local watches are back.

ollydbg · « **Reply #2 on:** September 08, 2013, 10:28:47 am »

@killerbot, good work!

@all
About the local watches issue. I have a test project which can let python enabled GDB crash. (see the attachment, note you should have both python pretty printers for wx and stl loaded when debugging)
To avoid the crash, I did two things:
1, limit the element number in GDB, normally it is the GDB command:

Code

set print elements 200

My whole gdb script file is below: which also loads wx and stl pretty printers.

Code

python
import sys
sys.path.insert(0, '')
from libstdcxx.v6.printers import register_libstdcxx_printers
register_libstdcxx_printers (None)
from libwx.v28.printers import register_libwx_printers
register_libwx_printers (None)
end
set print elements 200
set filename-display absolute

2, I have a modified GDB with local patches to fix the GDB crash issue, see this post:
unofficial MinGW GDB gdb with python released, especially the patch in this links: Bug 12127 – gdb with python support still get crash on showing uninitialized local variables

EDIT: add the attachment.

oBFusCATed · « **Reply #3 on:** September 08, 2013, 11:14:07 am »

Quote from: killerbot on September 08, 2013, 10:13:33 am

aka : local watches are back.

You've been warned about the problems:
1. Crashes of GDB, random, I've tried with GDB 7.6+python. C::B is almost undebuggable with locals/funcs args enabled, probably every other bigger C++ project
2. Slowness during stepping
3. uninitialized vectors crash gdb or at least produce tons of output, when you break at the initialization or before it
4. set print elements 200 doesn't help much

BTW: I don't intend to do anything about all these problems, so you either try to fix them yourself or just disable the feature!

Jenna · « **Reply #4 on:** September 08, 2013, 05:25:27 pm »

As usual (and most of the time updated more frequently):

Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo.
Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc18, fc19 and fc20) and RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) can be found in my rpm-repo .
Fedora 17 is no longer maintained (EOL) and I can not build packages for it any more (mock support discontinued).

The packages that are striked through are not yet available.
Debian packages are currently compiling and will come this evening.
The revision on my server is svn r9298.

goral · « **Reply #5 on:** September 09, 2013, 11:19:35 am »

Thanks for locals and function arguments in Watches window.

But there is a problem with Call stack and Running threads windows now: its ok, when I press Break debugger button. But then when I am switching to another threads, Call stack is empty and list of threads in Runing threads window is changing.

Tested with CB SVN 9298 (and 9296) on Fedora 18 x86_64, GCC 4.7.2.

oBFusCATed · « **Reply #6 on:** September 09, 2013, 11:22:27 am »

Quote from: goral on September 09, 2013, 11:19:35 am

But there is a problem with Call stack and Running threads windows now: its ok, when I press Break debugger button. But then when I am switching to another threads, Call stack is empty and list of threads in Runing threads window is changing.

Known problem, last time I've tried to fix it, I couldn't...

Manolo · « **Reply #7 on:** September 12, 2013, 01:01:36 am »

Hi all

What happened with share\CodeBlocks\SpellChecker folder? Build 9295 lacks it.

Regards,
Manolo

cacb · « **Reply #8 on:** September 12, 2013, 09:34:44 am »

Hi,

This is for the current Windows nightly: It looks like all the wxSmith images were missing from this version, there were no icons in the "Resources" tab of the "Management" pane. I had it working in a previous version (9246), so I copied the images from there, and it seems to have fixed it

Copied from ...\CB_20130806_rev9246_win32\share\CodeBlocks\images\wxsmith
Copied to ...\CB_20130907_rev9295_win32\share\CodeBlocks\images\wxsmith

The folder marked in red was missing entirely.

ollydbg · « **Reply #9 on:** September 12, 2013, 09:45:11 am »

I got a hang problem:
1, open this nightly build version
2, open codeblocks.cbp
3, cb hangs
I meet this kind of problem from time to time, no crash report is generated when I close c::b.
See the image shot when C::B hangs:

Jenna · « **Reply #10 on:** September 12, 2013, 10:07:12 am »

Quote from: cacb on September 12, 2013, 09:34:44 am

Hi,

This is for the current Windows nightly: It looks like all the wxSmith images were missing from this version, there were no icons in the "Resources" tab of the "Management" pane. I had it working in a previous version (9246), so I copied the images from there, and it seems to have fixed it

Copied from ...\CB_20130806_rev9246_win32\share\CodeBlocks\images\wxsmith
Copied to ...\CB_20130907_rev9295_win32\share\CodeBlocks\images\wxsmith

The folder marked in red was missing entirely.

Many more folders are missing:
share/CodeBlocks/SpellChecker
share/CodeBlocks/docs
share/CodeBlocks/images/DoxyBlocks
share/CodeBlocks/images/ThreadSearch
share/CodeBlocks/images/codesnippets
share/CodeBlocks/images/fortranproject
share/CodeBlocks/images/wxsmith
share/CodeBlocks/lib_finder
share/CodeBlocks/templates/wizard/sfml/files (this might be deliberately)

also some images (all png's) used by the settings-panel:
share/CodeBlocks/images/settings/DoxyBlocks*
share/CodeBlocks/images/settings/SpellChecker*
share/CodeBlocks/images/settings/ThreadSearch*
share/CodeBlocks/images/settings/ToolsPlus*
share/CodeBlocks/images/settings/incsearch*

zhanglyl · « **Reply #11 on:** September 13, 2013, 09:26:15 am »

From my Virus Scanner Application (Kingsoft Duba), the "codeblocks.exe" was found malware "win32.heurc.kvm011.a.(kcloud)". Do you find?

ollydbg · « **Reply #12 on:** September 13, 2013, 09:32:37 am »

Quote from: zhanglyl on September 13, 2013, 09:26:15 am

From my Virus Scanner Application (Kingsoft Duba), the "codeblocks.exe" was found malware "win32.heurc.kvm011.a.(kcloud)". Do you find?

It's false alarm. see the related discussion in installed cb 21.11 but AVG detects it as a virus

ollydbg · « **Reply #13 on:** September 15, 2013, 05:22:49 pm »

@OBF: when debugging, I try to turn off the "local variable and function arguments" feature, which cause C::B crash. This could be a bug.

oBFusCATed · « **Reply #14 on:** September 16, 2013, 10:03:39 am »

Exact steps to reproduce, please.

ollydbg · « **Reply #15 on:** September 16, 2013, 05:29:39 pm »

Quote from: oBFusCATed on September 16, 2013, 10:03:39 am

Exact steps to reproduce, please.

Very simple steps:
Suppose you have both "watch local variables" and "watch function arguments" setting selected in the debugger setting dialog
1, create a simple console project
2, set a breakpoint
3, build and start to debug the project
4, when debugger hit the breakpoint, go to the debugger setting dialog, and deselect both "watch function arguments" and "watch local variables"
5, press OK
6, crash!

oBFusCATed · « **Reply #16 on:** September 16, 2013, 06:07:11 pm »

Reproduced.

oBFusCATed · « **Reply #17 on:** September 16, 2013, 10:19:09 pm »

Fix in trunk.

ollydbg · « **Reply #18 on:** October 01, 2013, 04:01:26 pm »

Bug report here: call stack information was shown in threads info windows.
Steps to reproduce:
1, suppose the call stack and threads window were no shown.
2, clear the whole debugger log
3, open the threads window->show correctly
4, open the call stack window->show correctly
5, double click on one frame of the stack window
6, I see both the two window get refreshed. stack window becomes empty, all the stack was shown in threads window.
Screen shot below:

Log message in attachment.
Maybe, the opened disassembler windows cause this issue?

[attachment deleted by admin]

oBFusCATed · « **Reply #19 on:** October 01, 2013, 04:05:15 pm »

Quote from: ollydbg on October 01, 2013, 04:01:26 pm

Bug report here: call stack information was shown in threads info windows.

Known bug, can't be fixed or at least I can't.

carra · « **Reply #20 on:** October 01, 2013, 05:07:13 pm »

In the last nightlies (the ones after 12.11) I have seen a change in the way abbreviation parsers work. They got less practical for editing. Let me explain:

Say you have a line like the following (where | is the caret): |int i = 70;

If there you type an abbreviation (let's use a built-in one: "now") the line will be now|int i = 70;

Previous versions of C::B parsed only BEFORE the caret, and correctly recognised and replaced the abbreviation. In current versions, however, it seems that "nowint" gets parsed as a WHOLE word. Therefore abbreviations now only work if there are spaces.

oBFusCATed · « **Reply #21 on:** October 01, 2013, 05:23:46 pm »

Quote from: carra on October 01, 2013, 05:07:13 pm

In the last nightlies (the ones after 12.11) I have seen a change in the way abbreviation parsers work. They got less practical for editing. Let me explain:

Can you tell us which is the first broken nightly?

Alpha · « **Reply #22 on:** October 01, 2013, 06:31:25 pm »

Quote from: oBFusCATed on October 01, 2013, 05:23:46 pm

Can you tell us which is the first broken nightly?

Most likely here

Code

http://cb.biplab.in/websvn/comp.php?repname=codeblocks&compare[]=/trunk/src/plugins/abbreviations/abbreviations.cpp@8519&compare[]=/trunk/src/plugins/abbreviations/abbreviations.cpp@8520

carra · « **Reply #23 on:** October 01, 2013, 10:09:05 pm »

That could be it... I can't pinpoint an exact version since I haven't been updating much. But if the change is in 8520, it is older than I thought.

oBFusCATed · « **Reply #24 on:** October 01, 2013, 11:10:18 pm »

carra: Can you do binary search using nightly builds?

carra · « **Reply #25 on:** October 02, 2013, 03:08:04 pm »

No problem, I will do it when I have some free time. Hopefully that will narrow down the range of commits sufficiently.

oBFusCATed · « **Reply #26 on:** October 02, 2013, 03:11:11 pm »

If you can build from svn, the best you can try is to revert the commit mentioned by Alpha to see if the error goes away.

MortenMacFly · « **Reply #27 on:** October 02, 2013, 04:57:54 pm »

Quote from: oBFusCATed on October 02, 2013, 03:11:11 pm

If you can build from svn, the best you can try is to revert the commit mentioned by Alpha to see if the error goes away.

Well reverting is not an option in my opinion. I've applied the patch because I found it really useful once you are used to the new feature. This requires word matching and I didn't think of the use-case to apply abbreviations in the middle of a word. I'll see if I can find a way to support this, too (although I'd say its not the standard way you'd use abbreviations, isn't it?!)

oBFusCATed · « **Reply #28 on:** October 02, 2013, 05:38:54 pm »

The revert suggestion was just for testing if this is the commit that breaks it.

carra · « **Reply #29 on:** October 02, 2013, 07:54:06 pm »

Quote from: MortenMacFly on October 02, 2013, 04:57:54 pm

I didn't think of the use-case to apply abbreviations in the middle of a word. I'll see if I can find a way to support this, too (although I'd say its not the standard way you'd use abbreviations, isn't it?!)

Oh I wouldn't worry aboud that. I don't think I ever use abbreviations in the middle of words. I do sometimes use them at the beginning of a word (like in my previous example), but MOST of the time, what bugs me is being unable to use an abbreviation right at the start of a line. This can correspond to inserting separators or new sections of code. Example: Adding a new "case" statement in between a switch, or a new method inside a class

Alpha · « **Reply #30 on:** October 02, 2013, 11:11:03 pm »

Quote from: carra on October 02, 2013, 07:54:06 pm

I do sometimes use them at the beginning of a word (like in my previous example), but MOST of the time, what bugs me is being unable to use an abbreviation right at the start of a line. This can correspond to inserting separators or new sections of code. Example: Adding a new "case" statement in between a switch, or a new method inside a class

I do not have time to work on this right now, but if you are interested, search src/plugins/abbreviations/abbreviations.cpp for control->WordEndPosition and look to patch it so that it will check, for example, if the whole word it is in (current style) is valid, else fall back to prefix up to caret position is valid (previous style).

goral · « **Reply #31 on:** November 19, 2013, 10:46:54 am »

Quote from: oBFusCATed on September 09, 2013, 11:22:27 am

Quote from: goral on September 09, 2013, 11:19:35 am
But there is a problem with Call stack and Running threads windows now: its ok, when I press Break debugger button. But then when I am switching to another threads, Call stack is empty and list of threads in Runing threads window is changing.
Known problem, last time I've tried to fix it, I couldn't...

Is there any hope that this will be fixed?
I really miss that...

oBFusCATed · « **Reply #32 on:** November 23, 2013, 05:44:47 pm »

Quote from: goral on November 19, 2013, 10:46:54 am

Is there any hope that this will be fixed?
I really miss that...

Not in the current version of the plugin, I'm only fixing simple to fix bug in it.
There is another plugin in the works that uses the safer GDB interface - GDB/MI, but I have no time to work on it at the moment, unfortunately.

ToApolytoXaos · « **Reply #33 on:** November 23, 2013, 08:10:40 pm »

Still facing crashing issues even with svn9462. The only thing that runs into my mind is my graphics card, an NVidia FX5200 256MB. Both proprietary and nouveau (vesa) drivers crash applications or even freeze the entire DE. Currently cannot afford to set up a new PC :/

Code

Program received signal SIGSEGV, Segmentation fault.
0xb73a2f5b in wxFrame::OnInternalIdle() () from /usr/lib/i386-linux-gnu/libwx_gtk2u_core-2.8.so.0
(gdb) backtrace
#0  0xb73a2f5b in wxFrame::OnInternalIdle() () from /usr/lib/i386-linux-gnu/libwx_gtk2u_core-2.8.so.0
#1  0xb73c93c9 in wxAppBase::SendIdleEvents(wxWindow*, wxIdleEvent&) () from /usr/lib/i386-linux-gnu/libwx_gtk2u_core-2.8.so.0
#2  0xb73c98ee in wxAppBase::ProcessIdle() () from /usr/lib/i386-linux-gnu/libwx_gtk2u_core-2.8.so.0
#3  0xb7333f62 in ?? () from /usr/lib/i386-linux-gnu/libwx_gtk2u_core-2.8.so.0
#4  0xb66ce140 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#5  0xb66d142e in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0
#6  0xb66d17d8 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#7  0xb66d1c3b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#8  0xb6d4b140 in gtk_main () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#9  0xb734a3de in wxEventLoop::Run() () from /usr/lib/i386-linux-gnu/libwx_gtk2u_core-2.8.so.0
#10 0xb73c969f in wxAppBase::MainLoop() () from /usr/lib/i386-linux-gnu/libwx_gtk2u_core-2.8.so.0
#11 0xb73c919f in wxAppBase::OnRun() () from /usr/lib/i386-linux-gnu/libwx_gtk2u_core-2.8.so.0
#12 0x0808addb in CodeBlocksApp::OnRun (this=0x821bbb8) at app.cpp:809
#13 0xb710db36 in wxEntry(int&, wchar_t**) () from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#14 0xb710dbd6 in wxEntry(int&, char**) () from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#15 0x080885c4 in main (argc=3, argv=0xbffff464) at app.cpp:276

oBFusCATed · « **Reply #34 on:** November 23, 2013, 09:05:07 pm »

Can you try running under valgrind?

ToApolytoXaos · « **Reply #35 on:** November 24, 2013, 01:46:47 pm »

Yes, but it did not crash now with valgrind. I have checked though for memory leaks and saved the process in a log file.

Below you may find the report as an attachment in the form of an archive file.

Cheers.

[attachment deleted by admin]

oBFusCATed · « **Reply #36 on:** November 24, 2013, 01:52:19 pm »

Ok, next thing to try is under gdb to execute the command "thread apply all bt" and paste the output

ToApolytoXaos · « **Reply #37 on:** November 24, 2013, 02:24:34 pm »

Code

(gdb) run --verbose --debug-log
Starting program: /usr/local/bin/codeblocks --verbose --debug-log
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
[New Thread 0xad642b40 (LWP 16776)]
[New Thread 0xaccadb40 (LWP 16777)]
[New Thread 0xac4acb40 (LWP 16778)]
[New Thread 0xabcabb40 (LWP 16779)]
[New Thread 0xa9b1ab40 (LWP 16811)]
[New Thread 0xa91ffb40 (LWP 16814)]
[New Thread 0xa88e0b40 (LWP 16816)]
[Thread 0xa88e0b40 (LWP 16816) exited]

Program received signal SIGSEGV, Segmentation fault.
0x0853392a in ?? ()
(gdb) thread apply all bt

Thread 7 (Thread 0xa91ffb40 (LWP 16814)):
#0  0xb7fde424 in __kernel_vsyscall ()
#1  0xb65de7ab in pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:187
#2  0xb7167016 in wxConditionInternal::Wait() ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#3  0xb7167d66 in wxCondition::Wait() ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#4  0xb7167da8 in wxSemaphoreInternal::Wait() ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#5  0xb71685b6 in wxSemaphore::Wait() ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#6  0xaa415de0 in ClassBrowserBuilderThread::Entry (this=0xa92c008)
    at classbrowserbuilderthread.cpp:191
#7  0xb716868b in wxThreadInternal::PthreadStart(wxThread*) ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#8  0xb71686fb in wxPthreadStart ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#9  0xb65dacf1 in start_thread (arg=0xa91ffb40) at pthread_create.c:311
#10 0xb63c608e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:131

---Type <return> to continue, or q <return> to quit---
Thread 6 (Thread 0xa9b1ab40 (LWP 16811)):
#0  0xb7fde424 in __kernel_vsyscall ()
#1  0xb63be251 in select () at ../sysdeps/unix/syscall-template.S:81
#2  0xaaad67fa in MonDescriptors::do_select (this=0xa9b19010)
    at directorymonitor.cpp:70
#3  0xaaad6eb0 in DirMonitorThread::Entry (this=0xa83adb8)
    at directorymonitor.cpp:164
#4  0xb716868b in wxThreadInternal::PthreadStart(wxThread*) ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#5  0xb71686fb in wxPthreadStart ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#6  0xb65dacf1 in start_thread (arg=0xa9b1ab40) at pthread_create.c:311
#7  0xb63c608e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:131

Thread 5 (Thread 0xabcabb40 (LWP 16779)):
#0  0xb7fde424 in __kernel_vsyscall ()
#1  0xb65de7ab in pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:187
#2  0xb7167016 in wxConditionInternal::Wait() ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#3  0xb7167d66 in wxCondition::Wait() ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
---Type <return> to continue, or q <return> to quit---
#4  0xb7167da8 in wxSemaphoreInternal::Wait() ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#5  0xb71685b6 in wxSemaphore::Wait() ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#6  0xb7b95602 in BackgroundThread::Entry (this=0x894a57c)
    at ./backgroundthread.h:152
#7  0xb716868b in wxThreadInternal::PthreadStart(wxThread*) ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#8  0xb71686fb in wxPthreadStart ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#9  0xb65dacf1 in start_thread (arg=0xabcabb40) at pthread_create.c:311
#10 0xb63c608e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:131

Thread 4 (Thread 0xac4acb40 (LWP 16778)):
#0  0xb7fde424 in __kernel_vsyscall ()
#1  0xb65de7ab in pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:187
#2  0xb7167016 in wxConditionInternal::Wait() ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#3  0xb7167d66 in wxCondition::Wait() ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#4  0xb7167da8 in wxSemaphoreInternal::Wait() ()
---Type <return> to continue, or q <return> to quit---
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#5  0xb71685b6 in wxSemaphore::Wait() ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#6  0xb7b95602 in BackgroundThread::Entry (this=0x894a560)
    at ./backgroundthread.h:152
#7  0xb716868b in wxThreadInternal::PthreadStart(wxThread*) ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#8  0xb71686fb in wxPthreadStart ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#9  0xb65dacf1 in start_thread (arg=0xac4acb40) at pthread_create.c:311
#10 0xb63c608e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:131

Thread 3 (Thread 0xaccadb40 (LWP 16777)):
#0  0xb7fde424 in __kernel_vsyscall ()
#1  0xb65de7ab in pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:187
#2  0xb7167016 in wxConditionInternal::Wait() ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#3  0xb7167d66 in wxCondition::Wait() ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#4  0xb7167da8 in wxSemaphoreInternal::Wait() ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
---Type <return> to continue, or q <return> to quit---
#5  0xb71685b6 in wxSemaphore::Wait() ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#6  0xb7b95602 in BackgroundThread::Entry (this=0x894a544)
    at ./backgroundthread.h:152
#7  0xb716868b in wxThreadInternal::PthreadStart(wxThread*) ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#8  0xb71686fb in wxPthreadStart ()
   from /usr/lib/i386-linux-gnu/libwx_baseu-2.8.so.0
#9  0xb65dacf1 in start_thread (arg=0xaccadb40) at pthread_create.c:311
#10 0xb63c608e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:131

Thread 2 (Thread 0xad642b40 (LWP 16776)):
#0  0xb7fde424 in __kernel_vsyscall ()
#1  0xb63b78ab in poll () at ../sysdeps/unix/syscall-template.S:81
#2  0xb66e076b in g_poll () from /lib/i386-linux-gnu/libglib-2.0.so.0
#3  0xb66d1758 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4  0xb66d1c3b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#5  0xb6ab425a in ?? () from /usr/lib/i386-linux-gnu/libgio-2.0.so.0
#6  0xb66f6fea in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#7  0xb65dacf1 in start_thread (arg=0xad642b40) at pthread_create.c:311
#8  0xb63c608e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:131

Thread 1 (Thread 0xb4f4e900 (LWP 15909)):
---Type <return> to continue, or q <return> to quit---
#0  0x0853392a in ?? ()
#1  0x00000000 in ?? ()
(gdb)

oBFusCATed · « **Reply #38 on:** November 24, 2013, 02:31:00 pm »

Nothing interesting in here, too.

Can you try to disable plugins one by one and then tell us which causes the crashes?

ToApolytoXaos · « **Reply #39 on:** November 24, 2013, 03:47:47 pm »

Quote from: oBFusCATed on November 24, 2013, 02:31:00 pm

Nothing interesting in here, too.

Can you try to disable plugins one by one and then tell us which causes the crashes?

An interesting issue appeared; I went to Plugins > Manage plugins...boom! An error message window popped up "Codeblocks error: Failed to create a temporary file name (error 13: Permission denied)". All plugins are enabled.

Suggestion: I have tried to disable my plugins, one by one from command line and unfortunately such option is not available (other than --safe-mode).

Could it be possible to add each plugin as argument of type --disable-<plugin-name> so a user could disable a problematic plugin upon need?

Jenna · « **Reply #40 on:** November 24, 2013, 04:03:57 pm »

Quote from: ToApolytoXaos on November 24, 2013, 03:47:47 pm

Quote from: oBFusCATed on November 24, 2013, 02:31:00 pm
Nothing interesting in here, too.

Can you try to disable plugins one by one and then tell us which causes the crashes?
An interesting issue appeared; I went to Plugins > Manage plugins...boom! An error message window popped up "Codeblocks error: Failed to create a temporary file name (error 13: Permission denied)". All plugins are enabled.

Suggestion: I have tried to disable my plugins, one by one from command line and unfortunately such option is not available (other than --safe-mode).

Could it be possible to add each plugin as argument of type --disable-<plugin-name> so a user could disable a problematic plugin upon need?

The error about the temp-file is normally harmless and should only appear if C::B is started with the -v option.

ToApolytoXaos · « **Reply #41 on:** November 24, 2013, 05:12:34 pm »

Quote from: oBFusCATed on November 24, 2013, 02:31:00 pm

Can you try to disable plugins one by one and then tell us which causes the crashes?

I have disabled all plugins and followed a linear order; when I enabled DragScroll it got crashed. I have tried to reproduce it unsuccessfully; I then decided to continue enabling plugins and restarting C::B. As soon as I reached Valgrind, upon enabling I got it to crash. The error messages are those I have shared here; nothing new, sorry

oBFusCATed · « **Reply #42 on:** November 24, 2013, 05:46:17 pm »

Your last post is quite confusing. Do you see the original crash or a new crash?

ToApolytoXaos · « **Reply #43 on:** November 24, 2013, 06:08:21 pm »

Quote from: oBFusCATed on November 24, 2013, 05:46:17 pm

Your last post is quite confusing. Do you see the original crash or a new crash?

The two previous crashes I reported here are still the same.

http://forums.codeblocks.org/index.php/topic,18323.msg127422.html#msg127422

http://forums.codeblocks.org/index.php/topic,18323.msg127442.html#msg127442

oBFusCATed · « **Reply #44 on:** November 24, 2013, 07:11:31 pm »

So you're getting crashes with valgrind enabled and no crashes with valgrind disabled?

ToApolytoXaos · « **Reply #45 on:** November 24, 2013, 10:34:17 pm »

As I have stated before

Quote

I have disabled all plugins and followed a linear order; when I enabled DragScroll it got crashed. I have tried to reproduce it unsuccessfully; I then decided to continue enabling plugins and restarting C::B. As soon as I reached Valgrind, upon enabling I got it to crash.

BUT, I cannot reproduce it.

One indication though is the drawing of right scrollbar; as soon as it starts to "draw" it, occasionally it's there where at random times it gets the crash. I could swear it's something that has to do with my graphics card's drivers, both free and proprietary.

Unfortunately, I lack the advanced knowledge to go that deep and find out what could possibly cause the problem. I don't know, is it something that has to do with drawing, with rendering? I don't know

P.S.: Graphics Card info: NVidia FX 5200, 256MB

oBFusCATed · « **Reply #46 on:** November 24, 2013, 10:46:15 pm »

Can you do the following, so you can verify that you machine has no hardware problems:
1. run memcheck86 for several hours
2. run prime95 torture test -> blend for several hours
3. also run some fsck-ing on the file systems to see if there are no errors there
4. run a hdd surface scan test

ToApolytoXaos · « **Reply #47 on:** November 24, 2013, 10:55:43 pm »

Quote from: oBFusCATed on November 24, 2013, 10:46:15 pm

Can you do the following, so you can verify that you machine has no hardware problems:
1. run memcheck86 for several hours
2. run prime95 torture test -> blend for several hours
3. also run some fsck-ing on the file systems to see if there are no errors there
4. run a hdd surface scan test

Steps 3 and 4 are scheduled to run at every 23rd start up.
1 and 2 I have to test them on next coming week I guess when I will have time available to have the PC turned on all day.

oBFusCATed · « **Reply #48 on:** November 25, 2013, 12:26:27 am »

One night is enough, no need to leave it running all day.

News:

Author Topic: The 07 September 2013 build (9295) is out. (Read 165727 times)

ToApolytoXaos

ToApolytoXaos

ToApolytoXaos

ToApolytoXaos

ToApolytoXaos

ToApolytoXaos

ToApolytoXaos

ToApolytoXaos