#124 Windows port now cause memory leakage

cai singbo

Version QP/C 5.06.01
In the function QFEPOOLINIT(), a memory is dynamicly allocated. But it has no chance to free it. Because the pointer "fudgedQSto" is a local variable.
According to the note for this situation, this is for avoiding the massive message generated by windows. So I think this mermory should be allocated by user. The designers of Windows application should noted this problem and allocated more mermory.*

#define QF_EPOOL_INIT_(p_, poolSto_, poolSize_, evtSize_) do { \
    uint_fast32_t fudgedSize = (poolSize_) * QF_WIN32_FUDGE_FACTOR; \
    void *fudgedSto = malloc(fudgedSize); \
    Q_ASSERT_ID(210, fudgedSto != (void *)0); \
    (void)(poolSto_); \
    QMPool_init(&(p_), fudgedSto, fudgedSize, evtSize_); \
} while (0)

Also in the function of QActive_start_

fudgedQLen = qLen * QF_WIN32_FUDGE_FACTOR; /* fudge the queue length */
fudgedQSto = calloc(fudgedQLen, sizeof(QEvt *)); /* new queue storage */

This memory is freed by when the thread exit.

free((void *)act->eQueue.ring); /* free the fudged queue storage */

  • Although this memory is freed when the thread exit. however, if the thread was failed to create or any other reason , the memory also have no chance to free.

In all, this memory should be operated by user, and it's better using static memory than dynamic allocating.


  • cai singbo

    cai singbo - 2016-01-25
    • Description has changed:


    --- old
    +++ new
    @@ -7,7 +7,7 @@
             void *fudgedSto = malloc(fudgedSize); \
             Q_ASSERT_ID(210, fudgedSto != (void *)0); \
             (void)(poolSto_); \
    -        QMPool_init(&(p_), poolSto_, poolSize_, evtSize_); \
    +        QMPool_init(&(p_), fudgedSto, fudgedSize, evtSize_); \
         } while (0)
     Also in the function of QActive_start_
  • Quantum Leaps

    Quantum Leaps - 2016-02-03
    • status: open --> accepted
  • Quantum Leaps

    Quantum Leaps - 2016-02-03

    The QP port to Win32 used to work exactly as proposed in this bug report, that is, the port did not allocate any memory dynamically. Instead, as all embedded QP ports, the Win32 port requried all event-queue buffers and memory-pool buffers to be allocated by the application (statically, or dynamically) and passed on to the framework.

    The problem with this was that developers have tried to use on Windows the same (small) sizes of queues and pools designed for deeply embedded targets. In other words, the developers have re-used the same main() function on embedded targets and on Windows.

    However, this caused the Windows runs to occasionally run out of space in the queues/pools and assert. This occurred, because Windows is NOT a real-time system. But the developers didn not care, and instead they filed bug reports for QP. In other words, the developers perceived the QP as defective, because of the non-deterministic nature of Windows.

    To avoid these sort of problems, the QP ports to Windows (as well as POSIX) have been modified to oversize the queue and pool buffers. This was done under the assumption that Windows is primarily used as a platform for prototyping and testing embedded applications.

    However, Windows can also be considered a final target for QP applications that are only intended to run on Windows and not on any embedded system. In this situation, the "fudging" of the buffers sizes is inappropriate.

    In summary, the this bug report is in essence about the misunderstanding of the intent of using the QP ports to Windows.

    Last edit: Quantum Leaps 2016-02-03
  • cai singbo

    cai singbo - 2016-02-04

    The main bug is the "fudging" in QF_EPOOL_INIT_() ,

    void *fudgedSto = malloc(fudgedSize);

    this buffer isn't freed after allocated.

    the "fudging" of the buffers is right in QActive_start_()

    • Quantum Leaps

      Quantum Leaps - 2016-02-04

      That's right that the event pool buffers aren't freed, but the only place this could happen is upon the application exit. (The event pools are supposed to live througuhout the application life-cycle). At this point, the while memory space occupied by the application is reclaimed by the Windows OS anyway.

      This is in contrast to event-queue buffers, becasue they live only as long as an active object, so they are freed in QActive_stop().

      So, my point is that it makes no real difference whether on not pool-buffers are freed.

      Please comment.

      Last edit: Quantum Leaps 2016-02-04
  • Quantum Leaps

    Quantum Leaps - 2017-02-07
    • status: accepted --> closed
  • Quantum Leaps

    Quantum Leaps - 2017-02-07

    This bug was fixed in QP/C/C++ 5.8.0 by removing the "fudging" of event queues and event pools. This removes the dynamic memory allocation from the Win32 ports (win32 and win32-qv), so there is no possibilty of leaking memory in the QP.



Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks