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

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5138
The 07 September 2013 build (9295) is out.
« 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:



    Offline killerbot

    • Administrator
    • Lives here!
    • *****
    • Posts: 5138
    Re: The 07 September 2013 build (9295) is out.
    « Reply #1 on: September 08, 2013, 10:13:33 am »
    aka :   local watches are back.

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5163
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 07 September 2013 build (9295) is out.
    « 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: [Select]
    set print elements 200
    My whole gdb script file is below: which also loads wx and stl pretty printers.
    Code: [Select]
    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.
    « Last Edit: September 08, 2013, 10:32:13 am by ollydbg »
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « Reply #3 on: September 08, 2013, 11:14:07 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!
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 07 September 2013 build (9295) is out.
    « 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.

    Offline goral

    • Single posting newcomer
    • *
    • Posts: 6
    Re: The 07 September 2013 build (9295) is out.
    « 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.

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « Reply #6 on: September 09, 2013, 11:22:27 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...
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline Manolo

    • Multiple posting newcomer
    • *
    • Posts: 46
    Re: The 07 September 2013 build (9295) is out.
    « 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

    Offline cacb

    • Regular
    • ***
    • Posts: 381
    Re: The 07 September 2013 build (9295) is out.
    « 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.

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5163
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 07 September 2013 build (9295) is out.
    « 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:
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 07 September 2013 build (9295) is out.
    « Reply #10 on: September 12, 2013, 10:07:12 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*

    Offline zhanglyl

    • Single posting newcomer
    • *
    • Posts: 4
    Re: The 07 September 2013 build (9295) is out.
    « 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?

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5163
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 07 September 2013 build (9295) is out.
    « Reply #12 on: September 13, 2013, 09:32:37 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
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5163
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 07 September 2013 build (9295) is out.
    « 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. ;)
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « Reply #14 on: September 16, 2013, 10:03:39 am »
    Exact steps to reproduce, please.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5163
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 07 September 2013 build (9295) is out.
    « Reply #15 on: September 16, 2013, 05:29:39 pm »
    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!

    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « Reply #16 on: September 16, 2013, 06:07:11 pm »
    Reproduced.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « Reply #17 on: September 16, 2013, 10:19:09 pm »
    Fix in trunk.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5163
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 07 September 2013 build (9295) is out.
    « 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]
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « Reply #19 on: October 01, 2013, 04:05:15 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.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline carra

    • Multiple posting newcomer
    • *
    • Posts: 114
    Re: The 07 September 2013 build (9295) is out.
    « 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.

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « Reply #21 on: October 01, 2013, 05:23:46 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?
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline Alpha

    • Developer
    • Lives here!
    • *****
    • Posts: 1513
    Re: The 07 September 2013 build (9295) is out.
    « Reply #22 on: October 01, 2013, 06:31:25 pm »
    Can you tell us which is the first broken nightly?
    Most likely here
    Code: [Select]
    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

    Offline carra

    • Multiple posting newcomer
    • *
    • Posts: 114
    Re: The 07 September 2013 build (9295) is out.
    « 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.

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « Reply #24 on: October 01, 2013, 11:10:18 pm »
    carra: Can you do binary search using nightly builds?
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline carra

    • Multiple posting newcomer
    • *
    • Posts: 114
    Re: The 07 September 2013 build (9295) is out.
    « 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.

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « 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.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline MortenMacFly

    • Administrator
    • Lives here!
    • *****
    • Posts: 9475
    Re: The 07 September 2013 build (9295) is out.
    « Reply #27 on: October 02, 2013, 04:57:54 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?!)
    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

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « 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.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline carra

    • Multiple posting newcomer
    • *
    • Posts: 114
    Re: The 07 September 2013 build (9295) is out.
    « Reply #29 on: October 02, 2013, 07:54:06 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

    Offline Alpha

    • Developer
    • Lives here!
    • *****
    • Posts: 1513
    Re: The 07 September 2013 build (9295) is out.
    « Reply #30 on: October 02, 2013, 11:11:03 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).

    Offline goral

    • Single posting newcomer
    • *
    • Posts: 6
    Re: The 07 September 2013 build (9295) is out.
    « Reply #31 on: November 19, 2013, 10:46:54 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...

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « Reply #32 on: November 23, 2013, 05:44:47 pm »
    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.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    ToApolytoXaos

    • Guest
    Re: The 07 September 2013 build (9295) is out.
    « 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: [Select]
    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

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « Reply #34 on: November 23, 2013, 09:05:07 pm »
    Can you try running under valgrind?
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    ToApolytoXaos

    • Guest
    Re: The 07 September 2013 build (9295) is out.
    « 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]

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « 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
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    ToApolytoXaos

    • Guest
    Re: The 07 September 2013 build (9295) is out.
    « Reply #37 on: November 24, 2013, 02:24:34 pm »
    Code: [Select]
    (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)

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « 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?
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    ToApolytoXaos

    • Guest
    Re: The 07 September 2013 build (9295) is out.
    « Reply #39 on: November 24, 2013, 03:47:47 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?
    « Last Edit: November 24, 2013, 03:52:19 pm by ToApolytoXaos »

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 07 September 2013 build (9295) is out.
    « Reply #40 on: November 24, 2013, 04:03:57 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

    • Guest
    Re: The 07 September 2013 build (9295) is out.
    « Reply #41 on: November 24, 2013, 05:12:34 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 :(

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « 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?
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    ToApolytoXaos

    • Guest
    Re: The 07 September 2013 build (9295) is out.
    « Reply #43 on: November 24, 2013, 06:08:21 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

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « Reply #44 on: November 24, 2013, 07:11:31 pm »
    So you're getting crashes with valgrind enabled and no crashes with valgrind disabled?
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    ToApolytoXaos

    • Guest
    Re: The 07 September 2013 build (9295) is out.
    « 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

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « 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
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    ToApolytoXaos

    • Guest
    Re: The 07 September 2013 build (9295) is out.
    « Reply #47 on: November 24, 2013, 10:55:43 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.

    Online oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11399
      • Travis build status
    Re: The 07 September 2013 build (9295) is out.
    « Reply #48 on: November 25, 2013, 12:26:27 am »
    One night is enough, no need to leave it running all day.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]