Latest Bugs & Tasks

Syndicate content Haiku
Trac Timeline
Updated: 1 hour 38 min ago

Ticket #12322 ([kernel] PANIC on boot with HP LaserJet 1102w printer attached) created

Fri, 2015-08-21 17:56


Haiku always crashes on boot with HP LaserJet 1102w printer attached.
Probably because the printer emulates usb drive with windows driver.

When plugged after boot this is what I get in syslog:

KERN: usb hub 7: port 3: new device connected
KERN: usb_disk: device reports a lun count of 1
KERN: usb_disk: vendor_identification    "HP      "
KERN: usb_disk: product_identification   "Smart Install   "
KERN: usb_disk: product_revision_level   "1.0 "
KERN: usb error ehci -1: qtd (0x571fd00) error: 0x00088d40
KERN: usb_disk: operation 0x25 failed at the SCSI level
KERN: usb_disk: failed to update capacity: Device media changed


046d:c062 /dev/bus/usb/0/1 "Logitech, Inc." "M-UAS144 [LS1 Laser Mouse]" ver. 3100
046d:c315 /dev/bus/usb/0/2 "Logitech, Inc." "Classic Keyboard 200" ver. 2800
0000:0000 /dev/bus/usb/0/hub "HAIKU Inc." "OHCI RootHub" ver. 0110
03f0:102a /dev/bus/usb/1/3 "Hewlett-Packard" "HP LaserJet Professional P 1102w" ver. 0100
0000:0000 /dev/bus/usb/1/hub "HAIKU Inc." "EHCI RootHub" ver. 0200

listusb -v /dev/bus/usb/1/3

[Device /dev/bus/usb/1/3]
    Class .................. 0x00 (Per-interface classes)
    Subclass ............... 0x00
    Protocol ............... 0x00
    Max Endpoint 0 Packet .. 64
    USB Version ............ 0x0200
    Vendor ID .............. 0x03f0 (Hewlett-Packard)
    Product ID ............. 0x102a
    Product Version ........ 0x0100
    Manufacturer String .... "Hewlett-Packard"
    Product String ......... "HP LaserJet Professional P 1102w"
    Serial Number .......... "000000000W412KEASI1c"
    [Configuration 0]
        Configuration String . ""
        [Interface 0]
            [Alternate 0 active]
                Class .............. 0x08 (Mass storage)
                Subclass ........... 0x06
                Protocol ........... 0x50
                Interface String ... "HP MS"
                [Endpoint 0]
                    MaxPacketSize .... 512
                    Interval ......... 0
                    Type ............. Bulk
                    Direction ........ Output
                [Endpoint 1]
                    MaxPacketSize .... 512
                    Interval ......... 0
                    Type ............. Bulk
                    Direction ........ Input
Categories: Development

Ticket #12321 (sftp transfer slow compared to ubuntu.) created

Fri, 2015-08-21 11:12

On lastest Haiku build (official nightly hrev49559 x86 hybrid gcc2) downloaded 21 august 2015, I still have the same speed issue.

I launch an sftp transfer of a file from haiku virtual host to physical host RHEL (Redhat Enterprise Linux) 6.5.
Then I launch an sftp transfer of the same file from ubuntu mate 15.04 32 bits to the same physical host RHEL (Redhat Enterprise Linux) 6.5.

Haiku and ubuntu are installed on the same virtualbox binaries (Virtualbox 4.3.14 hrev95030 provided with RHEL 6.5).

And with the same virtual network configuration (NAT Intel PRO/1000 MT Desktop (82540EM)).

The RHEL openssh server is openssh-server-5.3p1-94.el6.x86_64
ubuntu openssh version: OpenSSH_6.9p1, OpenSSL 1.0.0s 11 Jun 2015
haiku openssh version: OpenSSH_6.9p1, OpenSSL 1.0.0s 11 Jun 2015

On ubuntu the average speed is 35 MB/s.
On haiku the average speed is 8.8 MB/s.

Joined 2 screenshot and haiku /var/log/syslog + /var/log/syslog.old + versions of openssh.

Categories: Development

Ticket #12317 (Debugger (silent?) crash, incomplete report) closed

Thu, 2015-08-20 21:23

Replying to ttcoder:

Discussion (to continue in a new /clean ticket maybe):

  • wouldn't it be better if the kernel "held tight" on the crashed thread, instead of letting it go ?

That presents its own problems, since in the case where something goes wrong, that leaves you with a permanently unkillable thread without a reboot.

  • if it isn't, how could Debugger give a hint about what happened ? Seeing a list of threads with no indication of any of them being stopped gives the (false) impression that the Debugger report is spurious and the team did not really crash. We probably don't want that.

All the Debugger knows is the kernel told it the thread exited, so there's no way for it to differentiate that. That having been said, to be perfectly blunt, the attached code sample is pretty much a case study in how not to do things.

  • kill_thread() should never be getting used as a matter of course by application code, it exists as a last resort, and only that, since among other things, any resources the thread may have allocated would have been leaked in such a case, i.e. any memory/objects/sockets allocated by ntp_update_time(), and in fact, could potentially even cause issues/corruption for future invocations within the same team. kill_thread() exists solely for the use of tools like kill or ProcessController. Furthermore, since Haiku is currently single user, any mistake can potentially result in it killing threads in other teams, leading to other unpredictable behavior.
  • The way UpdateSystemTime() currently works is pretty horribly broken, as it will result in the aforementioned condition getting triggered if there's any transient network lag or temporary loss in connectivity, and as such, if this is being run periodically will cause the hosting application to leak resources over time, eventually leading to other code randomly failing.
  • Last but not least, loading an image as an add-on that isn't designed to be, such as an application image, is asking for trouble. That will cause global constructors/destructors to be called, which, if there are global and/or static variables involved, could potentially mess with the internal state of the calling application. Since all the source code in question is available, if you really want to use it this way, it would make more sense to simply pull that code into your own function and call it directly rather than the series of messy kludges used here. Alternatively, submitting a patch that pulls the ntp functionality into a daemon/standalone app that could be invoked by others would also be nice.

All in all, you're pretty much causing your own problems here in many ways, and I really don't see any good reason to go out of the way to accommodate such a situation.

Categories: Development

Ticket #12320 ([HaikuDepot] rating stars align to left on click) created

Thu, 2015-08-20 14:44


HaikuDepot aligns rating stars to the left on package click in featured view if it gets rating info from HDS.

Categories: Development

Ticket #11886 (HaikuDepot's contents tab should live-update) closed

Thu, 2015-08-20 14:28

Somehow the patch did not apply anymore, and I noticed that there were no checks for packageRef.Get() != NULL. So I quickly re-implemented it based on your patch. Thanks! Fixed in hrev49557.

Categories: Development

Ticket #12319 (Time/NTP sometimes crashes in gethostbyname()) created

Thu, 2015-08-20 12:58

This is hrev49523

We load Time as an add-on into CC's address space to use the Network Time Protocol syncing feature within it, about every 3 minutes (basically after each transition from one song to the next). Seems to work great initially.

However I Just saw this for the first time after doing an extended 12+ hr test run since the past night (and we had reports hinting at this for a few weeks in older hrevs).

All splitviews in Debugger were collapsed and 'locked' (I thought I had deleted the settings in config/settings/Debugger but will try again before filing a ticket for that) but retrieving the info from syslog was easy:

KERN: vm_soft_fault: va 0x719a0000 not covered by area in address space
KERN: vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x719a0844, ip 0x143481c, write 0, user 1, thread 0x4562
KERN: vm_page_fault: thread "(add-on)ntp_update_time" (17762) in team "CommandCenter" (602) tried to read address 0x719a0844, ip 0x143481c ("libnetwork.so_seg0ro" +0x1781c)
KERN: debug_server: Thread 17762 entered the debugger: Segment violation
KERN: stack trace, current PC 0x143481c  nsdispatch + 0xe4:
KERN:   (0x71945ff8)  0x142f811  gethostbyname_internal + 0x305
KERN:   (0x71946048)  0x142f4a9  gethostbyname + 0x79
KERN:   (0x71946078)  0x5cf11c  ntp_update_time__FPCcPPCcPl + 0x24
KERN:   (0x71946188)  0x1903f04  thread_func__25NetworktimeprefletAsAddonPv + 0x290
KERN:   (0x719462b8)  0x20d3c7f  thread_entry + 0x23

FWIW -- might be just a coincidence, but it ran fine when unattended through the night but crashed within a few minutes of me checking the system this morning -- I checked if CC was running fine, launched a browser, accessed sites.

Will shortly provide some sample code to make it easier to reproduce this (maybe combined with some heavier network and DNS access usage, in case there is a concurrency component involved in the bug?)

Categories: Development

Ticket #11772 (close_fd() page fault) closed

Thu, 2015-08-20 11:14
Categories: Development

Ticket #12318 ([kernel] PANIC: _mutex_lock(): using uninitialized lock) created

Thu, 2015-08-20 10:21


Happens during being idle couple times a day:

Categories: Development

Ticket #12317 (Debugger (silent?) crash, incomplete report) created

Thu, 2015-08-20 08:58

We've been getting forwarded .report files for CC that lack stack crawls. Did not know what to think of it until this week, when looking through their syslogs I managed to find a reference to a Debugger problem, which /might/ (I hope :-) be related and explain what is going on: maybe the .report is incomplete because Debugger has silently crashed behind the scenes while generating it ?

That particular machine seems to have several problems, including corrupted BFS index, unrelated/unexplained crashes in servers and daemons, so it could be that Debugger is another bystander to another problem, but filing a ticket just in case (there is another ticket about "shortened" .reports too IIRC)

KERN: vm_soft_fault: va 0x50007000 not covered by area in address space
KERN: vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x50007a47, ip 0xe512d6, write 0, user 1, thread 0xd70
KERN: vm_page_fault: thread "worker" (3440) in team "Debugger" (3439) tried to read address 0x50007a47, ip 0xe512d6 ("libroot.so_seg0ro" +0xaf2d6)
KERN: debug_server: Thread 3440 entered the debugger: Segment violation
KERN: stack trace, current PC 0xe512d6  malloc__Q28BPrivate10threadHeapUl + 0x4ca:
KERN:   (0x719c30c8)  0xe51bd4  malloc + 0x184
KERN:   (0x719c30f8)  0xcb5ec3  _Allocate__7BStringl + 0x27
KERN:   (0x719c3128)  0xcb5ff9  _Clone__7BStringPCcl + 0x21
KERN:   (0x719c3158)  0xcb5fb4  _Init__7BStringPCcl + 0x28
KERN:   (0x719c3188)  0xcb0f12  __7BStringPCc + 0x4a
KERN:   (0x719c31b8)  0xfeca13  GetSymbolInfos__17DebuggerInterfacellRt11BObjectList1Z10SymbolInfo + 0xe7
KERN:   (0x719c3608)  0xfe2ac1  FinishInit__14ImageDebugInfoP17DebuggerInterface + 0x4d
KERN:   (0x719c36a8)  0xfe5f28  LoadImageDebugInfo__13TeamDebugInfoRC9ImageInfoP13LocatableFileR26ImageDebugInfoLoadingStateRP14ImageDebugInfo + 0x1c4
KERN:   (0x719c36e8)  0xffa823  Do__21LoadImageDebugInfoJob + 0x8f
KERN:   (0x719c3768)  0x10830ed  _ProcessJobs__6Worker + 0x1f9
KERN:   (0x719c37a8)  0x1082df9  _WorkerLoop__6Worker + 0x21
KERN:   (0x719c37e8)  0x1082dcf  _WorkerLoopEntry__6WorkerPv + 0x1f
KERN:   (0x719c3818)  0xdd380b  thread_entry + 0x23
Categories: Development

Ticket #12316 (Helios CD Burning app crashes in Haiku) closed

Wed, 2015-08-19 08:15
no change required:

It was probably an application bug. I've fixed the build in ​

Categories: Development

Ticket #12316 (Helios CD Burning app crashes in Haiku) created

Wed, 2015-08-19 00:54

Installed Helios 1.6 Final.
Crashes on launch.
Debug reports attached.
There is a newer revision (1.71b2) in HaikuArchives with source files. However, it does not build (errors).

Categories: Development

Ticket #12148 (64 bit boot intermittently hangs on rocket icon) closed

Tue, 2015-08-18 20:37

There's a newer issue that has more info than this one, closing as duplicate.

Categories: Development

Ticket #12314 ([Installer] Text is cut off) closed

Tue, 2015-08-18 14:42
Categories: Development

Ticket #12315 (Hiding volume control crashes Deskbar) created

Tue, 2015-08-18 14:11

Uncheck Show volume control on Deskbar:

Deskbar now crashes, see attached report.

Categories: Development

Ticket #12313 (Black screen with 6470M) created

Mon, 2015-08-17 20:51

Haiku revision - 49554.
I'm getting black screen after boot when using radeon_hd with my 6470M/6520G APU
Syslog is attached

Categories: Development

Ticket #11439 (KDL on first boot (hrev48257 x86_gcc2)) closed

Mon, 2015-08-17 14:57

Thanks for reporting!

Categories: Development

Ticket #12312 ([app_server] sometimes doesn't redraw modal windows) created

Mon, 2015-08-17 13:27


  • Install quicklaunch-0.9.11-1-x86_gcc2.hpkg which has ​this change.
  • Launch it
  • Click Setup and Add..
  • Close Setup window and then file panel
  • Click Setup and Add..

Setup window will not be drawn properly.

Categories: Development