1

I've been getting some crashes in my app out in the field an one crash that I received is very interesting in nature. For one of the crashes happening the service I am using is reporting a SIGSEGV SEGV_MAPERR in libwebviewchromium.so and the only information coming back is the address 0x00000000fbadbeef. It seems kind of ironic that not only the address is readable, but it also so consistent.

I'm unable to create the crash locally so I don't have a full trace, but I was curious if there is a know issue or reason for the 0xfbadbeef address in libwebviewchromium and if ther is a fix for it or way to reduce it from happening.

Dom
  • 1,687
  • 6
  • 27
  • 37
  • A readable address like that doesn't happen on accident. It means that they purposely wrote that value. Its an old school debugging technique for memory errors in C and other pointer based languages. If you're seeing that, it means you've either walked past the bounds of an array, are accessing an already freed pointer, or similar bug. What it is is not debuggable without more info. Although you could search libwebviewchromium's code for FBADBEEF to see why they assign that particular value (you use different values for different problems you're looking for). – Gabe Sechan Jul 04 '16 at 19:42

1 Answers1

1

From the Chromium WebKit sources — see the comment just above the macro definition — , this is their code for "known, unrecoverable errors like out-of-memory".

JBL
  • 12,588
  • 4
  • 53
  • 84