Latest Bugs & Tasks

Since the recent changes to Tracker "find" panel, i have noticed that is wider: 732 pixel. On low res screens this could be an issue. Should be this panel resizable or smaller? See the screenshot attached.

Possibly related to #3008. Brand new build of an IvyBridge system. Syslog attached.

System starts up, goes through the lil icons stuff. After the rocket, screen turns off/goes to sleep, and unresponsive.

​https://bitbucket.org/haikuports/haikuports/commits/644976f should fix the debug issue.

hrev45581 updated the Mesa package

Should be resolved now, feel free to reopen this if you still see problems.

Done.

Tools will be published shortly.

First:
When on Haiku we use another hard disk to store data (eg a fat32 disk) Haiku will automatically make a folder called "RECYCLED" and then a subfolder called "_BEOS_" (see the screenshot). BeOS was cool without any doubt, but Haiku also is totally cool; so the autogenerated folder should be generated as _HAIKU_ ? :-)

Second:
The same is for the folder beos_mime located in /boot/home/config/settings; could be updated as "haiku_mime"?

Replying to jprostko:

Korli, thank you for the commit! I suppose this could be closed as fixed (since it does fix the issue), but shouldn't we add native GCC 4.6.4 optional packages for x86 and x86_64 just to be "complete"? I tried doing as much earlier today, but it seems this

I was expecting maybe the current package management effort would include this adding an optional package for GCC4, as it did for GCC2 :)

Alexander, I'm marking as fixed. Please reopen if needed.

$49 ARM computer.

The filesystem layout looks similar to the Raspberry Pi except u-boot is used and things are a little more open source friendly.

This is a general ticket to keep track of a potential port. Please use additional tickets for anything beyond getting the boot loader code running.

SD Card Layout:

kallisti5@nyx fat :( $ sudo fdisk -l /dev/loop0
Disk /dev/loop0: 3657 MB, 3657433088 bytes, 7143424 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
      Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1   *          63      144584       72261    c  W95 FAT32 (LBA)
/dev/loop0p2          144585     7132859     3494137+  83  Linux

Boot Partition:

kallisti5@nyx fat :) $ ls -lah
total 448K
-rwxr-xr-x 1 root root   20 Mar 18 09:21 ID.txt
-rwxr-xr-x 1 root root  80K Mar 18 09:20 MLO
-rwxr-xr-x 1 root root 333K Mar 18 09:20 u-boot.img
-rwxr-xr-x 1 root root   14 Mar 18 11:01 uEnv.txt

Example u-boot image:

kallisti5@nyx fat :) $ file u-boot.img
u-boot.img: u-boot legacy uImage, U-Boot 2013.01.01-00018-gff666a3\024, Firmware/ARM, Firmware Image (Not compressed), 340300 bytes, Mon Mar 18 03:17:02 2013, Load Address: 0x80800000, Entry Point: 0x00000000, Header CRC: 0xB3051E22, Data CRC: 0x5EE391D5

Priority set to low for obvious reasons :)

Fixed in hrev45573

Should be fixed in hrev45565.

vm_soft_fault: va 0x0 not covered by area in address space
vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x8, ip 0x8203ee91, write 1, user 0, thread 0x2d7
PANIC: vm_page_fault: unhandled page fault in kernel space at 0x8, ip 0x8203ee91
Welcome to Kernel Debugging Land...
Thread 727 "checkfs" running on CPU 4
stack trace for thread 727 "checkfs"
    kernel stack: 0xcce54000 to 0xcce58000
      user stack: 0x62737000 to 0x63737000
frame               caller     <image>:function + offset
 0 cce57738 (+  32) 801328d2   <kernel_x86> arch_debug_stack_trace + 0x12
 1 cce57758 (+  16) 80092c03   <kernel_x86> stack_trace_trampoline(NULL) + 0x0b
 2 cce57768 (+  12) 80125372   <kernel_x86> arch_debug_call_with_fault_handler + 0x1b
 3 cce57774 (+  48) 800946a6   <kernel_x86> debug_call_with_fault_handler + 0x5e
 4 cce577a4 (+  64) 80092e23   <kernel_x86> kernel_debugger_loop(0x801716f7 "PANIC: ", 0x80187560 "vm_page_fault: unhandled page fault in kernel space at 0x%lx, ip 0x%lx
", 0xcce57850 ", int32: 4) + 0x21b
 5 cce577e4 (+  48) 80093187   <kernel_x86> kernel_debugger_internal(0x801716f7 "PANIC: ", 0x80187560 "vm_page_fault: unhandled page fault in kernel space at 0x%lx, ip 0x%lx
", 0xcce57850 ", int32: 4) + 0x53
 6 cce57814 (+  48) 80094a32   <kernel_x86> panic + 0x36
 7 cce57844 (+ 144) 80109e95   <kernel_x86> vm_page_fault + 0x145
 8 cce578d4 (+  80) 8013410f   <kernel_x86> x86_page_fault_exception + 0x18b
 9 cce57924 (+  12) 80127e20   <kernel_x86> int_bottom + 0x30
kernel iframe at 0xcce57930 (end = 0xcce57980)
 eax 0x8204fe80    ebx 0x8204fb34     ecx 0x0         edx 0x0
 esi 0xcc7ff048    edi 0x0            ebp 0xcce57984  esp 0xcce57964
 eip 0x8203ee91 eflags 0x10282
 vector: 0xe, error code: 0x2
10 cce57930 (+  84) 8203ee91   <bfs> __19TransactionListener + 0x19
11 cce57984 (+  48) 8202b764   <bfs> __9BPlusTreeP5Inode + 0x24
12 cce579b4 (+  48) 82035059   <bfs> __5InodeP6Volumex + 0xf5
13 cce579e4 (+  96) 820443f8   <bfs> bfs_get_vnode(fs_volume*: 0xcd5bdd20, int64: 4246495, fs_vnode*: 0xcc7fb4e0, 0xcce57a8c, 0xcce57a90, true) + 0x208
14 cce57a44 (+  96) 800d88de   <kernel_x86> get_vnode(int32: 4, int64: 4246495, vnode*: 0xcce57af0, true, int32: 1) + 0x356
15 cce57aa4 (+  80) 800dd4e7   <kernel_x86> get_vnode + 0x3f
16 cce57af4 (+  48) 8202aad1   <bfs> Vnode<0xcce57cc4>::SetTo(Volume*: 0x8322e100, int64: 4246495) + 0x5d
17 cce57b24 (+ 432) 820285f6   <bfs> BlockAllocator<0x8322e318>::CheckNextNode(check_control*: 0xcce57d10) + 0x626
18 cce57cd4 (+ 448) 82045272   <bfs> bfs_ioctl(fs_volume*: 0xcd5bdd20, fs_vnode*: 0xd33c5ce8, 0xcfad8410, uint32: 0x377b (14203), 0x6373655c, uint32: 0x184 (388)) + 0x116
19 cce57e94 (+  64) 800e13b4   <kernel_x86> common_ioctl(file_descriptor*: 0xd3770c20, uint32: 0x377b (14203), 0x6373655c, uint32: 0x184 (388)) + 0x38
20 cce57ed4 (+  48) 800cbf97   <kernel_x86> fd_ioctl(false, int32: 5, uint32: 0x377b (14203), 0x6373655c, uint32: 0x184 (388)) + 0x5b
21 cce57f04 (+  64) 800ccd7c   <kernel_x86> _user_ioctl + 0x58
22 cce57f44 (+ 100) 80128010   <kernel_x86> handle_syscall + 0xcd
user iframe at 0xcce57fa8 (end = 0xcce58000)
 eax 0x8e          ebx 0x152f048      ecx 0x63736484  edx 0x60f7e114
 esi 0x5           edi 0x0            ebp 0x637364b0  esp 0xcce57fdc
 eip 0x60f7e114 eflags 0x3202    user esp 0x63736484
 vector: 0x63, error code: 0x0
23 cce57fa8 (+   0) 60f7e114   <commpage> commpage_syscall + 0x04
24 637364b0 (+ 720) 02b7be97   <bfs> BFSPartitionHandle<0x2d79030>::Repair(false) + 0x453
25 63736780 (+  48) 00999b09   <libbe.so> BPartition::Delegate<0x2d79510>::Repair(false) + 0x39
26 637367b0 (+  48) 00997fdc   <libbe.so> BPartition<0x2d9dca8>::Repair(BPartition: 0x63730000, true) + 0x30
27 637367e0 (+ 192) 0157c57e   <_APP_> main + 0x3ee
28 637368a0 (+  48) 0157c037   <_APP_> _start + 0x5b
29 637368d0 (+  48) 0124c506   </boot/system/runtime_loader@0x0123d000> <unknown> + 0xf506
30 63736900 (+   0) 60f7e250   <commpage> commpage_thread_exit + 0x00}}}

The culprit seems to be ​this new operator. Apparently the non-nothrow new, if hacked to not throw anymore, simply calls the constructor on a NULL pointer when running out of memory.

This is gcc 2 at hrev45561.

It seems that ​44d2f5f53ecdbd030882fca45e40d53ea38801af has broken the ability to boot when installed on my disks and booting bare metal. I can boot it in vbox with a fresh vm but it also fails in vbox when trying to boot using raw disk access to multiple partitions.

Currently, breakpoints are always triggered when their instruction is hit. It would be nice to support a breakpoint condition in addition such that the latter must evaluate to true in order for the breakpoint to actually trigger. Contingent on general expression evaluation support.

It would be useful to support evaluation of arbitrary expressions in the context of the target team. However, this would require relatively sophisticated language parsing to implement. A possibility would be hooking into LLVM's parsing libraries once the latter is a bit more mature and/or shipped as a default development package with Haiku.

Eventually it would be nice to support debugging remote teams. This requires corresponding support in debug_server though.

Currently our debug_server only supports handling local teams. It would be useful to design and implement support for listening for remote connections, as well as a corresponding remote debugging protocol. The latter could potentially be based on the existing gdb protocol, which would also allow remote debugging via gdb itself. However, to fully support the native feature set, that protocol would likely require some non-standard extensions, so that might be better as an additional possible option rather than being the primary native remote protocol.

Currently, flow control is limited to run, step over, step into, step out, and breakpoints/watchpoiknts. In addition to these, it would also be nice to have a few more interactive options, such as being able to point to a line of code with the mouse cursor and asking to run to that point. The implemention shouldn't be that complex either, as this in effect simply necessitates setting a temporary breakpoint at said source location.

Another related but more complex feature that might be nice would be the ability to change the flow of control to a particular statement in a function, even one that's already been stepped over. The use case would be if, e.g. one has simply stepped over, and the return value was unexpected, so it's desired to execute said line again with a Step Into in order to understand why. This gets more complicated to implement however, since it may potentially mean changing the stack pointer and other cpu state attributes besides just the current instruction.

Currently one can see memory and variables, but not influence them. It would be nice to have edit support as well. On the memory inspector side this should be relatively straightforward, but for the variables view/table model it will be a bit more complex since the type of editor to present will have to vary based on value type.