The 28 May 2014 build (9781) is out.

[ToApolytoXaos]

About crashing issue: Can anyone with svn9817 try to create a macro like

Code: [Select]

#define arrsize(array) (sizeof(array) / sizeof(array[0]) )
and let me know if it crashes on insertion of the first parenthesis (?

UPDATE: I ran it with GDB and got the following line upon repeating the aforementioned procedure:

Code: [Select]

0x00007fffe553605e in wxsResourceTree::InvalidateItemData (this=0x0, ItemData=0x49b6b50) at wxsresourcetree.cpp:212
212         if ( m_Data == ItemData )


[oBFusCATed]

Are you sure you build is fine?
If you search the source you'll see that wxsResourceTree is part of wxSmith.
Can you try to unload it and try to reproduce the issue again?

Have you thought about learning how to make dep packages? I doubt it is that hard, but I'm sure it produces reliable binaries.
Using ./configure && make && make install && make unininstall is quite error prone.

[ToApolytoXaos]

Are you sure you build is fine?

Well, it built just fine without reporting any further issue, but seriously I don't know if it's "fine".

If you search the source you'll see that wxsResourceTree is part of wxSmith.
Can you try to unload it and try to reproduce the issue again?

Sure, I will do it right now and I will let you know.

Have you thought about learning how to make dep packages? I doubt it is that hard, but I'm sure it produces reliable binaries.

To be honest, it passed through my mind, but I did not give it a try; maybe it's a good time now, why not?

Using ./configure && make && make install && make unininstall is quite error prone.

To say such thing it means you know more than me and for sure you have far more traumatic experience than I.

I will try your suggestions and I will let you know.

[jens]

Using ./configure && make && make install && make unininstall is quite error prone.

To say such thing it means you know more than me and for sure you have far more traumatic experience than I.

If you build from a build-folder in (or outside) the C::B source-tree and install to a local folder below your home-directory you do not need "make uninstall" (which can fail miserably if file-paths have changed in makefiles).
You can always completely wipe-out your local build and install-folder and be sure no artefacts of former builds are left.

[jens]

Using ./configure && make && make install && make unininstall is quite error prone.

To say such thing it means you know more than me and for sure you have far more traumatic experience than I.

If you build from a build-folder in (or outside) the C::B source-tree and install to a local folder below your home-directory you do not need "make uninstall" (which can fail miserably if file-paths have changed in makefiles).
You can always completely wipe-out your local build and install-folder and be sure no artefacts of former builds are left.

But creating deb-files do not need anything but running dpkg-buildpackage from C::B's root-folder (the one containing the debian-folder).

[ToApolytoXaos]

Yeah jens, I know. I have created the packages and the issue remains the same. I am repeating the steps as I am typing this message to make sure it's not my fault.

UPDATE: Yep, the issue remains the same. Can someone update to latest HEAD revision, compile it, and try a #define something() macro to see whether it crashes on first parenthesis or not?
UPDATE #2: Now that I have compiled .deb packages myself and managed to reproduce the crash, gdb reports the following:

Code: [Select]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff58c0880 in wxMutex::Lock() () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0


[oBFusCATed]

As Jens said using "make uninstall" requires great discipline and care, so it is not recommended in the long run.

Deb packages will fail to if you've not completely cleaned you system from old files!
So you have to uninstall all codeblocks related packages. Then search your folders and remove everything related to C::B, then install the packages.

I've tried your example in r9818 and it worked fine.

[oBFusCATed]

This bt looks more plausible. Can you try to bisect the issue. r9808 seems like a first test revision.

[ToApolytoXaos]

Actually the first test revision I think and I might be wrong here is svn9802, based on log file.

By the way, I rolled back to svn9800, but dpkg-buildpackage -us -uc would generate files based on latest HEAD and not as required revision.

Can you please advice on this?

[ollydbg]

Actually the first test revision I think and I might be wrong here is svn9802, based on log file.

Commit log of 9802:

* CC: apply Huki's patch, it is a small bug fix in nativeparser.cpp, NativeParser::ParseLocalBlock(). The function ParseLocalBlock() is only supposed to be run for function blocks(bodies), but it's actually run for any kind of code block (classes, etc). So for example if the user clicks on a class declaration, the entire class block will be parsed as if it's a local block and several token info (such as the line index) will be overwritten. To fix it a check is added. See: http://forums.codeblocks.org/index.php/topic,18315.msg132338.html#msg132338

-------------------------------
M(T ) : /trunk/src/plugins/codecompletion/nativeparser.cpp

...
UPDATE: Yep, the issue remains the same. Can someone update to latest HEAD revision, compile it, and try a #define something() macro to see whether it crashes on first parenthesis or not?

No crash here I only build C::B HEAD (rev 9818)with all the core plugins under WinXP.

[jens]

Actually the first test revision I think and I might be wrong here is svn9802, based on log file.

By the way, I rolled back to svn9800, but dpkg-buildpackage -us -uc would generate files based on latest HEAD and not as required revision.

Can you please advice on this?

The revision number used is the one in debian/changelog. It might not be the correct number.

[ToApolytoXaos]

Indeed it still points on the latest HEAD even though I ran ./boostrap right after reversing on r9800.

[jens]

Indeed it still points on the latest HEAD even though I ran ./boostrap right after reversing on r9800.

Make sure it is also reverted and remove the hidden file ".last_revision".

[ToApolytoXaos]

Make sure it is also reverted and remove the hidden file ".last_revision".

Done so; still the same :/ It insists to do the same thing as before:

dpkg-buildpackage: source version 13.12svn9818

[jens]

Do you have a tar.gz or similar source-ball on your hdd (from former run of dpkg-buildpackage) ?

By the way, I can confirm the crash on FC21 64-bit build with gcc4.9 !