auctex
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AUCTeX] Update: Text corruption


From: Tassilo Horn
Subject: Re: [AUCTeX] Update: Text corruption
Date: Tue, 22 Jan 2013 11:03:08 +0100
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux)

"Axel E. Retif" <address@hidden> writes:

Hi Axel,

[sorry for the duplicate; previously I've replied to you privately.]

>>> Curiously enough, sometimes Meld have shown some text corruption,
>>> but reopening the same diff documents with Meld makes the
>>> ``corruption'' disappear (and checking with Emacs, TeXworks and Kate
>>> show that indeed there wasn't any corruption).
>>
>> Did that happen with the new memory modules, i.e., is the issue still
>> there, or has it been solved with the new modules?
>
> With the new memory modules, but it has been different. I has happened
> twice exactly:
>
> The first, instead of the word ``según'' Meld showed in the new
> version of the file something like ``segÃn'',

Hm, assuming UTF-8 and again the bit-2-flip, it would be:

ú = 11111010
þ = 11111110

Maybe Meld prints à in case the font doesn't have a glyph for the
character to display?

> as if it was mistaken the encoding for that word along, but closing
> Meld and, without doing anything else, choosing again "External
> editor" from the gitk interface, didn't show the error again. Anyway,
> I also checked with Emacs, TeXworks and Kate and there wasn't such
> corruption.

I think the diff is recalculated and loaded into memory again.  If you
hadn't switched your memory modules, I would have guessed that when
reloading the diff or file, chances are high that it ends up in a
non-broken part of memory and thus the corruption is gone.  In any case,
the contents on the disk seem to be correct, else a recalculation of a
git diff or reopening a file wouldn't revert the corruption.

So that leaves two possibilities:

 1. The new RAM is broken in exactly the same way as the old (very
    unlikely)
 2. Something else is broken

Since the disk contents are probably correct, the "something else" has
to be somewhere between disk and memory.  Maybe your disk's I/O
controller goes wonky, or your PCI controller, or whatnot.

To rule out your disk's I/O controller, you could move your document git
repositories from your main disk to some other disk (e.g., to an
external disk connected via USB).  If the issue disappears, then you
gotta buy a new disk.  If not, then I'm running out of ideas.

> The second, it showed a $ instead of a space.

Same pattern again:

SPACE = 100000
$     = 100100

Bye,
Tassilo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]