Strange behaviour with QString class members

[Mesrine]

Hello everyone,

I am having strange behavior randomly when using QString as a class member.

For example
class.hpp

class AddressBox:public QObject
{
public:
    AddressBox(const QString hrp="rms",QObject *parent = nullptr);
  QString getAddressBech32()const{ 
qDebug()<<"hey:";
return m_bech32adddress; }
}
private:
const QString m_bech32adddress
}

class.cpp

#include"class.hpp"
AddressBox::AddressBox(
                       const QString hrp, QObject *parent):QObject(parent)
    m_bech32adddress("WHATISWRONG")
{
    qDebug()<<"hello1:"<<m_bech32adddress;
    qDebug()<<"hello2:"<<getAddressBech32();
};

The output on a code that creates an AddressBox object is

hello1: "WHATISWRONG"
hey:
Segmentation fault (core dumped)

And every time I use getAddressBech32() it returns a Bad allocation or a Segmentation fault.

I am initializing a const QString class member m_bech32adddress in the constructor of the class.
Printing the value in the constructor and this is ok.
But if call a function from the class it does not work.

This was not happening before, and maybe if you try to reproduce it it won't happen. Something related happened to me before in a singleton class and has to set some members static.

But there is some missing knowledge from my side of C++ on why this is happening.
I am using qt6.7.0 dev I think.

Any help will be appreciated.

[Mesrine]

@Mesrine
The solution is to define AddressBox::getAddressBech32() in the class.cpp file.

 QString AddressBox::getAddressBech32()const{ qDebug()<<"hey:";return m_bech32adddress; }

But I do not get the reason.

[J.Hilk]

@Mesrine said in Strange behaviour with QString class members:

But I do not get the reason.

possibly the missing ,

AddressBox::AddressBox(
const QString hrp, QObject *parent):QObject(parent)
, m_bech32adddress("WHATISWRONG")

[Mesrine]

@J-Hilk Now I do not get what you are trying to say :) .

I have declared a member function on the definition of the class that just returns the QString member.
The initialization of the const QString member is in the constructor.
Even if I do not initialize the QString member the function should return a default QString object.

[kkoehne]

@Mesrine I agree that the code by itself shouldn't crash (though the nested qDebug() is suspicious, I still think it's behavior should be well defined).

Anyhow, the code snippets you're showing is also not valid C++ (it misses at least a ';'). Try to create a minimal example that actually compiles. Also, do you get any stack traces?

Kai

[Mesrine]

@kkoehne
Thanks, the code was just to get an idea. If I create a minimum reproducible example it works ok :).

The runtime error was happening in a bigger project and it was fixed by passing the function definition from the headers to the sources.

I published it here although it can not be reproducible just in case I was missing something or someone experienced before.

[Mesrine]

@Mesrine

If i do instead

class.cpp

#include"class.hpp"
AddressBox::AddressBox(
                       const QString hrp, QObject *parent):QObject(parent)
    m_bech32adddress("WHATISWRONG")
{
  qDebug()<<"hello0:"<<m_bech32adddress.size();
    qDebug()<<"hello1:"<<getAddressBech32().size();
    qDebug()<<"hello2:"<<m_bech32adddress;
    qDebug()<<"hello3:"<<getAddressBech32();
};

the output is

hello0: 11
hello1: 94248499095840
hello2: "WHATISWRONG"
Segmentation fault (core dumped)

[J.Hilk]

@Mesrine said in Strange behaviour with QString class members:

AddressBox

since file and class name differ so much, do you have multiple classes in those files ?

[Mesrine]

@J-Hilk yes

[aha_1980]

@Mesrine said in Strange behaviour with QString class members:

Segmentation fault (core dumped)

Then run it in a debugger and inspect the stack trace (maybe post it here).

My feeling is, that you have some old object files that for some reason get linked but are incompatible to the rest of your code.

I'd clean all build artifacts and see if it reproduces after a clean build.

Regards.

[Axel Spoerl]

Couldn't resist compiling the reproducer against the latest dev, as well as 6.6 and 6.5.
Works and doesn't crash. So I guess @aha_1980 is right about binary artifacts causing the issue.
Moving the member function from header to implementation, probably caused no more than a re-compile.

[Mesrine]

@Axel-Spoerl

Yeah, but if I move it back it gives the runtime error :) .
I will try some stack trace and posted here.
Also, I will try changing the name of the function as suggested by the remaining binary artifacts idea.