Latest Bugs & Tasks

I found a memory leak in BMediaFile -> MediaTrack. If you create a MediaTrack from BMediaFile, than release it again, close the media file and delete the media file object it is still some memory alloceted.
I wrote a short test app (paladin project) to demonstrate the memory leak/bug, have a look to the method "DebugClass::TestMethod()" in the test app.

Right. Removed with hrev45282. Thanks!

Quite correct, the setting was not getting saved to disk which is why it appear again next reboot, should be fixed in hrev45280. Doesn't matter if you hide/show from the context menu or Time prefs.

While updating the BeOS VNC server for Haiku, it occurs to me that it would be nice to have the Haiku specific cursor (hand shape, pointer arrow, insertion marker, etc) displayed at the VNC client side of things. VNC has an API for transmitting the cursor, and the client software does change the system cursor there to match the new bitmap. All we need to have is the bitmap from Haiku and some sort of notification of when it has changed.

Since we're using a BDirectWindow to do the screen scraping, perhaps the API could be added there (that also avoids the problem of deciding which workspace it is on, etc). Though I think someone with more knowledge should decide where it should go. The API could be something like this:

• GetCursorBitmap - reads the current cursor bitmap, includes alpha transparency. Need the pixel format too, if it's not a simple RGBA 32 bit pixel, and maybe worry about endianness too.
• GetCursorSerialNumber - gets the count of the number of times the cursor has been changed. The idea is that the VNC server will periodically call this and if the number has changed, get the new cursor bitmap and transmit it over the network to the client.
• IsCursorDrawn - returns TRUE if the cursor is being drawn into the screen video memory. FALSE if it is a separate video hardware cursor.

If the hardware cursor is off or not implemented, then it does seem to work, since Haiku writes the cursor shape into the screen's bitmap and VNC picks that up. If the hardware cursor is operational, then the user doesn't see anything and the VNC client currently substitutes a black dot or some other fixed graphic to show where the mouse is.

By the way, one other obvious but actually not useful VNC optimisation would be to have the app_server report all the dirty areas of the screen, so VNC can know which parts need updating over the network. It currently scans the whole screen to find the changed parts, which can be slow. On the other hand, the current method is more responsive since it scans in slices so each update will be small enough to keep feedback (mouse movement) fast. So using the dirty areas would actually make things feel slower for the user!

As i remember this issue was always present in any Haiku revision.
If i uncheck "show clock in Deskbar", at the next reboot, the clock in Deskbar appears again.

hrev45148

Fixed in hrev45278.

Please look out for older tickets. This one is a duplicate of #8979 that you reported a few months ago :-)

Also, please always include the original KDL message. If it is scrolled out of sight, you can use the message command to let KDL print it again.

Hi,

i got the following KDL. So far I see and unstand it is caused by libbe.so or the Haiku-OS kernel.

stack trace for thread 199 "w:124:/boot/home/Desktop"
    kernel stack: 0x81baf000 to 0x81bb3000
      user stack: 0x7067c000 to 0x706bc000
frame               caller     <image>:function + offset
0 81bb2b58 (+  48) 80095238   <kernel_x86> invoke_command_trampoline( [34m0x81bb2bf0 [0m) + 0x1c
1 81bb2b88 (+  12) 80123f32   <kernel_x86> arch_debug_call_with_fault_handler + 0x1b
2 81bb2b94 (+  48) 800941b2   <kernel_x86> debug_call_with_fault_handler + 0x5e
3 81bb2bc4 (+  64) 80095491   <kernel_x86> invoke_debugger_command + 0xb9
4 81bb2c04 (+  64) 800952bd   <kernel_x86> invoke_pipe_segment(debugger_command_pipe*: [34m0xcce38030 [0m, int32: [34m0 [0m, [34m0x0 [0m [31m"<NULL>" [0m) + 0x79
5 81bb2c44 (+  64) 800955fc   <kernel_x86> invoke_debugger_command_pipe + 0x9c
6 81bb2c84 (+  48) 80097298   <kernel_x86> ExpressionParser< [32m0x81bb2d34 [0m>::_ParseCommandPipe( [34m0x81bb2d30 [0m) + 0x234
7 81bb2cb4 (+  64) 800964b8   <kernel_x86> ExpressionParser< [32m0x81bb2d34 [0m>::EvaluateCommand( [34m0x801a2f60 [0m [36m"sc | qrappend" [0m, [34m0x81bb2d30 [0m) + 0x2d0
8 81bb2cf4 (+ 224) 800988e4   <kernel_x86> evaluate_debug_command + 0x80
9 81bb2dd4 (+  64) 80092a3e   <kernel_x86> kernel_debugger_loop( [34m0x801700f7 [0m [36m"PANIC: " [0m, [34m0x80152064 [0m [36m"port %ld: no messages found
" [0m, [34m0x81bb2e80 [0m [36m"� " [0m, int32: [34m3 [0m) + 0x32a
10 81bb2e14 (+  48) 80092c93   <kernel_x86> kernel_debugger_internal( [34m0x801700f7 [0m [36m"PANIC: " [0m, [34m0x80152064 [0m [36m"port %ld: no messages found
" [0m, [34m0x81bb2e80 [0m [36m"� " [0m, int32: [34m3 [0m) + 0x53
11 81bb2e44 (+  48) 8009453e   <kernel_x86> panic + 0x36
12 81bb2e74 (+  80) 800634d4   <kernel_x86> _get_port_message_info_etc + 0x2ac
13 81bb2ec4 (+  80) 80063219   <kernel_x86> port_buffer_size_etc + 0x25
14 81bb2f14 (+  48) 800643c9   <kernel_x86> _user_port_buffer_size_etc + 0x8d
15 81bb2f44 (+ 100) 80126bd0   <kernel_x86> handle_syscall + 0xcd
user iframe at 0x81bb2fa8 (end = 0x81bb3000)
eax 0xd4          ebx 0x98c8e8       ecx 0x706bbe30  edx 0xffff0114
esi 0xffffffff    edi 0x7fffffff     ebp 0x706bbe5c  esp 0x81bb2fdc
eip 0xffff0114 eflags 0x3216    user esp 0x706bbe30
vector: 0x63, error code: 0x0
16 81bb2fa8 (+   0) ffff0114   <commpage> commpage_syscall + 0x04
17 706bbe5c (+  48) 00491b45   <libbe.so> BPrivate::LinkReceiver< [32m0x186d5a38 [0m>::AdjustReplyBuffer(int64: [34m9223372036854775807 [0m) + 0x45
18 706bbe8c (+  64) 00491c07   <libbe.so> BPrivate::LinkReceiver< [32m0x186d5a38 [0m>::ReadFromPort(int64: [34m9223372036854775807 [0m) + 0x3b
19 706bbecc (+  48) 004919eb   <libbe.so> BPrivate::LinkReceiver< [32m0x186d5a38 [0m>::GetNextMessage( [34m0x706bbf44 [0m, int64: [34m9223372036854775807 [0m) + 0x47
20 706bbefc (+ 128) 002a2c70   <_APP_> ServerWindow< [32m0x186d36d8 [0m>::_MessageLooper( [34m0x0 [0m) + 0x2fc
21 706bbf7c (+  48) 0027f668   <_APP_> MessageLooper< [32m0x186d36d8 [0m>::_message_thread(NULL) + 0x28
22 706bbfac (+  48) 008e7893   <libroot.so> _get_next_team_info (nearest) + 0x5f
23 706bbfdc (+   0) 706bbfec   4713:w:124:TrackerWindow_199_stack@0x70678000 + 0x43fec

Nope :-)

Fixed in hrev45274

Fixed in hrev45273

The descritpions and the page that is linked to from the source activity area of the website needs to refer to the hrev that is being reported. We use hrev to identify the build of haiku, hrev is used to identify nightly builds. the hrev will tell us testers if this change should be included in this nightly build.

example: the Source Activity says:
"Lock about window before deleting it on destruction"
and links to: ​https://github.com/haiku/haiku/commit/19ec4667bc7ca7b40bba7ac54499df4a50c33405

it would be better to have the Source activity say:
"hrev45271 Lock about window before deleting it on destruction"
and link to:
​http://cgit.haiku-os.org/haiku/commit/?id=hrev45271

This one is my fault, should be fixed in hrev45271.

This is gcc4 build of hrev45257 on real Hardware.

If you shutdown Haiku with PowerStatus added to the DeskBar,
you will get the attached SegFault in the destructor.

I've tried two different USB thumb drives, a 2GB Verbatim "Store n go" and a 32GB Sandisk Cruzer Glide.

Both USB sticks work just fine with different formatting. I've booted the machine with both in before and after they were Haiku formatted and they worked fine.

I formatted the 2GB both as a YUMI multiboot (before the Haiku boot problems), and as a win98 boot disk to update the BIOS (after the boot problems). Booted fine as both.

But either stick, as soon as I write the Haiku anyboot to it, precisely as per ​https://www.haiku-os.org/guides/installing/making_haiku_usb_stick which has worked for me any other time, the BIOS locks up as soon as it shows the CPU type.

I have added an "Always on top" menu to th ActivityMonitor's Settings menu. This can be useful if the user want to monitor the performance while working on Haiku.

Patch file has been attached. Tested: working.

Fixed in hrev45266.

Fixed in hrev45266.