tgoop.com/gdb_dbg/16
Last Update:
The Folder of God (часть 3, последняя)
Ну что же, и правда стоит пояснить, что произошло, следите за руками:
1) В shell32.dll есть такой замечательный метод IShellFolder::GetDisplayNameOf(...), он, как нетрудно догадаться из названия, возвращает имя папки или файла для показа в GUI. Так вот для нашей божественной папки именно в Windows 10 Creators Update этот метод стал себя вести странно: все еще возвращает S_OK, т.е. вызов вроде как успешен, но вот вместо строчки STRRET возвращает NULL.
2) в JDK, в части связанной с awt, есть нативный метод sun.awt.shell.Win32ShellFolder2.getDisplayNameOf который дергает IShellFolder::GetDisplayNameOf при использовании Windows LAF. И вот никто в этом методе не был готов к тому, что от системы вернется S_OK, но строчка при этом не вернется. Поэтому никто не проверял этот параметр STRRET, а значит очень быстро случалось разыменование NULL и развал. Этим и объясняются развалы на HotSpot-е, которые я нагуглил.
3) Так, а что у нас, это ведь другая виртуальная машина? Тут интересно: мы в JET реализовали полностью работающий JNI, а значит все нативы работают из коробки. Зачем же нам тогда писать свои реализации сишных нативов для работы с GUI? Вместо этого мы просто переиспользовали нативы из JDK (это не запрещено). Соответственно, проблему с getDisplayNameOf мы тоже унаследовали.
Так что не сказать, что мы прям были виноваты. Скорее почувствовали божественное вмешательство, по-другому это историю и не назовешь!
—
Все это я рассказал и клиенту, чтобы немного унять его переживания по поводу русских хакеров, он был в восторге) Проблему же починили в следующем минорном апдейте JDK, так что она автоматически починилась и у нас.
Вот такой получился эффект бабочки: маленькая правка и изменение поведения в коде виндовой библиотеки привела к нетривиальным развалам в абсолютно разных JVM. Так и живем, друзья! С божьей помощью.
#откопали_стюардессу
BY Алло, это отладочная?
Share with your friend now:
tgoop.com/gdb_dbg/16