VLC blocked when opening a non-existent file and quitting

[KO Myung-Hun]

Hi/2.

As subject, VLC is blocked if failing to open a file.

The blocked codes are signaling parts.

    QVLCApp::triggerQuit();

and

The QVLCApp class is

class QVLCApp : public QApplication
{
    Q_OBJECT

public:
    QVLCApp( int & argc, char ** argv ) : QApplication( argc, argv, true )
    {
        connect( this, SIGNAL(quitSignal()), this, SLOT(quit()) );
    }

    static void triggerQuit()
    {
         QVLCApp *app = qobject_cast<QVLCApp*>( instance() );
         if ( app )
             emit app->quitSignal();
    }

#if defined (Q_WS_X11)
     QVLCApp( Display *dp, int & argc, char ** argv )
         : QApplication( dp, argc, argv )
     {
        connect( this, SIGNAL(quitSignal()), this, SLOT(quit()) );
     }
#endif

#if defined(Q_WS_WIN)
protected:
    virtual bool winEventFilter( MSG *msg, long *result )
    {
        switch( msg->message )
        {
            case 0x0319: /* WM_APPCOMMAND 0x0319 */
                DefWindowProc( msg->hwnd, msg->message,
                               msg->wParam, msg->lParam );
                break;
        }
        return false;
    }
#endif


signals:
    void quitSignal();

};

[Dmitry A. Kuminov]

My guess is that signals are just a coincidence and the real problem is in the termination code that gets executed when the application terminates (as a result of the quit() invocation). Moreover, I performed the quick test of the code above and it works here.

Anyway, the code you posted looks odd to me: I don't understand why they can't just call QApplication::quit() directly.

So please provide more details. The simplest is to start it from the debugger and break in when it hangs (to get the stack trace, as usual).

[KO Myung-Hun]

Replying to dmik:

My guess is that signals are just a coincidence and the real problem is in the termination code that gets executed when the application terminates (as a result of the quit() invocation). Moreover, I performed the quick test of the code above and it works here.

I agree because when playing a normal file, the blocking does not occur. Nevertheless I don't understand what is executed by quit(). In addition, why is a signal blocked only on OS/2 ?

Anyway, the code you posted looks odd to me: I don't understand why they can't just call QApplication::quit() directly.

It was my first try, in my case QVLCApp::quit(). But it causes SYS3175 in other place, or another blocking.

Unless using Qt4 interface, I could not encounter this problem at all.

So I'm guessing this is related to Qt4, but I cannot point out exactly what the problem is.

So please provide more details. The simplest is to start it from the debugger and break in when it hangs (to get the stack trace, as usual).

Do you mean Qt4 codes or VLC ones ?

Anyway it's hard to get the call stack because VLC is compiled in a.out although I've not tested with gdb, yet.

[Dmitry A. Kuminov]

SYS3175 is wrong too. Why do you use a.out? Please build it in -Zomf mode (and better with the debug info) and then we will be able to debug this and also use procdump to get the stack trace at the crash time if the debugger doesn't help (locks up or something). Otherwise there is nothing I can do about this problem.

[KO Myung-Hun]

VLC uses an autotools build system. And it generates a reloaded-object which emxomf does not understand.

But I've found the reason why libtool generates a reloaded-object, and now I'm using -Zomf. Oh, thanks to pdksh and klibc supporting a very long command line.

Now, what should I do ?

At a glance using a debugger, I have no chance to see the different situation from the before.

The only difference is now I can dive into the disassembly of DOSCALL1.

[Dmitry A. Kuminov]

Can you please check this with the 4.6.2 release?

[KO Myung-Hun]

Ok, I've checked it.

There is a following warning, but it works as expected.

WARNING: QApplication was not created in the main() thread.

What was the problem ?

[Dmitry A. Kuminov]

Ah yes, that was the problem I think. At least in Qt3 (and I suppose in earlier Qt4 versions) creating QApplication on a non-main (non-GUI) thread was surely not expected. Looks like they fixed it in 4.6.x (or maybe simply made the consequences less harmful -- I can't find any explicit statement regarding this). I guess this defect may be closed since it works now as you expect.