[Solved]Problem with svn 12446

[Miguel Gimenez]

Looks like memory layout in Squirrel is flaky, see ticket 1102
You can try adding -fno-strict-aliasing to the Squirrel target.

[gd_on]

I have added  -fno-strict-aliasing to the Squirrel target. Effectively, less warnings during the build (a full rebuild), but it's not sufficient: the problem is still there

[oBFusCATed]

Are you still using rev 12446? There were major problems with the new squirrel binding API which I've since fixed.
Have you tried to build the latest trunk?

[gd_on]

I use now svn 12458 (as told in reply #14), but this does not change anything for this specific problem. RPT file is the same (except for addresses).

If you look also in my reply #13, you can see that the problem is not recent, and was already there before the new squirrel rewrite.

[AndrewCot]

I have been able to reproduce the crash with the source from https://github.com/obfuscated/codeblocks_sf and it is crashing in the same spot as my RPT file looks like the same as post#11's codeblocks-g.RPT. The version is reporting as svn-r12459.


 

[AndrewCot]

My debugging shows the crash occurs in the in the SortTemplates() function in the \src\sdk\newfromtemplatedlg.cpp file, but the problem is hard to debug as the variables are wxWidget data types and are not shown in a readable format in the watch window. I have got the wxwidget pretty printing to work, but it is missing some of the structures... More work!!!!!

It looks like there may be some GCC bug as I have added a bunch of logging, but it does not work as my first line "if (data1->pt)" causes a crash. If I set a breakpoint on the line and watch the data1->pt is shows "Cannot access memory at address 0xffffffffd90246c0". When watching data1 is is also pointing to 0xffffffffd90246c0.

I suspect a GCC issue. Anyone got any ideas or any pointers on what to try next?

When I modify the newfromtemplatedlg.cpp the following is the relevant biuld log output:
-------------- Build: sdk in Code::Blocks wx3.1.x (64 bit) (compiler: MSYS2 GNU GCC Compiler)---------------

Running target pre-build steps
.objs31_64\autorevision +wx +int +t .. include/autorevision.h
g++.exe -Wall -std=gnu++11 -m64 -g -Og -pipe -mthreads -fmessage-length=0 -fexceptions -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DNOPCH -DwxUSE_UNICODE -D_WIN64 -Woverloaded-virtual -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -IF:\Andrew_Development\wxWidgets-3.1.5\include -IF:\Andrew_Development\wxWidgets-3.1.5\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Iinclude\tinyxml -Iinclude -Iinclude\tinyxml -Iinclude\scripting\include -Isdk\mozilla_chardet\include -Isdk\mozilla_chardet\include\mfbt -Isdk\mozilla_chardet\include\nsprpub\pr\include -Isdk\mozilla_chardet\include\xpcom -Isdk\mozilla_chardet\include\xpcom\base -Isdk\mozilla_chardet\include\xpcom\glue -Isdk\scripting\bindings -c F:\Andrew_Development\codeblocks_sf\src\sdk\newfromtemplatedlg.cpp -o .objs31_64\sdk\newfromtemplatedlg.o
g++.exe -shared  -Wl,--out-implib=devel31_64\libcodeblocks.a -Wl,--dll -LF:\Andrew_Development\wxWidgets-3.1.5\lib\gcc_dll -Ldevel31_64 <<<OBJECT LIST REMOVED>>>  -o devel31_64\codeblocks.dll -Wl,--enable-auto-image-base -Wl,--add-stdcall-alias -Wl,--enable-auto-import -Wl,--no-undefined -m64  -lshfolder -ltxml -lwxscintilla_cb -lsquirrel -lgdi32 -lwxmsw31u
Output file is devel31_64\codeblocks.dll with size 126.20 MB
Running target post-build steps
cmd /c if not exist devel31_64\share\CodeBlocks mkdir devel31_64\share\CodeBlocks
zip -jq9 devel31_64\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc
cmd /c "cd sdk\resources & zip -0 -q ..\..\devel31_64\share\CodeBlocks\manager_resources.zip images\*.png images\8x8\*.png images\10x10\*.png images\12x12\*.png images\16x16\*.png images\20x20\*.png images\24x24\*.png images\28x28\*.png images\32x32\*.png images\40x40\*.png images\48x48\*.png images\56x56\*.png images\64x64\*.png"

[oBFusCATed]

Can you post a backtrace? Does it crash if you use night builds provided by us?

[AndrewCot]

If I use the nightly SVN12458 it does not crash.

Attached is the GDB backtrace and the codeblocks.rpt for the same exe.

[AndrewCot]

If I comment out the "list->SortItems(SortTemplates, (wxIntPtr)0);" line then the wizard is shown. I have not done any testing on the wizard to see if it works or not.

[gd_on]

Your .rpt file is similar to mine published in reply #11.
As you, I can say that the "official" nighly version published by killerbot works as it should. But, that quite normal, because the problem appears with last gcc compiler's version (after january/february 2021). As the nightly is compiled with gcc 8.1 (a 3 years old version), it is not concerned by this bug.
This bug appears only for windows and 64 bits compilers.
So, is it a gcc problem or a codeblocks one, that's not obvious : new gcc versions are more strict on pointers apparently. I tried to use the same approach than the one I have found for filent.c, but without success until now.

[oBFusCATed]

I can reproduce this with gcc 11.1, but I'm not sure it is the compiler. Somehow the data items gets corrupted when they get to the sort function. Investigating.

[oBFusCATed]

Fixed in SVN. It is odd that the night build works... 

[AndrewCot]

I pulled the latest github changes and rebuilt the exe and it now does not crash on file->new->project.

[gd_on]

Cool. Nice work.
Many thanks