[Solved] Segmentation Fault... What can be?
I getting an error at this line, and the file "qatomic_x86_64.h":
inline bool QBasicAtomicInt::ref()
unsigned char ret;
: "=m" (_q_value), "=qm" (ret)
: "m" (_q_value)
: "memory"); //HERE!
return ret != 0;
This error appears after this code:
But If in a controller class I remove this line:
getEixo()->getSensores().append( getSensorConfigurado() );
The error not appears...
It's something with concurrence? Lock on variable attribute? What can be?
Please run your application inside valgrind, it's likely that you have a corrupted heap.
getEixo() is probably returning a null or an invalid pointer.
I try to use valgrind, but I got this error:
** Error: "valgrind" could not be started: No such file or directory **
I will check if getEixo is null, but I don't beleave that's can be the reason of my problem...
The value of variable getEixo() is <unavailable synchronous data>, on debug mode!
I read some posts saying to use SIGNALS and SLOTS?
Why so solution?
class Eixo : public QObject
explicit Eixo(QObject *parent = 0);
void setId(int newId); void setNumeroEixo(int newNumeroEixo); void setConjunto(int newConjunto); void setMyTipoEixo(TipoEixo* newMyTipoEixo); void setSensores(QList<Sensor*> newSensores); void addSensor(Sensor* newSensor); int getId(); int getNumeroEixo(); int getConjunto(); TipoEixo* getMyTipoEixo(); QList<Sensor*> getSensores(); bool isDiferencial();
#endif // EIXO_H
If I change sensores to be a pointer, like this: QList<Sensor*>* sensores;
The problem can be fixed?
I will try change this rightnow...
[quote author="dcbasso" date="1348577357"]The value of variable getEixo() is <unavailable synchronous data>, on debug mode![/quote]
No debugger required. Stick a:
if (getEixo() == 0) qFatal("getEixo() is returning null");
or similar check immediately before the affected line.
Incidentally, that affected line is adding an element to an anonymous copy of the QList<> and will probably not do what you are expecting.
A debugger is not required, but way more useful for tracking issues like these.
But basically, this is your problem:
@getEixo()->getSensores().append( getSensorConfigurado() );@
Here, you do two dereferences. The first especially may be problematic. If there is any chance of getEixo() returning 0, then you need to check for that.
Eixo* eixo = getEixo();
Q_ASSERT(eixo); //don't do the actual get inside the assert! It will be compiled out for release builds!
eixo->getSensores().append( getSensorConfigurado() );
Note that even this does not get you out of the woods yet. You have to be sure that getEixo() always returns 0 or a valid pointer. If you have deleted the Eixo object earlier and the pointer is still returned here, you're in trouble that you can't catch like this.
One might add that you will always suffer from this problem when using multiple dereferencing. This is the reason it is usually forbidden by any coding guidelines.
I found the reason!
I fix the error:
I was trying to append a some object/pointer to my QList! I remove the append, and just change the object/pointer and my QList is "auto" updated!
I really don't undestand why the problem appears when we try to add same object/pointer to QList, but the error don't happened again!!!
If you don't understand, I really suggest you keep on it until you do. Otherwise, I almost guarantee you that you'll get bitten by the same issue again, only this time about an hour before your release deadline...
The way you talk about object/pointer gives me the feeling you don't quite understand pointers & objects yet. However, that knowledge really is needed in order to work effectively with C++ and Qt.
I just use the thermology "object/pointer" to suggest that I was working with pointer to change a object, as this:
Well, I search a lot about this error and I don't found any good explanation to the error. After I remove the ".append(Sensor*)" on object sensores, the problem was fix, and the "Sensor*" is changed anyway, because I use pointer to change the value os "Sensor" inside the QList!
I just make the mistake to try add again on the QList... I think...