I'm getting an assertion inside of QMPool_get at line 108 indicating that memory pool free block is corrupt. I have dumped the queue and noticed that a QSPY data string has been written to the buffer.
Line 108: Q_ASSERT_ID(130, QF_PTR_RANGE_(fb_next, me->start, me->end));
I'm noticing that the block has QSPY data written to it which obviously is not correct. The QSPY buffer is far away from my medium memory pool. The QSPY statement is provide below which looks normal:
The most common cause of event pool corruption and the range-check assertion is overwriting the internal pointers that link the free blocks together in the pool. This can happen when you write past the end of your event.
I would first scrutinize the code in search of incorrect event cast (down-cast) or anything that could cause writing past the end of the event.
Also, I would look for any violations of the event life-cycle constraints (Section 6.5.6 Event Ownership in PSiCC2, especially the attached Figure 6.14). For example, this life-cycle prohibits posting or publishing an event twice.
As far as the QSPY interference is concerned, it could be a red herring. At this point I'm not sure what you mean by "the block has QSPY data...". Which block? There are at least a few candidates, such as: fb, fb_next, me->start, me->end, etc.
The medium memory pool starts at 0xFE8 and the block length is 0x14. If you notice starting at address 0x10 QSPY data is written allover the memory pool.
If you suspect the QS tracing, then perhaps you should check the QS trace buffer and the QS pointers inside the QS_priv_ structure. You need to cross-check it with your initialization of the QS trace buffer. I would also check the disassembly of any QS access to make sure that it uses the correct critical section (the standard examples use the same critical section as the QF port).
--MMS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm getting an assertion inside of QMPool_get at line 108 indicating that memory pool free block is corrupt. I have dumped the queue and noticed that a QSPY data string has been written to the buffer.
Line 108: Q_ASSERT_ID(130, QF_PTR_RANGE_(fb_next, me->start, me->end));
I'm noticing that the block has QSPY data written to it which obviously is not correct. The QSPY buffer is far away from my medium memory pool. The QSPY statement is provide below which looks normal:
QS_BEGIN(LOG_I2C_ERR, me) QS_STR("+++ I2C ERROR SIG occurred +++"); QS_U8(2, me->mBus); QS_END()Medium Memory Pool start address is at 0xfe8, length 10 buffers, buffer size 0x14
QSPY Buffer starts at: 0x1b96
Can I get a suggestion on troubleshooting this problem? I am using the dsPIC33 uP?
The most common cause of event pool corruption and the range-check assertion is overwriting the internal pointers that link the free blocks together in the pool. This can happen when you write past the end of your event.
I would first scrutinize the code in search of incorrect event cast (down-cast) or anything that could cause writing past the end of the event.
Also, I would look for any violations of the event life-cycle constraints (Section 6.5.6 Event Ownership in PSiCC2, especially the attached Figure 6.14). For example, this life-cycle prohibits posting or publishing an event twice.
As far as the QSPY interference is concerned, it could be a red herring. At this point I'm not sure what you mean by "the block has QSPY data...". Which block? There are at least a few candidates, such as:
fb,fb_next,me->start,me->end, etc.--MMS
I've attached a picture of the memory pool dump.
The medium memory pool starts at 0xFE8 and the block length is 0x14. If you notice starting at address 0x10 QSPY data is written allover the memory pool.
If you suspect the QS tracing, then perhaps you should check the QS trace buffer and the QS pointers inside the
QS_priv_structure. You need to cross-check it with your initialization of the QS trace buffer. I would also check the disassembly of any QS access to make sure that it uses the correct critical section (the standard examples use the same critical section as the QF port).--MMS