Planned maintenance has been done but it did not solve the problem. So work will continue on this and a new time for trying updates will be announced asap.

Issue with threading and opencv



  • @jsulm : Thanks for highlighting the possibility of signal/slots.
    I will have to redesign my approach for implementing the same.
    Just couple of question:
    -> If i queue signal and slot will it affect my overall program.
    ie. Suppose i queue the signal/slots related to this program will it affect the other signal/slots
    written in my program . For ex: delay in execution of the signal/slots of the main program.
    -> How to make a mutex wait for the previous lock if we are not sure how much time it is going to take.


  • Qt Champions 2018

    @Kira said in Issue with threading and opecv:

    Suppose i queue the signal/slots related to this program will it affect the other signal/slots
    written in my program . For ex: delay in execution of the signal/slots of the main program.

    Queued signals do not block anything - they are just in a queue. The only delay you will have is the slot when it is actually called - but that you will have anyway as you have to execute the code anyway, right?

    "How to make a mutex wait for the previous lock if we are not sure how much time it is going to take" - I don't understand this question. A mutex either blocks the thread which wants to lock if the mutex is already locked, or you can continue immediately. So, you already have this "waiting" if the mutex is already locked.



  • @jsulm
    Queued signals do not block anything - they are just in a queue. The only delay you will have is the slot when it is actually called - but that you will have anyway as you have to execute the code anyway, right? : Yes

    Thanks for the help cleared a lot of implementation doubts.
    Just a small question. If i have a thread which acquires the lock and there is one more thread which requests for the locked resource. How will i tell the other thread wait until and unless the lock in the thread have not been unlocked.
    We can currently use the wait time but is there any way to tell when create a notification when the lock is released and tell the other thread to wait for that specific time.

    And one more thing how to highlight specific lines which we are answering. Which you have did for my earlier questions. :)


  • Qt Champions 2018

    @Kira said in Issue with threading and opecv:

    How will i tell the other thread wait until

    That's exactly what a mutex is doing: it blocks the thread which tries to lock a mutex which is already locked by other thread, as soon as the other thread releases the mutex the OS will wake up one of the blocked (waiting) threads. So, you do not have to tell the thread anything.



  • @jsulm : Hello i have implemented the save image function in a slot as suggested by you.
    But the problem is that the image is not being saved. I would like to share the given code:

    signals:
    void signalSaveImage(cv::Mat,String row,String column);
    slots:
    public slots:
    void saveImage(Mat finalImage,String row, String column);
    Slot Definition:

    void MainWindow::saveImage(Mat finalImage, String row, String column)
    {
        cout<<"Inside image save function"<<endl;
        cout<<"Row"<<row<<endl;
        cout<<"Column"<<column<<endl;
        String imagePath = "D:/testN/"
        String imageFormat = ".bmp";
        try {
               cv::imwrite(imagePath+row+"_"+column+imageFormat,finalImage);
           }
           catch (cv::Exception& ex) {
               fprintf(stderr, "Exception in saving image: %s\n", ex.what());
           }
           fprintf(stdout, "Saved PNG file with alpha data.\n");
    
        cout<<"\n Entering inside save mutex"<<endl;
    
        cout<<"\n Completed image save function"<<endl;
    
    
    }
    

    Signal to slot connection:
    connect(this,SIGNAL(signalSaveImage(cv::Mat,String,String)),this,SLOT(saveImage(Mat,String,String)),Qt::QueuedConnection);

    MainWindow.cpp
    Emitting signal to save image:
    emit signalSaveImage(image,to_string(row),to_string(column));

    But my problem is that my images are not being saved.


  • Moderators

    @Kira said in Issue with threading and opencv:

    QueuedConnection

    forces a copy of the arguments, The MetaSystem doesn't know the type cv::Mat -> can't be transmitted via QueuedConnection.

    Check your console output you should have warning of unknown metatyps (declare and/or register)



  • @J.Hilk : I have registered it.
    #include "mainwindow.h"
    #include <QApplication>

    int main(int argc, char *argv[])
    {
    qRegisterMetaType< cv::Mat >("cv::Mat");
    QApplication a(argc, argv);
    MainWindow w;
    w.show();

    return a.exec();
    

    }


  • Moderators

    @Kira

    the data goes most likely out of scope, as the copy constructor of cv::Mat does actually no coping

    0_1560409629873_2c331f8b-46e4-4408-8567-abe5ac4169e3-image.png

    I had the same issues in my time with opencv.

    ended up converting it to a Image before transferring it from the opencv thread to the normal one.



  • @J.Hilk : Just for clarification should i replace this part with cv::clone
    void saveImage(Mat finalImage,String row, String column);



  • @J-Hilk : will try and also i tried to run the program in debug mode and getting the following error.
    0_1560418863054_65dbf469-08ad-429c-bed7-3a5997fe0246-image.png

    Debugger redirects to following line of file of ostream:
    // MANIPULATORS
    template<class _Elem,
    class _Traits> inline
    basic_ostream<_Elem, _Traits>&
    __CLRCALL_OR_CDECL endl(basic_ostream<_Elem, _Traits>& _Ostr)
    { // insert newline and flush stream
    _Ostr.put(_Ostr.widen('\n'));
    _Ostr.flush();
    return (_Ostr);
    }

    0_1560419407453_ee0e3e1d-16a4-4a24-8b13-2cf3c1db7c66-image.png

    And the program quits.
    Can u please explain what may be the relevant reason for error


  • Qt Champions 2018

    @Kira Please post the stack trace after crash



  • @jsulm : I thought this is the stack trace after crash


  • Qt Champions 2018

    @Kira said in Issue with threading and opencv:

    this is the stack trace after crash

    no, it isn't



  • @jsulm : This is the only thing which i see after crash with exception triggered.
    Is there any other way to do so


  • Qt Champions 2018

    @Kira In QtCreator if you start with debugger you will have a stack trace



  • @jsulm : Are you referring to this:
    0_1560428382736_ecc1a67e-9ef8-4aad-ab64-76c3ed8f112e-image.png
    Please let me know in case of any issues


  • Qt Champions 2018

    @Kira Yes. Now you need to go from top to bottom until you hit first source code file from your project and check it at the line mentioned in the stack trace.



  • @jsulm : I tried doing it but the error is expected to come after thread running >150 times which is making the debugging process very difficult.
    I have also sample test case on github can you please go through it for any possible issues.
    https://github.com/HackersSpirit/ImageProcessor


  • Moderators

    @Kira said in Issue with threading and opencv:

    150 times

    you can tell a breakpoint to be ignored for a certain amount of time

    0_1560506679424_0eaace31-88f0-4376-8417-f745494c6433-image.png


  • Qt Champions 2018

    @Kira I actually suggested to go through the stack trace after crash from top to bottom. No break points needed for that.



  • @jsulm :
    @Kira said in Issue with threading and opencv:

    @jsulm : Are you referring to this:
    0_1560428382736_ecc1a67e-9ef8-4aad-ab64-76c3ed8f112e-image.png
    Please let me know in case of any issues

    This is the stack trace which i get posted earlier referring from line no 1. It does not point to line of code where program has a break.
    But line 16 and 17 point to the line of the code.
    Should i refer those line for particular cause of the program to break
    Please do let me know if i getting something wrong


  • Qt Champions 2018

    @Kira Check your code in that source code at line 16 and 17.



  • @jsulm :
    Line 16 is pointing to following line in bold:
    void ImageMapping::requestReWorkNew()
    {
    cout<<"Inside requestRework Newwwwwwwwww"<<endl;
    const int sleep = 50;
    int queueSize = queueImageName.size();
    cout<<"Queue size Request Rework New: "<<queueSize<<endl;
    if(queueImageName.size()!=0){
    //Get the current image number from the list of images
    mutex.lock();
    _working = true;
    _abort = false;
    mutex.unlock();
    cout<<"Emiting resume work"<<endl;
    emit resumeWork();
    }else{
    cout<<"Signalling retrying"<<endl;

        emit retrying();
    }
    

    }

    This function is basically a slot triggered by following signal:
    connect(imageMapping, SIGNAL(finished()), imageMapping, SLOT(requestReWorkNew()));
    connect(imageMapping, SIGNAL(retrying()),imageMapping,SLOT(requestReWorkNew()));


  • Qt Champions 2018

    @Kira Are you sure this is the line? The actual line is mentioned in the "Line" column in the stack trace. So, it would be 2129.


  • Moderators

    @Kira you can double click on the line (in QtCreator) of the stack trace and it will open the file at the correct line



  • @jsulm : Actually i have recreated the issue.the program i am referring now is from github. I have cross checked the line which I highlighted is the same. If u want i can repost the image



  • @J-Hilk @jsulm : guys have you gone through the code at github do you see any issue with the threading logic? :)



  • @J-Hilk @jsulm : Hello guys sorry for the late update i was working on the issue.
    Would like to share the update.
    I trimmed down the issue further by first commenting out all the cout statements as the logs which
    was coming pointed to the ostream file of the cout.
    So the call stack pointed out to the opencv file stating unable to save the image.
    So i commented the save function to find any thing else was causing the issue. What i found that my program was still breaking and the call stack pointed to the thread function.
    I placed a counter for the signal and slot of the thread and it was found that it executed 666 times approx before breaking.



  • @J-Hilk
    @jsulm :Guys thanks for your support i finally figured where exactly the problem was:
    There was issue with the logic which was used for implementation. As you can see the code on github.
    Instead of requesting the task in the dowork function every time a signal is raised and an slot is called to execute the task.
    This led to the calling of so many signals and slots within a given time that it caused the stack to overflow.
    The issue will be resolved by removing the signal slot loop. This issue was top priority, a big learning curve for my future implementations in dealing with signal and slot mechanism.

    Thanks for your support.
    Just one last question which i would like to be answered which triggered with this implementation.

    1. Is there any limitation of how much slots can reside at a given time on a stack?
      As per my observation at a given time 666 approx signal/slots calls were made after which the program crashed.
    2. Is the slot entry is cleared or maintained on the stack after the execution and can be increase the size of stack or transfer it to heap?

    Regards


  • Qt Champions 2018

    @Kira 1. Sure but I guess it depends on many factors. You should not rely on it and avoid flooding the signal queue
    2. Not sure I understand the question. Which slot entry do you mean? Slots are not put into the signal queue. And the stack is automatically cleared when a function/method (which a slot is) finishes, nothing Qt specific.



  • @jsulm

    @jsulm said in Issue with threading and opencv:

    @Kira 1. Sure but I guess it depends on many factors. You should not rely on it and avoid flooding the signal queue
    2. Not sure I understand the question. Which slot entry do you mean? Slots are not put into the signal queue. And the stack is automatically cleared when a function/method (which a slot is) finishes, nothing Qt specific.

    1. Sorry if not understood i will just try to clear :). Actually i my assumption due to the implementation logic there were so many signals generated that caused the stacks to overflow giving error at different points.
      For example sometime i got error at saveImage function. while sometimes at calling the slot etc.
      I still need to clarify my assumptions using different test cases but probably this should be the cause why the program crashed.

  • Moderators

    @Kira said in Issue with threading and opencv:

    1. Sorry if not understood i will just try to clear :). Actually i my assumption due to the implementation logic there were so many signals generated that caused the stacks to overflow giving error at different points.
      For example sometime i got error at saveImage function. while sometimes at calling the slot etc.
      I still need to clarify my assumptions using different test cases but probably this should be the cause why the program crashed.

    Hi, great that you managed to work it out thumbsUp

    Sadly I'm quite a but under time pressure and was unable to take a closer look on your uploaded project :(

    To your question.
    The (default)stack limit is highly OS depended but In most cases, the max stack size of the main thread is significantly large, that you won't run into issues, even in highly recursive functions.
    IIRC, than on an ordinary desktop PCs, the call stack for Windows defaults to 1mb, 8mb for Linux, and 8-64mb for OSX

    For 2ndary threads, that can be quite different for macOS, that's reduced to 512 kbyte



  • @jsulm @J-Hilk :
    Thanks both of you in helping to figure it out.
    Actually this forum remains my first choice for any answers because of the quick response and supportive people.

    Thanks once again


Log in to reply