TypeError: 'type' object does not support item assignment

[dannosaur]

Summary of problem

  File "ddtrace/internal/periodic.py", line 56, in run
    self._target()
  File "ddtrace/profiling/collector/__init__.py", line 42, in periodic
    for events in self.collect():
  File "ddtrace/profiling/collector/stack.pyx", line 511, in ddtrace.profiling.collector.stack.StackCollector.collect
  File "ddtrace/profiling/collector/stack.pyx", line 351, in ddtrace.profiling.collector.stack.stack_collect
  File "ddtrace/profiling/collector/_traceback.pyx", line 54, in ddtrace.profiling.collector._traceback.pyframe_to_frames
  File "ddtrace/profiling/collector/_traceback.pyx", line 92, in ddtrace.profiling.collector._traceback.pyframe_to_frames
  File "ddtrace/profiling/collector/_traceback.pyx", line 20, in ddtrace.profiling.collector._traceback._extract_class_name

Which version of dd-trace-py are you using?

2.4.1

Which version of pip are you using?

23.3.1

Which libraries and their versions are you using?

See #8132

How can we reproduce your problem?

No idea

What is the result that you get?

Error

What is the result that you expected?

No error :)

[emmettbutler]

Thanks @dannosaur. Is it possible that there's more to the traceback?

[dannosaur]

Unfortunately not, this is the same situation as the other issue I posted whereby the stack trace was copy/pasted from our Sentry instance and this is all that it gave me.

[dannosaur]

I should add that I'm willing to run test builds with extra log output if necessary to help try and get to the bottom of what's happening. There's a non-zero chance our app is doing something stupid, but I have no way to figure out what might be triggering it.

[P403n1x87]

@dannosaur Thanks for reporting this. As suspected, the handling of the SystemError exception has brought to light a different exception on the same line 🙁 . We suspect this is due to a potentially corrupt frame object being passed around. Line 20 in _traceback.pyx is not an item assignment statement, so I suspect the exception might be thrown from some internals. I have drafted #8223, if you could be so kind again to give it a try 🙏 . In the meantime, we are working on a more robust way of stack sampling that should allow us to avoid these kind of issues entirely.

[dannosaur]

I've just updated our project to use your branch for #8223. If you merge it in and you rebase your fork let me know so I can update our requirements file since the commit hash will change.

I'll keep you posted.

[dannosaur]

Bit of an update on this. We didn't have a release cycle this week, so this hasn't gone as far as I'd hoped yet. That said, it's been running on our dev platform since I last posted and there's been no ddtrace errors whatsoever since. Granted it's our production environment that has all the edge cases.

It'll go out to production on Tuesday 2/13 and I'll have a more definitive result for you.

[P403n1x87]

@dannosaur thanks for the update 🙏

[dannosaur]

@P403n1x87 so your branch has been in production for a couple days now. I cleared out the Sentry errors for ddtrace when it was deployed so I'd have a clearer picture. This particular error hasn't been seen since, however #8218 persists.

We've also seen a new error, only once (over probabiy hundreds of millions of requests), so I'll post that one as a new issue. It's possible that this new error is being uncovered as a result of the work you've done on your branch.

[P403n1x87]

@dannosaur many thanks for the feedback thus far 🙏 . I'll get the proposed change merged then, so that it can be delivered via the next patch release. Meanwhile I'll have a look at the other issues and see what we can do about them.

[github-actions[bot]]

This issue has been automatically closed after a period of inactivity. If it's a feature request, it has been added to the maintainers' internal backlog and will be included in an upcoming round of feature prioritization. Please comment or reopen if you think this issue was closed in error.