• /
  • EnglishEspañolFrançais日本語한국어Português
  • Se connecterDémarrer

Cette traduction automatique est fournie pour votre commodité.

En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.

Créer un problème

|View as Markdown (English)

Débogage

  • Correction d'un plantage (SIGSEGV ou SIGBUS dans SessionAttributeManager::generateJSONObject) sur le thread de collecte, qui pouvait également corrompre le tas, et causer des plantages ailleurs. L'agent copiait ses attributs de session internes, tels que memUsageMb et lastInteraction, pendant une collecte sans détenir le verrou qui les protège, de sorte qu'il pouvait les lire pendant qu'un autre thread les mettait à jour. Ce problème était présent dans la version 7.7.8 et les versions antérieures.
  • Correction du blocage du thread principal, et de la fermeture des applications par le watchdog iOS (0x8BADF00D), une fois que le tampon d’événements était plein, et que l’application continuait à effectuer des requests réseau. L’agent maintenait un verrou pendant qu’il réécrivait sa copie sur disque des événements mis en mémoire tampon, et les threads enregistrant les événements, y compris le thread principal, attendaient ce verrou. Les événements rejetés d’un tampon plein n’étaient pas non plus supprimés de cette copie, elle augmentait donc de volume, et était entièrement réécrite pour chaque nouvel événement. Les écritures se produisent désormais sans maintenir le verrou, sont regroupées par lots, et les événements rejetés sont supprimés. Ce problème était présent dans la version 7.7.8, et les versions antérieures.
  • Correction d’événements qui n’étaient parfois pas signalés lorsqu’ils étaient enregistrés, par exemple par la fin d’une requête réseau, au même moment où l’agent collectait les événements mis en mémoire tampon pour une récolte. L’agent vidait la mémoire tampon une seconde fois après la sortie de son verrou, ce qui supprimait tout événement ajouté entre-temps avant qu’il ne soit envoyé. Ce problème était présent dans la version 7.7.8 et les précédentes.
  • Correction du problème où le propre travail JSON de l’agent était enregistré comme activité de l’application. NSJSONSerialization est instrumenté pour les traces d’interaction, et l’agent l’appelait directement pour chaque message de log, ainsi que pour les attributs de session, et les exceptions gérées. Cela ajoutait le travail interne de l’agent aux traces d’interaction, et, lorsque l’application générait beaucoup de logs, pouvait saturer le tracing. L’agent appelle désormais l’implémentation d’origine, non instrumentée. Ce problème était présent dans la version 7.7.8, et les versions antérieures.
  • Correction d'un problème où les règles de masquage de l'identifiant d'accessibilité de Session Replay définies dans les paramètres de l'application étaient ignorées sur iOS. New Relic envoie ces règles aux applications iOS avec l'identifiant accessibilityIdentifier, mais l'agent ne reconnaissait que tag, ce qui entraînait le rejet de toutes ces règles. Les deux valeurs sont désormais acceptées. Une règle mal formée est désormais ignorée avec un avertissement, au lieu de rejeter toutes les règles, ou de faire planter l'agent.
  • Correction d'éventuels plantages lors du masquage de Session Replay. Les listes de masquage pouvaient être mises à jour par une reconnexion, ou par addSessionReplayMaskedAccessibilityIdentifier: et les API associées, pendant qu’une trame était en cours de capture, sans maintenir le verrou que la capture utilise. Les règles de masquage personnalisées contenant des valeurs qui ne peuvent pas être enregistrées dans NSUserDefaults, telles que null, pouvaient également arrêter l’application lorsque l’agent enregistrait sa configuration. Les règles sont désormais nettoyées avant d’être stockées, et chaque mise à jour des listes de masquage est verrouillée.
  • Correction des navigations WKWebView signalées sans URL dans les applications compilées avec le SDK iOS 27. Avec ce SDK, WKWebView.URL peut toujours être nil lorsqu’une navigation commence. L’agent se rabat désormais sur l’URL de la request du cadre principal à partir de decidePolicyForNavigationAction.
  • Correction d’un plantage EXC_BAD_ACCESS possible lors de l’utilisation de addHTTPHeaderTrackingFor.
Droits d'auteur © 2026 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.