Opened 2 years ago

Closed 22 months ago

Last modified 22 months ago

#13773 closed bug (fixed)

Need to recompile application after every reboot for it to run

Reported by: smallstepforman Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Drivers/USB/XHCI Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: yes Platform: x86-64


I have a custom application (Haikux64, OpenGL, Boost, yasm, OpenAL) which after every reboot wont run due to the following error:

runtime_loader: /boot/home/development_006046001/Build/Haiku/prototype: Unsupported version needed revision: 49860 runtime_loader: Cannot open file HT$dE$`$H|$HD$ D A]: No such file or directory

If I clean and rebuild the software, it works fine until the very next reboot.

hrev51541, updated with SoftwareUpdater daily. hrev49860 sounds like the version I originally installed on the USB memory stick, and I've since updated it to 51541.

Attachments (2)

IMG_5615.JPG (1.2 MB ) - added by smallstepforman 23 months ago.
vm_page_fault screenshot
IMG_5616.JPG (1.0 MB ) - added by smallstepforman 23 months ago.

Change History (14)

comment:2 by pulkomandy, 2 years ago

It sounds like your application is somehow managing to corrupt its own executable?

Easy to check: run an md5sum on the exe, run the exe, run an md5sum again. If the checksum is changed, it means the app is trying to modify itself.

If that's indeed what happens, keep a "safe" copy of the exe somewhere and use some tool to compare the binaries before/after, to see what gets written into it. Maybe we can find out which kind of things got written there.

comment:3 by smallstepforman, 2 years ago

PulkoMandy, I'm away on business for the next 7 days, so I wont be able to confirm this until next Thursday. Thanks.

by smallstepforman, 23 months ago

Attachment: IMG_5615.JPG added

vm_page_fault screenshot

comment:4 by smallstepforman, 23 months ago

Has a Patch: set

by smallstepforman, 23 months ago

Attachment: IMG_5616.JPG added


comment:5 by smallstepforman, 23 months ago

PulkoMandy, the md5sum does not change after program execution/reboot. Here is my latest experience with hrev51638 (29 Nov 2017).

Compile the x86_64 application from scratch. Application runs successfully. Reboot. The md5sum has not changed, however a cold run causes a vm_page_fault (see screenshot IMG5615.jpg), stack_trace_trampoline. Reboot and run the application again through the Debugger - also a vm_page_fault (IMG5616.jpg). Reboot and recompile, same md5sum and the application runs successfully. The app on startup needs to load over 1Gb of graphics resources into memory.

Note: I run Haiku via USB3 <XHCI> port, a USB2 hard disk. I am experiencing daily USB glitches (eg. trackpad stops working, keyboard get key repeat stuck, mouse loses connection, hard disk access no longer works, etc). When I attempt "git pull", a get a KDL after 30 seconds (lots of disk IO). This bug may be related to USB glitches. When I recompile from scratch, its as if the memory buffers are warmed up, so subsequent application runs work fine. Cold memory buffers crash the application. Weird.

comment:6 by smallstepforman, 23 months ago

An interesting observation with image IMG_5616.JPG. The Bash directory was initially ~/development_001029001/Build/Haiku, and after the crash, ls showed the current directory as /, and a subsequent KDL. The bug looks like pointer memory stomping in the USB XHCI driver (which would explain all the USB glitches I'm seeing) under heavy load.

comment:7 by korli, 23 months ago

Component: System/runtime_loaderDrivers/USB/XHCI
Keywords: runtime_loader link removed

comment:8 by korli, 23 months ago

It's a known problem indeed, in the mean time you can compile on a USB2 port or intern (AHCI) connected hard disk.

comment:9 by smallstepforman, 22 months ago

Sorry for noise - was trying to close another issue, but accidently added comment here. Moving on ...

Last edited 22 months ago by smallstepforman (previous) (diff)

comment:10 by waddlesplash, 22 months ago

Resolution: fixed
Status: newclosed

comment:11 by waddlesplash, 22 months ago

I actually made a change to that fix just now; so if the problem *absolutely* does not occur in the hrev you are on now, but it *does* recur on the next hrev(s), please let me know immediately.

comment:12 by smallstepforman, 22 months ago

Issues with XHCI (USB3) disk access still exist in hrev51700. The system exhibits delayed responses, then eventually KDL's (stack_trace_trampoline).

Note: See TracTickets for help on using tickets.