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 Select Expand


    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.