Linux GRID SDK 2.2 is not compatible with new drivers (352)

Hello everyone!

I see that export function list is changed for libnvidia-fbc.so.1 since 352 driver series.
Also new drivers cause memory corruption right after app call any nvfbc funtion. I assume that structure definitions are changed too.(nvfbc except longer struct size)

nvidia, could you release new grid sdk with correct library headers?

thank you, Alex.

I don’t think that I’m only one have this issue. Does anyone else have this issue too?

I have idea, may be I am using wrong source?

What is best source to download recent GRID SDK?
I see it available only on https://developer.nvidia.com/grid-app-game-streaming

I have the same issue too.
I think we should get the old version of the driver.

The GRID SDK released a year ago,we need new SDK .

https://developer.nvidia.com/grid-app-game-streaming

This is the correct source for the GRID SDK

Are you guys running any grid sdk sample application with which you are observing this issue? Can I get reproduction steps so we can debug the issue?

we are taking this issue under 200223330

We have not observed this issue. Can you provide details about his repro steps. Maybe something else was wrong with your setup.

Hello, this issue is reproducible using h264 capture example from linux grid sdk2.1

some stack variables are modified by nvidia .so file.

To avoid this issue I allocate some bytes before and after any structure passed to nvidia api.

template <typename T>
class SafeStack
{
public:
  SafeStack()
  {
    memset(before, 0x55, sizeof(before));
    memset(after, 0x66, sizeof(after));
    memset(&object, 0, sizeof(object));
  }

  ~SafeStack()
  {
    bool corrupt = false;
    for(int i = 0; i < sizeof(before) / sizeof(int64_t); ++i)
      if(before[i] != 0x5555555555555555)
        corrupt = true;

    for(int i = 0; i < sizeof(after) / sizeof(int64_t); ++i)
      if(after[i] != 0x6666666666666666)
        corrupt = true;

    if (corrupt)
      LOG(ERROR) << "nvidia api issue, corruption: ", typeid(object).name();
  }

  int64_t before[16];
  T object;
  int64_t after[16];
};

I didn’t check recent capture SDK examples yet

Please test with recent capture SDK examples. If repro , please share step-by-step repro steps so we can reproduce this issue.

I think this issue got fixed with 370.28 driver. Please test and share feedback.

yes this issue is fixed for me, thank you. (new sdk provided all headers I need)