Apps crash in ICU when using guard pages in the heap

[axeld]

When you start any application linking against libbe.so this way:

$ MALLOC_DEBUG=g LD_PRELOAD=/system/lib/libroot_debug.so <my-app>

you'll see the following crash ('g' enables guard pages in the debug heap):

KERN: stack trace, current PC 0x1b7c166  addElement__Q26icu_447UVectorPvR10UErrorCode + 0x36:
KERN:   (0x7ffed540)  0x1a0b441  put__Q26icu_4411TextTrieMapRCQ26icu_4413UnicodeStringPvRQ26icu_4413ZSFStringPoolR10UErrorCode + 0xbd
KERN:   (0x7ffed580)  0x1a0dcb3  __Q26icu_4416ZoneStringFormatRCQ26icu_446LocaleR10UErrorCode + 0x1593
KERN:   (0x7ffee0d0)  0x1a1383b  get__Q26icu_448ZSFCacheRCQ26icu_446LocaleR10UErrorCode + 0xd7
KERN:   (0x7ffee130)  0x1a101a9  getZoneStringFormat__Q26icu_4416ZoneStringFormatRCQ26icu_446LocaleR10UErrorCode + 0xc1
KERN:   (0x7ffee180)  0x1926f63  initZoneStringFormat__Q26icu_4417DateFormatSymbols + 0x10b
KERN:   (0x7ffee1c0)  0x1926e3c  getZoneStringFormat__CQ26icu_4417DateFormatSymbols + 0x3c
KERN:   (0x7ffee1f0)  0x191aa2a  subFormat__CQ26icu_4416SimpleDateFormatRQ26icu_4413UnicodeStringUsiRQ26icu_4420FieldPositionHandlerRQ26icu_448CalendarR10UErrorCode + 0xb6e
KERN:   (0x7ffee280)  0x1917e43  _format__CQ26icu_4416SimpleDateFormatRQ26icu_448CalendarRQ26icu_4413UnicodeStringRQ26icu_4420FieldPositionHandlerR10UErrorCode + 0x31f
KERN:   (0x7ffee2e0)  0x1917a11  format__CQ26icu_4416SimpleDateFormatRQ26icu_448CalendarRQ26icu_4413UnicodeStringRQ26icu_4413FieldPosition + 0x45
KERN:   (0x7ffee340)  0x191458f  format__CQ26icu_4410DateFormatdRQ26icu_4413UnicodeStringRQ26icu_4413FieldPosition + 0x63
KERN:   (0x7ffee370)  0x191466d  format__CQ26icu_4410DateFormatdRQ26icu_4413UnicodeString + 0x59
KERN:   (0x7ffee3c0)  0x1953ae4  getDisplayName__CQ26icu_448TimeZoneScQ36icu_448TimeZone12EDisplayTypeRCQ26icu_446LocaleRQ26icu_4413UnicodeString + 0x364
KERN:   (0x7ffeea40)  0x1cd7af2  TZSet__Q38BPrivate7Libroot17ICUTimeConversionPCcT1 + 0x2c6
KERN:   (0x7ffeeaf0)  0x1cd4eb5  TZSet__Q38BPrivate7Libroot16ICULocaleBackendPCcT1 + 0x39
KERN:   (0x7ffeeb20)  0x29ffc4  tzset + 0xac
KERN:   (0x7ffeec80)  0x1b73c80  uprv_tzset_44 + 0x18
KERN:   (0x7ffeeca0)  0x195223f  initDefault__Q26icu_448TimeZone + 0x43
KERN:   (0x7ffeed10)  0x195257a  createDefault__Q26icu_448TimeZone + 0x22
KERN:   (0x7ffeed30)  0x87d8fd  SetTo__9BTimeZonePCcPC9BLanguage + 0x75
KERN:   (0x7ffeed90)  0x87ce7c  __9BTimeZonePCcPC9BLanguage + 0x88
KERN:   (0x7ffeedc0)  0x879db1  __Q28BPrivate10RosterDataRC9BLanguageRC22BFormattingConventions + 0x71
KERN:   (0x7ffeedf0)  0x87ccb5  __static_initialization_and_destruction_0 + 0x5d
KERN:   (0x7ffeeeb0)  0x87cdbe  _GLOBAL_.I.__Q28BPrivate16CatalogAddOnInfoRC7BStringT1Uc + 0x22
KERN:   (0x7ffeeee0)  0x88001c  __do_global_ctors_aux + 0x28 (closest symbol)
KERN:   (0x7ffeef00)  0x867d85  (/boot/system/lib/liblocale.so + 0x15)
KERN:   (0x7ffeef0c)  0x100910  init_dependencies__FP7image_tb + 0x7c
KERN:   (0x7ffeef4c)  0x100d3c  load_program + 0xc8
KERN:   (0x7ffeefac)  0x10602a  runtime_loader + 0x11e

I haven't looked into the issue, so it might just be a bug in the debug heap, too.

[zooey]

Replying to axeld:

When you start any application linking against libbe.so this way:

$ MALLOC_DEBUG=g LD_PRELOAD=/system/lib/libroot_debug.so <my-app>

you'll see the following crash ('g' enables guard pages in the debug heap):

[ ... ]

I haven't looked into the issue, so it might just be a bug in the debug heap, too.

No, I think this looks somewhat familiar: I remember a problem with ICU's initialization invoking tzset() and our own implementation of tzset() in turn invoking ICU functions. So it might very well be the case that the malloc debugger traps access to an uninitialized pointer or similar.

I'll try to look into it tomorrow.

[zooey]

hrev40529 improves the initialization of the locale roster data, but that just circumvents the problem, as the crash still occurs, but now somewhere else (just after the next realloc()). Staring at the debug heap implementation, it's obvious that realloc doesn't deal properly with guard page, so that's why it fails.

I'll poke around some more to see if I can come up with a solution ...

[axeld]

Replying to zooey:

I'll poke around some more to see if I can come up with a solution ...

For the debug heap, I hope? :-)

[zooey]

Replying to axeld:

Replying to zooey:

I'll poke around some more to see if I can come up with a solution ...

For the debug heap, I hope? :-)

Yes :-) Should be fixed in hrev40533.

[axeld]

Great! I can now debug ShowImage using guard pages; unfortunately, this didn't bring any extra help - it still just randomly crashes.