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.
Tools will be published shortly.
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_ ? :-)
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
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.