Latest Bugs & Tasks

This is hrev45525.

Since the recent keystore addition, connecting to wifi isn't working every time. Connecting via the NetworkStatus icon in the Deskbar works sometimes, sometimes it doesn't. Sometimes I get asked to give the wpa_supplicant access to the keystore ("Allow always"), sometimes not. Then, while connecting, the connection window with the already filled in password appears 3 times after another. I'm not sure if I should check the box "Store this configuration" or not...

Anyway, then often the wpa_supplicant crashes, see attached report plus syslog and syslog.old. Not sure how much of syslog.old is from that session. Is there a way to detect the start of the entries for the most recent session?

In this session, I tried to down/up/scan with ifconfig to make my network ("haiku-top") visible again in the NetworkStatus replicant and tried once more to connect. Same result.

See attached report.

Should be finally resolved in hrev45533.

on hrev45526. Boots OK when removing hrev45518.

(tested with GCC 4.6.3 and GCC 4.6.4)
QEMU emulator version 1.2.0 (qemu-kvm-1.2.0+noroms-0ubuntu2.12.10.3, Debian)

Haiku revision: hrev45526
reserve_io_interrupt_vectors: reserved 2 vectors starting from 98
CPU 0: type 0 family 6 extended_family 0 model 3 extended_model 0 stepping 3, string 'GenuineIntel'
CPU 0: vendor 'Intel' model name 'QEMU Virtual CPU version 1.2.0'
CPU 0: features: fpu de pse tsc msr pae mce cx8 apic sep pge cmov pat mmx fxsr sse sse2 sse3 popcnt hypervisor dts ecmd aperfmperf epb
PANIC: Unexpected exception "General Protection Exception" occurred in kernel mode! Error code: 0x0
Welcome to Kernel Debugging Land...
Thread 0 "" running on CPU 0
stack trace for thread 0 ""
    kernel stack: 0x00000000 to 0x00000000
frame               caller     <image>:function + offset
 0 81004d1c (+  32) 801105a4
 1 81004d3c (+  16) 8008309e
 2 81004d4c (+  12) 80103a62
 3 81004d58 (+  48) 80083af1
 4 81004d88 (+  80) 8008477e
 5 81004dd8 (+  64) 800849fa
 6 81004e18 (+  32) 80084c5b
 7 81004e38 (+ 176) 80111a28
 8 81004ee8 (+  12) 8010647e
kernel iframe at 0x81004ef4 (end = 0x81004f44)
 eax 0x80172d01    ebx 0x81004f88     ecx 0x1b0       edx 0x0
 esi 0x80172c80    edi 0x80172d0c     ebp 0x81004fb0  esp 0x81004f28
 eip 0x80103937 eflags 0x210092
 vector: 0xd, error code: 0x0
 9 81004ef4 (+ 188) 80103937
10 81004fb0 (+  32) 8004d159
11 81004fd0 (+  32) 80056285

This is hrev45525.

Right-click drag&dropping the query icon from the find dialog used to show a context menu when dropping the icon. There you could choose to save the query as "query template" instead. That doesn't work anymore.

This is hrev45525.

When doing any admin tasks on sourceforge projects, like creating a new project or changing info or uploading an icon etc, pressing the "Save", "Create" or whatever button to submit the new data will take you to the login screen instead. No data is sent/updated.

Still crashes in hrev45531. It also prints "Invalid argument" in case a process name doesn't exist. I think "No such process (name") would be better.

While making changes to Tracker's Find to use the Layout API, discovered a drawing bug when layout changes were triggered by a function in the overridden BWindow::MessageReceived hook.

The window calls DisableUpdates(), makes layout changes, and then calls EnableUpdates(), but the window is not redrawn correctly. Even adding UpdateIfNeeded() after EnableUpdates() did not cause the window to redraw.

Removing the calls to disable/enable updates allowed the window to redraw correctly.

My current changes are available at ​https://github.com/jessicah/haiku/tree/find-panel-layout-api, ​SwitchToTemplate.

Fixed in hrev45526.

Fixed in hrev45526.

If you want to compile an InputServer add-on, you need to link it against the appropriate (32/64 bit, GCC2/4, etc) InputServer. BeOS had a symbolic link named _INPUTSERVER_ in the /boot/develop/lib/x86 directory which pointed to the executable /boot/beos/system/servers/input_server. Haiku doesn't have it.

There are other libraries in Haiku's /boot/develop/lib/x86 directory (actually a symbolic link, which points to GCC2 or GCC4 varieties), even _KERNEL, but no _INPUTSERVER_. It would be useful to have for compiling add-ons outside the whole Haiku build process.

In particular I'm trying to make an InputServer add-on for VNC that simulates input from a remote mouse and keyboard, for GCC4. For now, I'll just link with the input server executable from a GCC4 build of Haiku.

If one tries to kill by pid, if e.g. the pid doesn't exit, kill crashes and one sees the message twice:

~/> kill 1234
kill: 1234: No such process
kill: 1234: No such process

Also kill doesn't print the message at all if one tries to kill by process name which doesn't exist:

~/> kill foo

Since the ASLR changes, attempting a jam -qj8 build of Haiku under Haiku itself frequently fails with the above error message. Rerunning the command works for a while longer, then eventually fails again the same way. Nothing of interest shows up in syslog though, and I've been unable to reproduce it while running with strace so I assume a race of some form is involved. Hardware here is a quad core i7 w/ hyperthreading and 8GB of RAM, ergo PAE is active.

hrev45525
If i launch GLTeapot or any other app which use OpenGL (eg the game BillardGL or Quake II) i always got an error.
Files attached: crash report of BillardGL, GLTeapot and the part of syslog related to error.

Currently, RetrieveMemoryBlockJob doesn't notify the block's listener if reading the requested block fails for whatever reason. Consequently, if this occurs while generating a crash report, it will wait forever for the job to complete and never write the report out.

See ​https://wiki.freebsd.org/dev/ath_hal%284%29/AR9300 for the current FreeBSD support state for these family of adapters of QCA (QualCom Atheros).

Fixed in hrev45525.
Blame me for this bug I'm so sorry I've introduced two years ago in hrev41274.

Applied with some style and code cleanup in hrev45523.
Thanks.

Currently, the only way to start a new team with Debugger rather than attach to an existing one is by passing a command line. It would be nice if the teams window also featured a way to start a new one rather than just being able to attach to existing ones.