Strange crash

[Grit Clef]

Hi,
       I finished building a small wxwidgets program this morning, and then I closed CB. After several hours(now) I reopened it to do some changes. But it crashed. And that was strange! I was just looking  through an article while CB starting, to my surprise, CB suddenly told me it crashed. Then I retried to start it, (I can ensure that I did nothing this time during CB's start) but it crashed again as soon as CB's start page appeared.
      I use CB r13426, on a Windows 7 32-bit system.
      The RPT file is attached. Any solution?

      Edit:Now I put my early backup of CB's conf file into the AppData directory, CB can work well.

[Pecan]

Glad you got it working again.

This has, on rare occasions, also happened to me. Especially when I kill CB during a debugging session.
It appears to set the .conf file in a bad condition, thereby crashing CB on any restart.
I also just restore the .conf and keep on trunkin'.

The .RPT file, in this case, is useless because I can see no way to map the crash address to the causing function.

If you are compiling CB yourself, you can:
1) Backup output32_64.
2 Copy the devel32_64 dir to output32_64 dir so that the .RPT shows the actual source line that caused the error.

Thanks for the report.

[Grit Clef]

OK, sometime I'll try to give you the debug rpt.

[Grit Clef]

Hey Pecan!
       I've made CB crash again, with debug info! This time is, I clicked "Compile Current File" by mistake, and CB crashed after a short halt. I think this RPT file might contain the same info as CB generated that time it crashed at startup. Also, I'm always annoyed when it crashes right after I make CB compile/build some files/projects. Hope this rpt will give you much useful info.

[Wkerry]

Can you reproduce the crash? If you used a debug build then the RPT is way more useful.

[Miguel Gimenez]

CompilerGCC::PrepareCompileFile(wxFileName& file) checks if the editor pointer is not null, but inmediately after it uses the pointer anyway.

Code

    cbEditor* ed = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
    if (ed)
    {
        // make sure it is saved
        ed->Save();
        file.Assign(ed->GetFilename());
    }

    // Now activate the project this file belongs to
    ProjectFile* pf = ed->GetProjectFile();

I will fix this in a while. The remaining question is, why the pointer is null?

EDIT: Fixed in r13445

[Grit Clef]

Oh, no! Today I built CB r13490 myself entirely, but when I ttied to run it, it crashed at startup! Luckily, I use the one in devel32. So the RPT file may include something useful.
P.S. I tried to delete all the conf files and restart CB, but it still crashed. This new RPT file is also attached.
P.S. 2 There must be some problems with KeyBinder, because when I delete it and start CB, nothing is wrong.

[Pecan]

I just built and tested rev 13490 (cb 32_64, Win 11) but could not reproduce the problem.

I have no way of testing win 7 (cb 32).

[Grit Clef]

Oh, I seemed to do something stupid when building CB. I had set a wrong compiler setting and linked a library that isn't needed, and that error was in that module. After I removed it, CB can start correctly.

[Pecan]

Oh, I seemed to do something stupid when building CB. I had set a wrong compiler setting and linked a library that isn't needed, and that error was in that module. After I removed it, CB can start correctly.

Thanks for reporting that. I'm relieved it's not a hidden error somewhere.
We all make these little mistakes. God knows I've made my share.

[Grit Clef]

Hi,
    This time I want to update my CB build from 13518 to 13525. When I was building CB's core, I suddenly found that CB crashed again when it started to build the target 'AStyle'. The RPT file with debug info is attached, hope it works for you devs!

[stahta01]

Grit Clef: What exactly is the compiler you are using? If my old Windows 7 64 bit laptop works still I will try to duplicate the problem.
I am guessing the Compiler might be the cause; so, I wish to test with the exact compiler build you are using.

Tim S.

[Grit Clef]

stahta01: GCC 13.2.0 from MSYS2, I'm using the mingw32 port. (I've found that MSYS2 has 32-bit versions once, but it's stopped supporting 32-bit systems since 2021.)
It's very kind of you to try building it! But it's not very easy to reproduce the problem, since it doesn't appear very often.

[nenin]

stahta01: GCC 13.2.0 from MSYS2,

I suggest to try i686 builds from WinLibs or niXman. Also you probably need to care about Mingw-w64 version. I have some fresh experience with WinXP, key issues was to find relatively fresh compiler with XP-compatible  Mingw-w64. The same story may be with Win7 32b. 

[Grit Clef]

I will try other mingw-w64 versions; I've used winlibs' and nixman's build of version 13 before, they also  have the similar problems and, even other problems like -pipe errors. Maybe I should change the compiler's version.

[nenin]

I will try other mingw-w64 versions; I've used winlibs' and nixman's build of version 13 before, they also  have the similar problems and, even other problems like -pipe errors. Maybe I should change the compiler's version.

I suggest to control Mingw-w64 version as well.  Mingw-w64 interact with OS, and may call inappropriate system functions. Typically gcc and Mingw-w64 are from the same generation, but at least at Winlibs sometimes older  Mingw-w64  may be coupled with more fresh gcc.

[Grit Clef]

Hmm... I'm now using GCC 10.5 + MinGW-w64 6.0.1, and I used that toolchain to rebuild CB. Also, I set that compiler as the default compiler for building programs, but CB still crashed today... The RPT file contains the same content as above.

There's another thing that is worth mentioning. When I opened a project, CB suddenly gave me a debugging check failure, shown as the attached picture.

[nenin]

I`m using this https://github.com/brechtsanders/winlibs_mingw/releases/tag/9.3.0-7.0.0-sjlj-r3 for some old PC under XP. It works.