Yep, absolutely, there is much to read/fiddle with, and may not be portable. May or may not work for OP's particular case. Anyway, whether this or your core dump suggestion (OP should look up how his target Linux OS handles core dumps allowed or not), he has a few approaches to consider now....
It means even it reports thats its QtWidgets that crashes, its likely not that DLL
if a plain empty GUI project works. ( for exact same folder , same pc)
I would next add some openGL to the test project see if it still runs.
As it seems might be direclt related to Qt ( like wrong Qt dll loaded)
so it could be the openGL for clients gfx card.
Anyway, the bug is in line 61 in = &inFile; - you assign a variable created on a stack to variable in. In the next line, the inFile goes out of scope and is deleted. So when you try to access in later in the code, it segfaults.
Thanks !! . I know it's not Qt problem but that's why i posted it in C++ section
@dheerendra oh, I found where was the problem, and it wasn't actually related to context menus. I use my own BrowserApp class that inherits QApplication but I found out that I inherited it the wrong way (constructor signature was wrong) and that caused some segfaults, including the one described in my question. So now I fixed that and everything works fine.
It is not the iterator that is the problem. From your example:
for ( QList<QListWidgetItem*>::iterator iter = selectedItems().begin(); iter != selectedItems().end(); iter++ )
qDebug() << (*iter)->text();
The functions 'selectedItems().begin()' and 'selectedItems().end()' are the problem. Each time you call 'selectedItems()' a copy of QList<QListWidgetItem*> array is returned. Since you call it twice you have two different copies. The contents of the list may be the same but they are two different lists.
QString input_text(" some text for input ");
QString text = input_text.simplified().trimmed().mid(1);
In order to have the second line work a QString is constructed (and destroyed) for each step as a copy constructor. The QString member 'simplfied()' returns an unnamed instance of a new copy of QString after performing whatever 'simplfied()' does. The member 'trimmed()' is then called from this new QString creating another unnamed instance which finally calls member 'mid(1)'. The final variable 'text' is assigned from the last member function of the unnamed instance of QString. If the last member was '.toInt()' it would return an integer instead (which won't compile unless the assigned variable is changed to an integer (or acceptes an integer as a constructor)).
The output from the above example is "ome text for input" if you are curious.
The member function QListWidget::selectedItems(void) might looks something like this:
QList<QListWidgetItem*> QListWidget::selectedItems(void) const
list.push_back(<figure out what is selected>);
You end up calling this function twice and therefore you have two different lists as you would expect (returned values from the same function will each have a unique instance). Your loop starts on the beginning of the first list and ends on the last item of the second list. It is very likely they are not sitting next to each other in memory so after the first list is traversed you are running over unknown memory (which is where your segfault comes from).
You need to be careful about copy constructors (when they are created). For example, your 'for' loop uses the postfix operator 'iter++'. For simple variables (integers) this is not a problem but if you have a complex iterator calling the postfix version will be expensive at it creates a copy. A better form is to use the prefix operator '++iter' as no copy is created.
I know, I too hate when people propose an alternative instead of answering the actual question but please forgive me this time. QXlsxWriter is a Qt based library to read and write excel files and I did not have many problems with it so far
How are you deleting your objects? Are you using delete or deleteLater? Seems odd this is happening since any delete on an object will delete all it's children before itself. At least with Qt parenting. If object X isn't a true child of B then that would cause your issue.
I.e. if I have:
QLabel *label = new QLabel();
QLabel *child = new QLabel(label);
// label should delete child by before it fully deconstructs.
Also if you have real code or at the very least a backtrace I could help more.
Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.