GCCE compiler issue

[sergey_galat]

Hi everyone,

I've run into problem with GCCE compiler (the one coming with Symbian SDKs - csl-arm-2005Q1C).
My application was occasionally closing with KERN-EXEC 3 and I managed to get minimal code to reproduce:

#include <e32def.h>
#include <vector>

static void f1(bool, unsigned long)
{
    int* i = new int;
}

struct A
{
    virtual void f2(const void* p,
                    const std::vector<int>& v1,
                    const std::vector<int>& v2,
                    bool b,
                    unsigned long n) =0;
};

struct B
    : public A
{
    void f2(const void* p,
            const std::vector<int>& v1,
            const std::vector<int>& v2,
            bool b,
            unsigned long n)
    {
        std::vector<int> l = v1;
        f1(b, n);
    }
};

GLDEF_C TInt E32Main()
{
    std::vector<int> v;

    A* a = new B;
    a->f2(NULL, v, v, false, 1000);

    return 0;
}

It should be built against OpenC (\Epoc32\include\stdapis) with 5th Edition 1.0 SDK.

You can download the test package from here:

http://qarea.com/set/test_gcce.zip

It also includes code to reproduce with estlib+STLport (just uncomment an appropriate section in the MMP file).

Notes:

1. This only reproduces with -O2 optimization in release configuration
2. This doesn't reproduce with WINSCW or RVCT builds
3. I haven't tested with newer versions of GCCE since they are not officially supported by Nokia

Thanks for assistance,
Sergey.

[wizard_hu_]

The compiler is not flawless, so it may easily happen.

Have you attempted to check the actual control flow? Though adding printf/cout-s may 'ruin' the issue via affecting optimizations, it may worth a try.
STL on Symbian may use the Cleanup Stack, so it may also worth a try providing one.
Inline+virtual can lead to problems, avoiding this combination may be more peaceful.

[sergey_galat]

Thanks for the reply.

1. Yes I added a console and traced the flow. The app closes with KERN-EXEC during a call to a->f2() function.
2. Providing a cleanup stack didn't help.
3. Making the f2() function non-inline didn't help either.

Is there anyone who could confirm the bug or point me to an article describing the issue if it has been filed already? It seems critical as the code to repro is rather trivial and may appear in any project. This forced us to move to -O1 optimization for the whole Symbian development for now.

Thanks.

[wizard_hu_]

Even if you do not like the idea of using a non-supported version of the compiler, you can give it a try (http://wiki.forum.nokia.com/index.ph...h_Symbian_SDKs) - at least it will become clear if the given bug still exists. The compiler itself comes from CodeSourcery (http://www.codesourcery.com, you will also find the link in the Wiki article), so its bugs belong to them.
What you can blame on Symbian and partially on FN is the lack of official support for using more recent GCCE toolchains with the newer SDK-s (except Symbian^3, which is still bundled with GCCE 3.4.3, but comes with some support package for 4.4.1)

[tamhanna]

Hi,
have you already tried to report the bug to Nokja?

[sergey_galat]

Hi,
have you already tried to report the bug to Nokja?

I used to report other GCCE problems on this forum in the past and official Nokia people appeared here and took them. How do I report a bug to Nokia otherwise?

[petrib]

I used to report other GCCE problems on this forum in the past and official Nokia people appeared here and took them. How do I report a bug to Nokia otherwise?

https://www.forum.nokia.com/Contact_and_feedback/