GenerateFrameTabularText skips some data


I’m developing simple plugin to process captured IR transmission, source code available at GitHub - aleaksah/logic-ir: Saleae Logic plugin for IR-transmitter data analyzing

It kinda works, and report valid if I save it as file or if I view it as bubbles, as well as it correct in Data Table. But when I select terminal view - I can see that some data missing. That’s weird, because GenerateFrameTabularText, GenerateExportFile and GenerateBubbleText using same code snippet.
I tried to add minus symbol at the end of every text reported by AddTabularText, like this: AddTabularText(number_str, "-"), and after that I can see that data like -1--0 (part of data missing) appears in terminal, while Data Table view have nothing like that.

Why some data can disappear from Terminal view?

Sample capture for testing: sample-ir-capture.sal (41.9 KB)

@aleaksah Sorry to hear about this! I didn’t take a deep dive into your source code, however, one of the more common reasons for terminal text to seemingly disappear is described in the support article below, under the section titled “Terminal Text Seems to be Missing”, located at the very bottom.

Can you double check if that situation might apply in your case? If so, a workaround might be to use the “Carriage Return to Line Feed Converter” extension, which is available from our Extensions Marketplace.

Thanks for tour reply, but this is not my case. I have disappeared graphic symbols in terminal.

This bug can be triggered even simplier, by following code in tabular text generator:

static unsigned long long int n = 0;

void LogicIRAnalyzerResults::GenerateFrameTabularText(U64 frame_index, DisplayBase display_base)
    char number_str[128] = { 0 };
    snprintf(number_str, sizeof(number_str), "%llu-", n++);

Code above shot generate strict sequence from 1 to n in terminal window, like “1-2-3-” etc. But I got next result:

@aleaksah Thanks for the added details. It’s interesting to see that the disappearing entries are separated by a loose multiple of around 26.

I forgot to ask earlier — what version of the software are you running?

We actually recently fixed a major bug with our terminal in v2.4.9 described in the changelog below:

Fixed bug where if you shrink the analyzer terminal, and then expand it again, some contents would be deleted.

The bug above would delete terminal entries at a fixed interval, which seems to be the case for the behavior you described.

I am running Logic 2.4.9, but I saw same behavior at Logic 2.4.8

@aleaksah Ah that’s unfortunate… sorry to hear both of my hunches weren’t correct. We’ll get this on our backlog to review some more and we’ll follow up with our findings once we do so.

Sorry for the trouble with this. The terminal is a special case, we added it recently, long after the Analyzer API was created. We didn’t add a new API for the terminal, instead we gave it some simple default behavior for most low level analyzers (LLAs) and customized it specifically for a few of our more common built-in LLAs, like I2C and SPI.

Specifically, for the terminal, we just call the GenerateFrameTabularText once per frame with the display base set to ASCII.

However, we also call GenerateFrameTabularText for other reasons too, not just the terminal. Your code is incrementing n every time GenerateFrameTabularText is called, but when we call it to generate data for the data table, those results won’t be shown in the terminal.

A better test would be to print the parameter frame_index. The terminal should call GenerateFrameTabularText once for every frame you have generated, sequentially. Let me know if you still observe the same issue.

I just did a local test through about 200 terminal messages, but I didn’t see any missing data.

Sorry, my previous proof wasn’t valid.
I still facing this issue, and I found a way to reproduce it even with analyzers shipped with Logic (I am using 2.4.9):

  1. Open Logic, no analyzer attached
  2. Select “Try a demo device”, then “Logic pro 8”
  3. Add one analyzer, Async serial with default settings.
  4. Start demo for about 4-5 seconds and stop it
  5. Switch to terminal view, Ctrl+A and Ctrl+C to copy all data. Paste in in some text editor that able to comapre different texts or use a website like
  6. Save this capture to disk
  7. Choose File->Close tab
  8. Choose “Open a capture” and select capture we saved in previous step
  9. DO NOT OPEN TERMINAL VIEW YET! Rresize right panel. Make it thinner, could be as thin as possible.
  10. Open terminal view
  11. Repeat step 5 to compare new data with previous data
  12. Data should be different, usually it messed up at the end of capture.

This bug sort of random, but it needs some size of data (no bug when you have small capture) and it depends on terminal width when you open it first time per session. If terminal wide at maximum usually you have no bug.


@aleaksah Thanks for the added details, and sorry to hear you are still facing this issue. Our software team is unfortunately swamped at the moment, however, I’ve added this to our backlog to review. We’ll need some time to dig into this, as we were unable to reproduce the issue here the first time we tried it.

We’ll follow up with our updates here once we’ve had a chance to investigate this further.

1 Like

Look like data messing up only in last line of terminal view. More characters you have in last line - more chances to this bug to show up.

@aleaksah Thanks for the added info. We haven’t had a chance to review this further yet, but we’ll keep you updated on our findings.

Sorry for our long delay on this!

We thought that bug was fixed in 2.4.8. Specifically, In logic 2.4.7 and older versions, shrinking the sidebar would cause the last line of the terminal output to get truncated. You can see the fix mentioned in the 2.4.8 changelog here: Saleae - Changelog

Thanks for the video you posted. After several attempts, I was able to reproduce the problem. The most important step to reproduce the problem appears to be to shrink the sidebar horizontally when the terminal is not visible, then open the terminal. On top of that, I think it may be required that the terminal is not displayed when the data is generated.
Unfortunately this is likely the same underlying problem that we though we fixed in 2.4.8.

The root problem is a “bug” in the terminal UI library we’re using, which will truncate the last line of text when reduced in size horizontally IF the last line of text does not end with a newline. This is because the terminal library (xterm.js) treats the last line separately from all other lines, as delimited by newline characters.

I had implemented a workaround, but it does not seem to cover this case.
I’ve just spent a bit more time on it, but it looks non-trivial, so I will need to put this into the backlog for now.

1 Like