2016-07-04 4 views
1

J'ai eu quelques plantages dans mon application sur le terrain un crash que j'ai reçu est très intéressant dans la nature. Pour l'un des accidents se produit le service que j'utilise signale un SIGSEGV SEGV_MAPERR en libwebviewchromium.so et la seule information qui revient est l'adresse 0x00000000fbadbeef. Il semble assez ironique que non seulement l'adresse est lisible, mais aussi si cohérente.SIGSEGV SEGV_MAPERR 0x00000000fbadbeef dans libwebviewchromium.so

Je ne parviens pas à créer le plantage localement, donc je n'ai pas de trace complète, mais j'étais curieux de savoir s'il y avait un problème ou une raison pour l'adresse 0xfbadbeef dans libwebviewchromium et s'il y a un correctif ou façon de le réduire de se produire.

+0

Une adresse lisible comme cela ne se produit pas accidentellement. Cela signifie qu'ils ont volontairement écrit cette valeur. C'est une technique de débogage old school pour les erreurs de mémoire dans C et d'autres langages basés sur des pointeurs. Si vous voyez cela, cela signifie que vous avez soit dépassé les limites d'un tableau, soit accédé à un pointeur déjà libéré, soit un bug similaire. Ce qu'il est n'est pas débogable sans plus d'informations. Bien que vous puissiez rechercher le code de libwebviewchromium pour FBADBEEF pour voir pourquoi ils attribuent cette valeur particulière (vous utilisez des valeurs différentes pour les différents problèmes que vous recherchez). –

Répondre

1

De la Chromium WebKit sources - voir le commentaire juste au-dessus de la définition de la macro -, c'est leur code pour "les erreurs connues et irrécupérables comme la mémoire insuffisante".