Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1369 closed bug (fixed)

Haiku corrupts vlc binary

Reported by: kaoutsis Owned by: axeld
Priority: critical Milestone: R1
Component: System/Kernel Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

  • run haiku (tested with real hardware, hrev21848)
  • unzip from haiku the vlc zip package:

unzip vlc-0.8.6c-BeOS.zip

  • cd vlc-0.8.6c
  • ./vlc

works amazingly well listen a internet radio station, or watch a internet tv station.

  • close the app
  • reboot
  • after reboot rerun the vlc binary

you should get: sh: ./vlc: cannot execute binary file

*finally i mounted the haiku partition and try to run the binary from hrev5: the same result sh: ./vlc: cannot execute binary file

Change History (11)

comment:1 by axeld, 12 years ago

Component: - GeneralSystem/Kernel

Just curious about "reboot" - are you shutting down Haiku correctly? Because only then the caches are written back.

in reply to:  1 comment:2 by kaoutsis, 12 years ago

Replying to axeld:

Just curious about "reboot" - are you shutting down Haiku correctly? Because only then the caches are written back.

Yes. i am shutting down haiku correctly; After all that is the point:)

in reply to:  description ; comment:3 by aldeck, 12 years ago

Replying to kaoutsis: I may be wrong but i always run 'sync' after any file op, if i were you i would do a sync after unziping :)

comment:4 by stippi, 12 years ago

It's still a bug though if multiple file ops and a sync produces different results than a sync after each op. I have seen this bug too I think. We hoped that it would have disappeared with all the file cache and vm fixes recently.

in reply to:  3 comment:5 by kaoutsis, 12 years ago

Replying to aldeck:

Replying to kaoutsis: I may be wrong but i always run 'sync' after any file op, if i were you i would do a sync after unziping :)

followed your suggestion: i ran sync after unzipping; then the vlc runs fine and reruns fine after reboot. The strange thing for me is that if i run sync not immediately after unzipping, but i run vlc first, close the app and then run sync and reboot, the problem appears again.

comment:6 by tangobravo, 12 years ago

I've noticed it too - and it seems from 1399 it applies generally to all executables.

<wild speculation>Does something in the first-execute code path assume the file is actually on the disk instead of just in the cache?</wild speculation>

comment:7 by bbjimmy, 12 years ago

The new file is corrupted if it is executed before a Restart. If it is not executed until after a Restart the file is not corrupted and can be executed any number of times.

( simple quick test ... http://216.110.210.251/fatelk/TextSaver.zip unzip copy TextSaver /boot/home/config/add-ons/Screen Savers/ execute the screensaver THEN reboot.

now the TextSaver file in /boot/home/config/add-ons/Screen Savers/ does not match the file in the TextSaver folder.

re-copy the file and Restart THEN execute the file ... now the system can re-boot and the file is not corrupted.

NOTE: the corruption is not limited to screensavers, this is just a quick test case)

looks like something with a combination of copying the file and then executing it.

comment:8 by axeld, 12 years ago

Priority: normalcritical
Status: newassigned

I've found the problem: when executing the application, some pages are moved from the modified list to the active list - therefore, when the cache is written back, those pages are simply not written. On next boot, those pages are just empty (or just contain garbage, since BFS currently does not clear unused space).

comment:9 by axeld, 12 years ago

Resolution: fixed
Status: assignedclosed

Fixed in hrev21971.

in reply to:  9 comment:10 by kaoutsis, 12 years ago

Replying to axeld:

Fixed in hrev21971.

thanks!

comment:11 by stippi, 12 years ago

Wow, whenever I think, "dude, that's gonna be a tough one", here come Axel or Ingo with a fix already! Great that this one got nailed! It was causing me quite a feeling of uncertainty... :-)

Note: See TracTickets for help on using tickets.