QGriddlayout works for grid 80*80 but not for 100*100 or more (SIGSEGV error)

Davay

Sorry in advance I am very new to QT and c++. I am trying to make a grid filled with colored clickable labels. And the whole program works perfectly for grids the size smaller than 80*80 but for bigger gridds I get a SIGSEGV segmentation fault error in the debugger, it doesn't exactly tell my why. This is the code where the error most likely originates:

void Gridd::ShowStart(QWidget *wid){

    QGridLayout *layout = new QGridLayout;

    for (unsigned int r = 0; r < rows; r++) { 
        for (unsigned int c = 0; c < cols; c++) {

            ClickableLabel  *label = new ClickableLabel(r,c); 
            QString str = " background-color : " ;

            if ((*this)(r,c).getState() == "fireless"){ 

                str += (*this)(r,c).getMaterial().getColor();
            }
            else {
                int bt = (*this)(r,c).getBurningTime();
                QColor col (250-20*bt,(80+bt * 160)/(1+bt*bt),0);
            }
            label->setStyleSheet(str);
            layout->addWidget(label, r, c);
            str="";

            (*this)(r,c).setLabel(label);

        }
    }
    layout->setHorizontalSpacing(0);
    layout->setVerticalSpacing(0);
  
    wid->setLayout(layout);
    wid->show();
}

I think it originates from here because it does not want to show my start grid here. Thanks in advace!

Christian Ehrlicher

@Davay said in QGriddlayout works for grid 80*80 but not for 100*100 or more (SIGSEGV error):

int bt = (*this)(r,c).getBurningTime();

wtf?
What is 'this' dervied from. This looks very strange.

Also when it crashes - use a debugger to see where it crashes and fix it.

Davay

@Christian-Ehrlicher said in QGriddlayout works for grid 80*80 but not for 100*100 or more (SIGSEGV error):

ied from. This looks very strange.
Also when it crashes - use a debug

I'm sorry it looks so strange but I'll try to answer this is a matrix (a std vector of a std vector of a class section and the section on that row and column gets given back by (*this)(r,c), I overloaded the () operator) which has an attribute named burning time.)

I want to use the debugger but it does not give me more info on exactly where it crashes, It seeminly crashes on this function in my main:

void delay(int secs)
{
    QTime dieTime= QTime::currentTime().addSecs(secs);
    while (QTime::currentTime() < dieTime)
        QCoreApplication::processEvents(QEventLoop::AllEvents, 100);
}

But if I leave it out it crashes as well so I know for sure it isn't this.

Christian Ehrlicher

This function should be removed and the logic be fixed. Don't do this. If you want a 500ms timer then use QTimer but don't call the eventloop this way. It will just lead to problems.

Davay

@Christian-Ehrlicher said in QGriddlayout works for grid 80*80 but not for 100*100 or more (SIGSEGV error):

This function should be removed and the logic be fixed. Don't do this. If you want a 500ms timer then use QTimer but don't call the eventloop this way. It will just lead to problems.

Thanks a lot for your answer! Can you elaborate why it would lead to problems and why to problems only occur for big enough grids?

Christian Ehrlicher

@Davay said in QGriddlayout works for grid 80*80 but not for 100*100 or more (SIGSEGV error):

Can you elaborate why it would lead to problems

You call the eventloop but it's not run in the 'outer' loop. So basically you have

outer main eventloop -> your program logic -> inner event loop

but this can lead to problems, especially when your program logic was called as a result of a queued signal/slot connection. When you then call the eventloop inside this slot, the signal may be evaluated again since it's not yet finished. Also the order of the signals can be mixed up due to this and other stuff which is very hard to debug. Therefore avoid it, especially when you try to delay something. Qt is event driven and you should not do such things.

and why to problems only occur for big enough grids?

timing or others, no idea but what you're doing is not recommended.

nagesh

@Davay confirm that as you increase the grid from 80x80 to 100x100, the following index access from the matrix is valid?

(*this)(r,c).getState()
(*this)(r,c).getMaterial()
(*this)(r,c).getBurningTime()

My guess is that matrix is being initialized to 80x80

Davay

@nagesh Thank you for your comment, all of them seem to be initialized. I also checked for hard coding errors several times but don't seem to find any of that sort sadly.

Davay

@Christian-Ehrlicher Thank you for the elaboration! I've followed your advice and it did help me with some laggy issues of my program but sadly not with the grid. I've changed my delay function in:

QTimer ts;
ts.start(200);
QEventLoop loop;
QObject::connect(&ts, SIGNAL(timeout()), &loop, SLOT(quit()));
loop.exec();

JonB

@Davay said in QGriddlayout works for grid 80*80 but not for 100*100 or more (SIGSEGV error):

I get a SIGSEGV segmentation fault error in the debugger, it doesn't exactly tell my why.

I don't see anywhere you have looked at/shown the stack trace for this?

Davay

@JonB Thank you for your reply, I hope this picture helps but I wasn't really sure what you've asked for (since I'm really unfamiliar with qt (and c++). The first picture is just before I get the Sigsev error and this second one is just after:

JonB

@Davay
It probably won't help, but you would need to go back further in the stack trace (bottom window) till you reach somewhere in your own code.

SimonSchroeder

The debug output looks like you have infinite recursion. With every function call you allocate more stack space. Eventually you will run out of stack space (as it is quite limited compared to the heap) which will in turn result in a segmentation fault.

Like @JonB already said, you need to provide more of the stack trace until you reach your own code. Click on <More> in the stack trace until you see something familiar. You should also figure out if Qt uses more than 1 Thread. If I am not mistaken GUI stuff runs in Thread #0 and not #1 like you show it. (I might be mistaken about this, though.) Sometimes switching the thread will show your own code in the stack trace.

Davay

@JonB & @SimonSchroeder Thanks a lot for your answers let me start of with the threads, I'll only show those where something new shows up:

Now if I click on more in thread 1 (see the previous reply) it doesn't do anything now if I click on it a couple of times, QT crashes without error or any warning.

@SimonSchroeder do you mean with this limited amount of stack space that I can't make more of my clickable labels than lets say than a grid filled with them more than (80 on 80) so about 6400?

Pl45m4

@Davay

It probably wont help to solve your problem, but why do you need 10.000 labels or more in a QGridLayout at the same time? Maybe there is a workaround or better/different solution for your use case.
-> QGraphicsView+ QGraphicsItems instead of labels in a grid.

Davay

Well, you are probably right that I don't need them but for a beginner like me it seemed a logical choice to use labels or buttons since those are things I know. I'm trying to make a forest fire simulation and each tile can be made of a different material that can be changed throughout the simulation. Hence they need to be clickable. I would be open to any suggestions on how to do this better of course!

SGaist

Hi,

As suggested by @Pl45m4 the Graphics View Framework. You'll be able to build your simulation in an easier way to manage your various tiles on the map.

JoeCFD

@Davay Is it possible to create a single image for display of your simulation? You can change the colors of its pixels. Your simulation data is generated behind the scene. One tile consists of a matrix of pixels.

Pl45m4

@Davay

So your "map" looks like raster graphics with a low resolution where each label in some color represents a tile of a different material?
Yes, you can do this with the GraphicsView framework.
Of course they can be clickable. But there is so much more you can do, when you use the GraphicsView framework (zooming, custom items etc).
It probably takes some time to re-design your interface but 6.400 or over 10k labels on a widget is by far not the best solution :)

Davay

Thank all of you for your good suggestions, I'll look into them!