Latest Bugs & Tasks
Not a very prominent/annoying bug, but easily reproducible:
- select e.g. a folder (clicking its icon, not its name)
- click its name
- hit (quickly!) Alt-T to move it to trash
If you've hit Alt-T before the renaming starts (appearance of a BTextView ..etc), it crashes in BPrivate::BTextWidget::StartEdit().
Maybe when the "rename" timer fires, it contains a pointer to the no-longer-existing widget?
In hrev49654 vertical scrollbar was changed and now looks unaligned:
It appears the issue is with the output (or lack thereof). The exit code behaves normally. E.g. echo $? after the command will output 1 if they differ, 0 if they're the same.
Anyway, this is part of the diffutils package at HaikuPorts now.
Not sure of the cause, but got the following KDL with the following configuration:
- hrev49658 x86_64
- libvirtd vm under linux kvm
- virtio block storage
- boot machine
- eventually see kdl below
kdebug> bt stack trace for thread 313 "messaging command processor" kernel stack: 0xffffffff818b6000 to 0xffffffff818bb000 user stack: 0x00007f11ab200000 to 0x00007f11ab240000 frame caller <image>:function + offset 0 ffffffff818ba468 (+ 32) ffffffff800a38f9 <kernel_x86_64> invoke_command_trampoline(void*) + 0x19 1 ffffffff818ba488 (+ 24) ffffffff801308bc <kernel_x86_64> arch_debug_call_with_fault_handler + 0x16 2 ffffffff818ba4a0 (+ 96) ffffffff800a10ac <kernel_x86_64> debug_call_with_fault_handler + 0x68 3 ffffffff818ba500 (+ 96) ffffffff800a3acb <kernel_x86_64> invoke_debugger_command + 0xcf 4 ffffffff818ba560 (+ 80) ffffffff800a3c0c <kernel_x86_64> invoke_pipe_segment(debugger_command_pipe*, int, char*) + 0x81 5 ffffffff818ba5b0 (+ 80) ffffffff800a3ced <kernel_x86_64> invoke_debugger_command_pipe + 0xa0 6 ffffffff818ba600 (+ 80) ffffffff800a804d <kernel_x86_64> ExpressionParser::_ParseCommandPipe(int&) + 0xdbf 7 ffffffff818ba650 (+ 96) ffffffff800ae234 <kernel_x86_64> ExpressionParser::EvaluateCommand(char const*, int&) + 0xba2 8 ffffffff818ba6b0 (+ 240) ffffffff800af4b3 <kernel_x86_64> evaluate_debug_command + 0x99 9 ffffffff818ba7a0 (+ 96) ffffffff800a2132 <kernel_x86_64> kernel_debugger_loop(char const*, char const*, __va_list_tag*, int) + 0x2fd 10 ffffffff818ba800 (+ 80) ffffffff800a22fa <kernel_x86_64> kernel_debugger_internal(char const*, char const*, __va_list_tag*, int) + 0x132 11 ffffffff818ba850 (+ 240) ffffffff800a256e <kernel_x86_64> panic + 0xc1 12 ffffffff818ba940 (+ 272) ffffffff8011c5c5 <kernel_x86_64> vm_page_fault + 0x15a 13 ffffffff818baa50 (+ 64) ffffffff8013980c <kernel_x86_64> x86_page_fault_exception + 0x1bb 14 ffffffff818baa90 (+ 536) ffffffff801326ef <kernel_x86_64> int_bottom + 0x56 kernel iframe at 0xffffffff818baca8 (end = 0xffffffff818bad70) rax 0x0 rbx 0xffffffff82007510 rcx 0xf6 rdx 0xffffffff rsi 0xffffffff82007558 rdi 0xffffffff82007558 rbp 0xffffffff818bada0 r8 0xc6 r9 0x80000009 r10 0xc6 r11 0x3246 r12 0xffffffff878c0fc8 r13 0x0 r14 0xffffffff82007548 r15 0x1 rip 0xffffffff8010c968 rsp 0xffffffff818bad70 rflags 0x13282 vector: 0xe, error code: 0x0 15 ffffffff818baca8 (+ 248) ffffffff8010c968 <kernel_x86_64> object_cache_alloc + 0x1a8 16 ffffffff818bada0 (+ 64) ffffffff8010506f <kernel_x86_64> block_alloc(unsigned long, unsigned long, unsigned int) + 0x83 17 ffffffff818bade0 (+ 16) ffffffff80105383 <kernel_x86_64> malloc + 0x13 18 ffffffff818badf0 (+ 208) ffffffff8006c6c3 <kernel_x86_64> writev_port_etc + 0x41a 19 ffffffff818baec0 (+ 96) ffffffff8006d044 <kernel_x86_64> _user_write_port_etc + 0xc7 20 ffffffff818baf20 (+ 24) ffffffff80132995 <kernel_x86_64> x86_64_syscall_entry + 0xfb user iframe at 0xffffffff818baf38 (end = 0xffffffff818bb000) rax 0xdc rbx 0x2108804ffe0 rcx 0x1719aa5fb24 rdx 0x2108804ffe0 rsi 0x706a7070 rdi 0x77 rbp 0x7f11ab23f510 r8 0x8 r9 0x0 r10 0xc6 r11 0x3246 r12 0x77 r13 0x0 r14 0xc6 r15 0x7f11ab23f630 rip 0x1719aa5fb24 rsp 0x7f11ab23f508 rflags 0x3246 vector: 0x63, error code: 0x0 21 ffffffff818baf38 (+139715983984088) 000001719aa5fb24 <libroot.so> _kern_write_port_etc + 0x0c 22 00007f11ab23f510 (+ 48) 0000019b29eb6f67 <libbe.so> BMessage::_SendFlattenedMessage(void*, int, int, int, long) + 0x73 23 00007f11ab23f540 (+ 16) 0000002aeb6ba1c9 <_APP_> MessageDeliverer::_SendMessage(MessageDeliverer::Message*, int, int) + 0x19 24 00007f11ab23f550 (+ 208) 0000002aeb6ba9bf <_APP_> MessageDeliverer::DeliverMessage(void const*, int, MessagingTargetSet&, long) + 0x169 25 00007f11ab23f620 (+ 64) 0000002aeb6bd7cc <_APP_> MessagingService::DefaultSendCommandHandler::HandleMessagingCommand(unsigned int, void const*, int) + 0x48 26 00007f11ab23f660 (+ 96) 0000002aeb6bcfc1 <_APP_> MessagingService::_CommandProcessor() + 0xbb 27 00007f11ab23f6c0 (+ 16) 0000002aeb6bd0f5 <_APP_> MessagingService::_CommandProcessorEntry(void*) + 0x09 28 00007f11ab23f6d0 (+ 32) 000001719aa5e988 <libroot.so> _thread_do_exit_work (nearest) + 0x72 29 00007f11ab23f6f0 (+ 0) 00007f9cf7952260 <commpage> commpage_thread_exit + 0x00
hrev49623 (didn't check in older hrevs yet)
Unzip the attached folder. Do the below and watch as cmp fails to find a difference, even though there's one as evidenced by cksum and md5sum:
/boot/system/cache/tmp/New folder/cmp_bug> ls runtime_loader49137 runtime_loader49623 /boot/system/cache/tmp/New folder/cmp_bug> cmp * /boot/system/cache/tmp/New folder/cmp_bug> cksum * 3624641877 154316 runtime_loader49137 3137876803 154316 runtime_loader49623
Pretty jaw dropping when I saw that, not used to seeing binutils fail completely :-o ...
This report pertains to a nightly based install, from the "hrev 49652" image.
Using Webpositive, I found that occasionally pages would not load. Thinking this may not be a Webpositive issue, but instead a network issue, I used Netsurf for a while, and got approximately the same result (occasionally pages would not load). Netsurf displayed the error ("socket not connected), and Webpositive did not, but I suspect the same problem applies to both. I've attached two png images (the Netsurf message, and the debugger screen).
SNI support can be tested here: https://sni.velox.ch/?
This results in some https websites triggering self signed certificate errors, although in any browser supporting SNI (such as QupZilla), the certificate will be considered valid.
Haiku version: x86_gcc2 hrev49658
Running python src/tools/checkstyle/checkstyle.py src/tools/checkstyle/test.cpp generates a styleviolations.html file.
Closing this one then as the other ticket looks like more clear.
In Haiku it actually works as it should (you can check that in Linux (e.g. try something like xeyes)). Many things regarding signals and terminal session handling weren't implemented correctly in BeOS. When you start a process from the shell -- regardless of whether you start it in the foreground or background -- it still belongs to the same (terminal) session as the shell and is managed by the shell as an active job. When the terminal is closed, SIGHUP is sent to the shell, which in turn propagates it to all active jobs. Unless a process handles/ignores the signal explicitly, it will thus be killed.
Several things can prevent that fate:
- Obviously handling/ignoring SIGHUP by the process itself. There's also a wrapper tool nohup, which will do that: nohup my-program & will ignore SIGHUP and redirect stdin (from /dev/null) and stdout (to a file).
- You can tell the shell to remove the job from its list of active jobs: my-program & disown. The shell won't propagate SIGHUP to the job anymore. However, that won't affect the process' stdin/out/err, so one usually wants to redirect those, too.
I did a quick Trac search, but maybe I am indeed the first to notice: In previous Haiku releases and on BeOS, it was possible to launch Tracker (and Deskbar) via /system/Tracker & and when quitting the Terminal, Tracker would continue to run. This is no longer the case. I am probably picking the wrong component...
Like the title says.
Go to a directory with a large number of files
- Window->Select All
- File -> Get Info
There is no way to Hide or Close All open windows without scrolling through the entire list.
The function to Hide, Close or Show should be at the top for easy access.
See attached screenshot.
As shown by the FlattenPictureTest test, FillTriangle produces a slightly different result when invoked inside a BPicture.
This happens because there is no FILL_TRIANGLE op in the BPicture encoding, and FillTriangle is translated to a FillPolygon call. Now, I'd expect that FillPolygon(), when called with three points, would produce the same output that FillTriangle does.
Need to kill and restart the Deskbar to re-enable it.
Yes, reported and fixed in #12377. Thanks for reporting!
Latest test on hrev49638 x86_gcc2. This panic was in the previous builds too.
Thanks for reporting! Closing this, will do some more work related to this later though.
Fixed in hrev49644.