Latest Bugs & Tasks

Syndicate content Haiku
Trac Timeline
Updated: 50 min 22 sec ago

Ticket #12393 (Crash when moving to trash (if renaming under way)) created

Fri, 2015-09-25 09:52

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?

Categories: Development

Ticket #12392 ([Tracker] insets of vertical scrollbar) created

Fri, 2015-09-25 09:26

In hrev49654 vertical scrollbar was changed and now looks unaligned:

Categories: Development

Ticket #12390 ([cmp] fails to find difference) closed

Fri, 2015-09-25 04:58

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.

Categories: Development

Ticket #12391 (KDL in messaging command processor) created

Thu, 2015-09-24 20:53

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   <> _kern_write_port_etc + 0x0c
22 00007f11ab23f510 (+  48) 0000019b29eb6f67   <> 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   <> _thread_do_exit_work (nearest) + 0x72
29 00007f11ab23f6f0 (+   0) 00007f9cf7952260   <commpage> commpage_thread_exit + 0x00
Categories: Development

Ticket #12390 ([cmp] fails to find difference) created

Thu, 2015-09-24 16:32

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 ...

Categories: Development

Ticket #12389 (Sockets not opened or closed unexpectedly) created

Wed, 2015-09-23 14:36

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).

Categories: Development

Ticket #12388 (Missing support for TLS SNI (easy)) created

Tue, 2015-09-22 12:05

SNI support can be tested here: ​
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

Categories: Development

Ticket #12387 ([checkstyle] change html output to confirm to xhtml strict) created

Mon, 2015-09-21 23:03

Running python src/tools/checkstyle/ src/tools/checkstyle/test.cpp generates a styleviolations.html file.

WebPositive complains about this file:

Attached patch fixes the html output to confirm to XHTML Strict. WebPostitive now renders the file completely without any complaints.

Categories: Development

Ticket #8790 ("Get info" and multiple files selection) closed

Mon, 2015-09-21 09:45

Closing this one then as the other ticket looks like more clear.

Categories: Development

Ticket #12386 (Terminal: launching apps in the background no longer detaches them from ...) closed

Mon, 2015-09-21 08:18
no change required:

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.
Categories: Development

Ticket #12386 (Terminal: launching apps in the background no longer detaches them from ...) created

Sun, 2015-09-20 19:12

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...

Categories: Development

Ticket #12384 (Tracker Hide, Close, Show All View) created

Sun, 2015-09-20 00:50

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.

Categories: Development

Ticket #12383 (FillTrangle produces slightly different results if drawn in a BPicture) created

Fri, 2015-09-18 13:36

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.

Categories: Development

Ticket #12382 (Deskbar freeze randomly) created

Wed, 2015-09-16 21:24

In latest official hrev49645 hybrid gcc2 I met Deskbar freeze.
This problem was already reported in #5948.

Need to kill and restart the Deskbar to re-enable it.

Categories: Development

Ticket #12381 (PANIC: calculated irq routing doesn't match bios for PCI 6:0:0) closed

Wed, 2015-09-16 07:25

Yes, reported and fixed in #12377. Thanks for reporting!

Categories: Development

Ticket #12381 (PANIC: calculated irq routing doesn't match bios for PCI 6:0:0) created

Tue, 2015-09-15 19:40

Latest test on hrev49638 x86_gcc2. This panic was in the previous builds too.

Categories: Development

Ticket #12377 (PANIC: calculated irq routing doesn't match bios for PCI 24:0:0) closed

Tue, 2015-09-15 12:47

Thanks for reporting! Closing this, will do some more work related to this later though.

Categories: Development