Need to recompile application after every reboot for it to run

[smallstepforman]

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.

[miqlas]

This error comes from runtime_loader, see here: ​https://github.com/haiku/haiku/blob/b65adbdfbc322bb7d86d74049389c688e9962f15/src/system/runtime_loader/elf_versioning.cpp#L86

No idea, what's going on hovewer.

[pulkomandy]

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.

[smallstepforman]

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

[smallstepforman]

vm_page_fault screenshot

[smallstepforman]

vm_page_fault

[smallstepforman]

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.

[smallstepforman]

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.

[korli]

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

[smallstepforman]

Seems to be fixed in hrev51692, possibly due to commit from Augustin Cavalier <waddlesplash@…> (​https://cgit.haiku-os.org/haiku/commit/?id=019828aba71a25f9f952bc6fd51b57c77be1f8a2). Thanks Augustin.

Safe to close (korli?)

[waddlesplash]

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.

[smallstepforman]

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