# Buffer Overflow Debug **URL:** \ **Category:** GNU Radio\ **Created:** [May 15, 2015, 12:27am UTC](https://www.ruby-forum.com/t/buffer-overflow-debug/241951 "2015-05-15T00:27:36Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\ **Post date:** [May 15, 2015, 12:27am UTC](https://www.ruby-forum.com/t/buffer-overflow-debug/241951/1 "2015-05-15T00:27:36Z")
Hi all, I’m working on an incredibly annoying issue related to my use of the Header/Payload Demux (HPD) block. I think it’s related to a buffer overflow at some point, but I’m having a really hard time coming up with a proper debug strategy to nail this down. What I’m seeing is my data streams freeze after the input to the HPD block, both on the header branch and the payload branch. Everything before the HPD block continues on without issue. The time it takes the streams to freeze is HIGHLY variable. I’ve watched it run for 30 minutes straight before a freeze and I’ve watched it freeze a few seconds after start. I’m using tags generated by the Correlation Estimator as the trigger for the HPD block. My question is this, if I suspect a buffer overflow is causing a freeze, how would I prove this to myself? v/r, Rich ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [May 15, 2015, 1:06am UTC](https://www.ruby-forum.com/t/buffer-overflow-debug/241951/2 "2015-05-15T01:06:45Z")
On 14.05.2015 15:26, Richard B. wrote: > streams to freeze is HIGHLY variable. I’ve watched it run for 30 minutes > straight before a freeze and I’ve watched it freeze a few seconds after > start. I’m using tags generated by the Correlation Estimator as the > trigger for the HPD block. > > My question is this, if I suspect a buffer overflow is causing a freeze, > how would I prove this to myself? Rich, a “buffer overflow” wouldn’t cause GR to freeze, rather, it would crash. Going by your previous messages, I suspect what you’re seeing is that the HPD is starting to block, causing backpressure until that in turn reaches the source. (Correct me if I’m wrong). I remember you previously mentioning something similar. Did you confirm the header parser is actually sending out a message for every data packet it receives? This is a case where the HPD is actually designed in a way that it’ll fail. As a debugging strategy, I would recommend printing out the state changes inside the HPD state machine. If it freezes, it would be interesting to see in which state that is. Cheers, Martin ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [May 20, 2015, 8:03pm UTC](https://www.ruby-forum.com/t/buffer-overflow-debug/241951/3 "2015-05-20T20:03:42Z")
Hi Martin, Sorry for the delay in response. We have been able to put some time into debugging this issue and here is what we’ve found: 1. We have confirmed that the input stream to the HPD block is correctly tagged when the block freezes. The tags we set as “trigger tag” in the block are on the input stream. 2. At some point in the flowgraph operation, the HPD block gets stuck in the STATE\_FIND\_TRIGGER state (idle state). This is even though the trigger tags are present on the input, as confirmed in 1 above. We are observing that get\_tags\_in\_range is failing to find the tags in the stream. We can’t figure out what would cause this, or that this is even the issue. It’s the best idea we have. So we agree there is no buffering issue. The issue is with the HPD block not seeing tags that are confirmed to enter the input port. We would love some help on this issue. The way we are debugging, is we copy and pasted the built in HPD block source to our own custom gr\_modtool module and added cout debug statements there. v/r, Rich On Thu, May 14, 2015 at 4:05 PM, Martin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [May 21, 2015, 3:28am UTC](https://www.ruby-forum.com/t/buffer-overflow-debug/241951/4 "2015-05-21T03:28:16Z")
Yes I will file a bug. We put a tag\_debug block right before the HPD input. The tag debug stdout statements continue, while the get\_tags\_in\_range function of the HPD block returns none. We will continue debugging this to see if we can learn something more concrete. The time it takes the flow graph to generate this error is very variable. From hours to seconds. If there is other useful debug info you’d like us to generate please let me know and we will. V/r, Rich ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [May 21, 2015, 3:06am UTC](https://www.ruby-forum.com/t/buffer-overflow-debug/241951/5 "2015-05-21T03:06:39Z")
This is interesting, and kinda serious. Also, we’ve had reports that tags go missing in the past, but it’s something that’s hard to verify. How did you confirm the input stream is correctly tagged? If get\_tags\_in\_range isn’t finding tags that it should, that is most likely the issue you’re seeing here. Can you please file a bug report on the issue tracker, with as much detail as you can provide? On a side note, you might be able to use the trigger input instead of the tags, but that doesn’t solve this problem. Thanks, Martin ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [May 27, 2015, 2:46pm UTC](https://www.ruby-forum.com/t/buffer-overflow-debug/241951/6 "2015-05-27T14:46:18Z")
Hey Richard, I’m going to need some time, peace and quiet to get to the bottom of this. Which means not in the very near future 🙂 But I’m very interested in getting this to work. Can you post some failing codes/OOTs somewhere for me to start testing? M ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [May 22, 2015, 9:23pm UTC](https://www.ruby-forum.com/t/buffer-overflow-debug/241951/7 "2015-05-22T21:23:16Z")
Martin et. al., I implemented my own block that produces a trigger signal when a specific tag is encountered, and I feed this into the detect port of the HPD block. This is an attempt to overcome the tag trigger issues we’ve been having in this email chain. The trigger\_tag block simply outputs zeros until a specified tag\_key is found, at which point it outputs a 1 on that sample and then continues outputting zeros. It has the same trigger behavior as the Schmidt Cox block used to create the detect signal in the OFDM example. This has resolved the HPD block freezing issue, however, a new issue has arisen. Now the block will output the correct header and payload for a little while, and then randomly start passing the wrong header portion through, even though the detect signal is still on the correct trigger point at the input to the HPD block. I confirmed this by comparing the HPD port0 input with the HPD port1 input, confirming the detect peeks correspond exactly with the port0 tags that signify a header start. Even while the HPD block allows the wrong header portion through, the detect signal is aligned perfectly with the header start at input0. If you wouldn’t mind confirming my HPD block settings, I will detail them here. I don’t think this could be the issue, because I expect the block would never work correctly if they were off, but better to be safe. The input0 type is complex unpacked data. My header is 32 bits long packed. I correspondingly set the following: _Header Length (Symbols): 4Items per Symbol: 8_ _Guard Interval (items): 0_ _Output Format: Items_ _IO Type: Complex_ _Sampling Rate:_ Now, to add on to this confusing block, I tried using the following settings and it worked better than the above settings. However, looking at the source code, it makes no sense to me why it should work at all. This is because the payload size is calculated by using the packet\_length read off the message passed in multiplied by the items\_per\_symbol variable. This would correspond to a huge payload (128_32 in my case, instead of 128_8), yet it works. _Header Length (Symbols): 1Items per Symbol: 32_ Using the other possible combination that produces the correct header length when multiplied together, it does not work for any length of time. _Header Length (Symbols): 2Items per Symbol: 16_ I’m starting to think there is a major bug in the HPD block when used without the ‘Output Format Symbols’ mode. I say this because this is the last difference between the OFDM example, which seems to work fine, and my own. At this point I’m stuck code diving into the HPD block to see if I can figure out what’s going on. v/r, Rich On Wed, May 20, 2015 at 6:27 PM, Richard B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [May 27, 2015, 6:03pm UTC](https://www.ruby-forum.com/t/buffer-overflow-debug/241951/8 "2015-05-27T18:03:18Z")
Martin, I’ll update you on this in a new thread soon. We had been running into the age old problem of plugging one hole and having two more leaks spring up. We are finally onto something that seems to be fixing everything. It’s a simple code change in HPD. Rich Sent from my iPhone