I think I've isolated the windows crash introduced by the new toolchain

[squinkylabs]

You may remember last year that four of my old plugins started crashing the module browser when the library switched to the new toolchain.

At the time I found that the crashes were from usage of std::stringstream, and from the inability to catch any exception. But I couldn't pin it down. So I removed all the offending code from my old plugins, and they have been fine.

Today I recreated this issue: it happens when the ui thead does one of these things, i.e. if my draw() call does them.

This does not happen when I make a local build - with a local build any valid c++ 11 seems to work just fine, regardless of thread.

Anyway, I could further isolate this. I would think I could even make a dedicated repo with just a "hello world" plug that would crash.

Anyone interested in pursuing this?

[squinkylabs]

Thanks for moving this issue to the right place. It just occured to me that I put it in wrong repo.

ATM I'm testing with a extemely minimal plug in my repo called "Test". It will crash if it only uses std::stringstream, which (unlike some of the other things I was doing) is a pretty reasonable thing for a draw function to do.

if it helps, this currently exists at 3c9b5dfd4dc51df48dba693ec05fd4f834d698e2

Below is the entire widget code. You can see most of the test is #if 0.

struct TestWidget : ModuleWidget {
    TestWidget(TestModule*);
    DECLARE_MANUAL("Blank Manual", "https://github.com/squinkylabs/SquinkyVCV/blob/main/docs/booty-shifter.md");

    Label* addLabel(const Vec& v, const char* str, const NVGcolor& color = SqHelper::COLOR_BLACK) {
        Label* label = new Label();
        label->box.pos = v;
        label->text = str;
        label->color = color;
        addChild(label);
        return label;
    }
    void draw(const DrawArgs& args) override {
        INFO("TestModule::draw 66");
        ModuleWidget::draw(args);
        std::stringstream str;
        static int counter = 0;
        str << "draw ";
        str << counter;
        INFO(str.str().c_str());
        INFO("TestModule::draw 73");
        ++counter;
    #if 0
        try {
            std::invalid_argument ex("i am an exception");
            throw(ex);
        } catch (std::exception& e) {
            INFO("caught: %s", e.what());
        }

        const size_t size = 100000;
        int testArray[size];
        static bool init = false;
        if (!init) {
            srand(1234);
            init = true;
        }
        for (size_t i=0; i<size; ++i) {
            testArray[i] = rand();
        }
        for (size_t i=0; i<size; ++i) {
            testArray[i] += rand();
        }
        int sum = 0;
        for (size_t i=0; i<size; ++i) {
            sum += testArray[i];
        }
        INFO("sum = %d", sum);
#endif
    }
};```

[squinkylabs]

Here's what gdb says:

Thread 1 received signal SIGSEGV, Segmentation fault.
0xffffffffab3b0000 in ?? ()
(gdb) bt
#0  0xffffffffab3b0000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) q
A debugging session is active.

[cschol]

This crash is only on the Windows platform with the tool chain build? Does it work with the MSYS2 build? What is the compiler version of the MSYS2 enviroment?

[squinkylabs]

Yes, all my various crashes are only in windows using a toolchain build. Have never ever had a mystery crash like these in an MSYS2 build.

I update my dev environment pretty often. My gcc is:

$ gcc --version
gcc.exe (Rev5, Built by MSYS2 project) 10.3.0

[squinkylabs]

I should say I have tried running the Linux version under address sanitizer and found nothing, also used gcc's "check stack corruption" feature and found nothing.

[cschol]

The tool chain cross-compiler for Windows is v9.3.0 of gcc.

It is because we are using the last released version of the crosstool-ng framework to set up the tool chain. That released version is from 2019 and therefore the compiler versions are older.

Question about the code above: does it crash when you remove the INFO() calls? Maybe would have to use the str value somehow to prevent it from being optimized out. Just wondering whether the debug calls are the problem here.

[squinkylabs]

No, the debugging stuff was just added to try to see what's going on. Usually in the past when I used stringstream it was to make strings for custom tooltips. I'll try to make a stand alone plugin that crashes. It could of course be some entirely unrelated init code in my plugin that is causing all these issues.

But I'll make sure next time I made a repro case it doesn't use any debugging macros. Oh, but now that I think about it, don't those stay in the release builds?