Crash in ICUNumericData::Initialize()

[kaliber]

If haiku is build with clang, it crashes at ​http://dev.haiku-os.org/browser/haiku/trunk/src/system/libroot/add-ons/icu/ICUNumericData.cpp#L29

vm_page_fault: vm_soft_fault returned error 'Permission denied' on fault at 0x6133a4, ip 0x1834352, write 1, user 1, thread 0x50
vm_page_fault: thread "mount_server" (80) in team "mount_server" (80) tried to write address 0x6133a4, ip 0x1834352 ("libroot-addon-icu.so_seg0ro" +0x9352)
debug_server: Thread 80 entered the debugger: Segment violation
stack trace, current PC 0x1834352  _ZN8BPrivate14ICUNumericData10InitializeEPNS_23LocaleNumericDataBridgeE + 0x12:
  (0x7ffee838)  0x1832167  _ZN8BPrivate16ICULocaleBackend10InitializeEPNS_16LocaleDataBridgeE + 0x67
  (0x7ffee858)  0x577ec0  _ZN8BPrivate13LocaleBackend11LoadBackendEv + 0x40
  (0x7ffee868)  0x5ef568  tzset + 0x18
  (0x7ffee980)  0x172bb68  uprv_tzset_44 + 0x18
  (0x7ffee990)  0x1561d0c  _ZN6icu_448TimeZone11initDefaultEv + 0x3c
  (0x7ffee9f0)  0x1561f75  _ZN6icu_448TimeZone13createDefaultEv + 0x65
  (0x7ffeea10)  0x4a2e9b  _ZN9BTimeZone5SetToEPKcPK9BLanguage + 0x4b
  (0x7ffeea90)  0x4a2ded  _ZN9BTimeZoneC2EPKcPK9BLanguage + 0x7d
  (0x7ffeeac0)  0x4a0a6c  _ZN8BPrivate10RosterDataC2Ev + 0x7c
  (0x7ffeeae8)  0x4a2d12  _GLOBAL__I_a + 0x12
  (0x7ffeeb00)  0x4a4c97  __do_global_ctors_aux + 0x27 (closest symbol)
  (0x7ffeeb10)  0x4979d5  (/boot/system/lib/liblocale.so + 0x15)
  (0x7ffeeb1c)  0x100878  _Z17init_dependenciesP7image_tb + 0x48
  (0x7ffeeb44)  0x100b35  load_program + 0x295
  (0x7ffeefb4)  0x1057ef  runtime_loader + 0xff

Shouldn't it be dataBridge instead of *dataBridge?

[zooey]

Replying to kaliber: [ ... ]

Shouldn't it be dataBridge instead of *dataBridge?

No, since it's actually *dataBridge->addrOfGlibcDecimalPoint, so the code is trying to set a char* pointer by dereferencing a char.

The problem seems to be that the code relies on global objects being initialized in a specific order and that clang picks a different order. In this specific case, the constructor of LocaleNumericDataBridge relies on glibc's _nl_C_LC_NUMERIC to be set up already. I'm trying to find a way around that ...

[zooey]

Replying to zooey: [ ... ]

The problem seems to be that the code relies on global objects being initialized in a specific order and that clang picks a different order. In this specific case, the constructor of LocaleNumericDataBridge relies on glibc's _nl_C_LC_NUMERIC to be set up already. I'm trying to find a way around that ...

Nope, _nl_C_LC_NUMERIC is not dynamically initialized, so it *must* be filled before any dynamic initialization is done. So something's wrong with the clang port, I suppose.

[kaliber]

I did some research, my conclusions:

1. In ICUNumericData::Initialize() *dataBridge->addrOfGlibcDecimalPoint has correct value (".")

2. Writing to the *dataBridge->addrOfGlibcDecimalPoint is not permitted, additionally in the syslog there is "write access attempted on write-protected area 0x657 at 0x00613000", it's possible clang bug.

[zooey]

Replying to kaliber:

I did some research, my conclusions:

1. In ICUNumericData::Initialize() *dataBridge->addrOfGlibcDecimalPoint has correct value (".")

As it should have.

2. Writing to the *dataBridge->addrOfGlibcDecimalPoint is not permitted, additionally in the syslog there is "write access attempted on write-protected area 0x657 at 0x00613000", it's possible clang bug.

Err, no, actually it is a bug in my code, since the struct that is being written to is marked as constant, so the compiler is free to put it into a write-protected section (which apparently gcc doesn't). Fixing ...

[zooey]

I tried to fix the problem in hrev38623, please try again with that and shout if the problem persists.

[kaliber]

It works, thank you!

[zooey]

Ah, nice! Thanks for the swift response.