Latest Bugs & Tasks
Fresh install of hrev50085 x86_64 -> pkgman full-sync 50094
Attempting to play any kind of audio or video file in MediaPlayer causes a crash
If ffmpeg command is invoked from the terminal there is a crash
Degug reports attached
Probably fixed in 1.5.2.
Haven't seen this one happen in a while, I think it's fixed now.
haiku_loader has some support for MultiBootInfo data passed from GRUB when loaded as a kernel (ie. not chainloaded). However it doesn't get the boot partition from it yet.
While it's not the recommended boot method, it could be useful for testing with QEMU (allows passing kernel settings as command line args).
Unlike GRUB, GRUB2, LILO, and most other MBR loaders, our own MBR sector does not pass the selected partition info properly, and our stage1 loader does not attempt to use it, which is why we require running makebootable on install. But it should not be necessary.
Most MBR pass the selected boot partition entry in a register (ds:si) with a flag set to let the chainloaded OS know about it. There is no reason not to do it as well, as it would eliminate the need for makebootable.
This is not about BIOSes, buggy or not, since it's only the MBR which does this, and except if the user does not install our own MBR or GRUB or GRUB2 or the many other MBRs which support this convention, it would just work without makebootable.
We can still ship with makebootable just in case, but it shouldn't be required anymore once this is fixed.
Looks fine now with hrev50087.
This is hrev50087.
After logging into dropbox, the page starts to load, all kinds of widgets appear, but after a short while Web+ crashes (see attached full report):
0x71717a58 0x37604cd WebCore::WebSocket::create(WebCore::ScriptExecutionContext&, WTF::String const&, WTF::Vector<WTF::String, (unsigned long)0, WTF::CrashOnOverflow, (unsigned long)16> const&, int&) + 0x7d 0x71717ac8 0x356259e WebCore::JSWebSocketConstructor::constructJSWebSocket1(JSC::ExecState*) + 0xfe 0x71717b08 0x3562853 WebCore::JSWebSocketConstructor::constructJSWebSocket(JSC::ExecState*) + 0xc3 0x71717b78 0x488a454 JSC::LLInt::setUpCall(JSC::ExecState*, JSC::Instruction*, JSC::CodeSpecializationKind, JSC::JSValue, JSC::LLIntCallLinkInfo*) + 0xe4 0x71717bb8 0x48857b3 llint_slow_path_construct + 0xa3 . .. ...
There are still a few drawing errors at the top (the facebook button etc.), but the discribed bug has been fixed.
This works now with the new webkit build (hrev50087 here).
Fixed in hrev50091.
Applied in hrev50090.
Applied with minor changes in hrev50089.
Fixed the actual problem in hrev50088. The comment was not referring to the string length (not a problem, the used format string would lead to a fixed format), but to the fact that the static variables used were not thread safe.
Applied in hrev50087. Thanks!