#122 QP-Win32 port didn't initialed with some internal variable

[cai singbo]

After exit QF , if we want to enter this frame again, There are three variables that uninitialized which lead to wrong behavier. However, in the QK version , there are such initialization.
QF_maxPool_ = (uint_fast8_t)0;
QF_bzero(&QF_timeEvtHead_[0], (uint_fast16_t)sizeof(QF_timeEvtHead_));
QF_bzero(&QF_active_[0], (uint_fast16_t)sizeof(QF_active_));

[Quantum Leaps]

Which QP/C version was used? Was it the QV ("Vanilla") kernel?

Starting from QP/C 5.4.0 (released on 2015-04-26), the qv.c file defiens the QF_init() function as follows:

void QF_init(void) {
    extern uint_fast8_t QF_maxPool_;
    extern QTimeEvt QF_timeEvtHead_[QF_MAX_TICK_RATE];

    /* clear the internal QF variables, so that the framework can start

    * correctly even if the startup code fails to clear the uninitialized
    * data (as is required by the C Standard).
    */
    QF_maxPool_ = (uint_fast8_t)0;
    QF_bzero(&QV_readySet_,       (uint_fast16_t)sizeof(QV_readySet_));
    QF_bzero(&QF_timeEvtHead_[0], (uint_fast16_t)sizeof(QF_timeEvtHead_));
    QF_bzero(&QF_active_[0],      (uint_fast16_t)sizeof(QF_active_));
}

As you can see, the QV initialization contains all the variables listed in the bug description.

Please verify which QP/C version you are using. Please post to this discussion so that the bug could be closed if this is just a problem with an older QP/C version.

--MMS

[Anonymous]

Version QP/C 5.6.1, released on 01/01/2016

in the folder qpc\ports\win32\qf_port.c
I am using this port, only InitializeCriticalSection was called.

/ QF functions ============================================================/
void QF_init(void) {
InitializeCriticalSection(&l_win32CritSect);
}

[Quantum Leaps]

This "bug" has been accepted and will be "fixed" in the next QP/C and QP/C++ releases.

However, the issue reported here arises only because the QP application is apparently re-started without going through the startup sequence. This must be the case, because Windows startup code complies with the C/C++ Standard in that it cleans the .bss section (uninitialized variables).

The original QP port to Windows was designed under the assumption that the application will be stared from Windows, in which case the .bss section will be cleared and clearing it again in QF_init() is a waste of time.

But, to avoid any such "bug" reports in the future, the QF_init() will be implemented as follows:

void QF_init(void) {
    extern uint_fast8_t QF_maxPool_;
    extern QTimeEvt QF_timeEvtHead_[QF_MAX_TICK_RATE];

    InitializeCriticalSection(&l_win32CritSect);

    /* clear the internal QF variables, so that the framework can (re)start

    * correctly even if the startup code is not called to clear the
    * uninitialized data (as is required by the C Standard).
    */
    QF_maxPool_ = (uint_fast8_t)0;
    QF_bzero(&QF_timeEvtHead_[0], (uint_fast16_t)sizeof(QF_timeEvtHead_));
    QF_bzero(&QF_active_[0],      (uint_fast16_t)sizeof(QF_active_));
}

Please NOTE, however, that (re)starting of your Windows application without going through the standard startup code will clear only the internal QP variables, but will not clear any of your own application-level variables. It now becomes your responsibility to make sure that all such variables are cleared correctly.

--MMS

[cai singbo]

Thanks for your fast response! Yes, your explaination is exactly correct. In my case, the windows application will not quit after the QF part exit . And generally, the QF part will start again. So with this uninitialized variable, the QF part behaves wrong.

Another suggestion is the QF part have these global variables which lead to the functions of QF part are not reentrantable. So one application with two or more QF part is impossible. Do you have any plan to make it support such feature?

[Quantum Leaps]

The QP port to Windows is specifically designed to allow one instance of QP per process. There are no plans to extend this model for more than one instance of QP per process.

If you whish to use more QP instances, you can do it by launching more Windows processes (applications). The communication (event exchanges) between different processes, however, goes beyond the scope of QP. Such communication must be implemented on top of QP (as sockets, pipes, or other such mechanisms.)

--MMS

[Quantum Leaps]

This issue has been fixed in QP/C 5.6.2. The function QF_init() in the Win32 and Win32-QV ports explicity clears all internal framework variables.