After several hours of usage, suddenly, text files suffer data corruption (plain text is replaced with strange characters).

[Giova84]

I am on hrev50141 and I still notice this behaviour, which, for me, is present since years on Haiku. I noticed that this corruption of text files, for me, easily occurs after several hours of usage. In these days - as usual, periodically - I'm using Haiku as my main OS: after an intensive usage (eg I download, copy, move and delete a lot of files on the disk), suddenly, I notice that some text files (also a bash script) are corrupted: this happens suddenly. Eg: this morning i have executed a bash script and I opened a text file, I closed it and open again (the plain text file): then some portion of the text was replaced with strange/ASCII characters. The fact is that such text file has never been edited since weeks: I just opened it in StyledEdit (the content was OK), closed and opened again, then the corruption occured. I didn't noticed any other issue (and the modification time of the file, after the corruption - strange characters instead of plain text - hasn't been touched). I also executed a bash script - all was fine - then I executed this script again and didn't worked: then I opened this script file with Pe and an alert window of Pe told me about encoding/UTF problems: in fact a portion of text of this script was replaced with strange characters. I run a checkfs on the disk, but no errors were found.

Unfortunately, due these tickets ticket:12634 and ticket:12415 I can't investigate in the syslog.

[ttcoder]

StyledEdit uh... My finding in #10765 is that the problem completely goes away if I use something else (Pe) and blacklist StyledEdit. Pe does not reproduce the bug for me, unlike using both Pe and StyledEdit combined.

EDIT: removed checkfs and syslog mentions, I should read more carefully before I hit submit *g*

[Giova84]

Replying to ttcoder:

StyledEdit uh... My finding in #10765 is that the problem completely goes away if I use something else (Pe) and blacklist StyledEdit. Pe does not reproduce the bug for me.

Hi, differently from #10765, I found data corruption also with bash scripts files: one of my bash script file was corrupted after the execution (I didn't opened the script file with StyledEdit). Few minutes ago I also noticed that a cookie file was also corrupted, I can affirm this because I lost the preference of a website).

What does checkfs report ?

checkfs doesn't report anything:

checkfs /boot
        6528 nodes checked,
        0 blocks not allocated,
        0 blocks already set,
        0 blocks could be freed

        files           5014
        directories     502
        attributes      611
        attr. dirs      374
        indices         27

        direct block runs               6276 (1.00 GiB)
        indirect block runs             93 (in 10 array blocks, 88.84 MiB)
        double indirect block runs      0 (in 0 array blocks, 0 bytes)

Kind regards.

[Giova84]

Replying to ttcoder:

EDIT: removed checkfs and syslog mentions, I should read more carefully before I hit submit *g*

Don't you worry :-)

However: I just uninstalled my optical drive and I disabled its relative SATA port from the BIOS, so, now, I have a clean syslog (I wil attach the syslog after this comment: tell me if you see something of suspect.)

[ttcoder]

No interesting bfs errors in there, it seems; would be interesting to see a syslog captured right after the error occurs I guess. Noted on StyledEdit not being involved for the corrupted file; sounds like this differs from the bug I had observed, where saving a text file in StyledEdit had corrupted both the text file and also an App.cpp file that was never opened in StyledEdit.

[mmlr]

In such cases it is always interesting to figure out where the corruption is actually happening as there are numerous layers involved. Here's a couple of things you could try to narrow things down:

• Open the corrupted file with DiskProbe and look at where the corruption starts/ends. Does it span the whole file or does it start/stop at a certain boundary? Does the offset of that start/end align with a power of 2 (i.e. is it a multiple of 2048, 4096 or similar)? -> The offsets might give a hint at whether it is cache corruption and which cache is possibly affected.
• Is there a pattern in the corruption or does it look completely random? Can you see readable text? -> The structure of the corruption might point to a certain driver/component that may be overwriting memory.
• Does the corruption persist across a reboot? -> This will show whether or not the data on the file system actually got corrupted or if it was one of the cache layers getting corrupted transiently.

[Giova84]

Replying to mmlr:

In such cases it is always interesting to figure out where the corruption is actually happening as there are numerous layers involved. Here's a couple of things you could try to narrow things down

Unfortunately (but fortunately for my computer ) I immediately recovered my files from the weekly backup, after the corruption. So for now I can't do a detailed inspection and I don't have a specific syslog. But I remember some details, however:

Point 2: The corruption seemed patterned on both files (the bash script and the plain text file); in both files there was just a portion of corruption, represented by strange/ASCII characters; since the corruption was partial inside these files, there was still readable text (and I remember, especially in the bash script), that the corruption was present in a certain portion of the script: it affected a portion which is repeated various times in this bash script: but just one of these portions has been corrupted).

Point 3: The corruption of such files persisted after a reboot.

However you mention, maybe, something of interesting: a driver/component that may be overwriting memory.

When the corruption has occured, I was playing with a driver: the modified HDA driver which Pete Goodeve sent me about two years ago: its modified driver is provided with a setting file (hda.settings) which allows to set the buffer size to reduce the audio latency: when I change the value in the hda.settings file, I also restart the media_server: I often play with this setting, but this was the first time that I noticed the data corruption (to make a test I also attempted to change continuosly the setting file, various time, one hour ago: but I didn't noticed again the data corruption).

However, to exclude the possibility mentioned by ttcoder, I blacklisted StyledEdit.

I will keep you updated with more infos if/when a corruption will occur again.

[axeld]

I just had a similar issue: I changed the DriveEncryption driver to dump more data to the syslog. While it was busy mounting BFS (which took a while, since it scans the complete bitmap on startup once), I installed some software package, and ended up with an activated-packages file of the correct length (according to those found in older states), but with part of the contents of the syslog file I tailed into a Terminal.

Since the file system was not corrupted, this means it's very likely that the file cache mixed up its pages somehow.

[waddlesplash]

Would that be a file_cache problem or a PageWriteWrapper problem, though?

[axeld]

That's actually not quite clear, indeed. It could also mix up the owner of the pages.

[waddlesplash]

I just added some other tickets probably related to this one as blocking this. Note that at least one of them has a bunch of additional information which may provide more clues.