[linux] 5.x: userland writes to /usr/lib64/firefox/libxul.so

[Geert Stappers]

On Fri, Apr 24, 2020 at 11:57:18AM +0200, Udo van den Heuvel wrote:
> On 24-04-2020 08:11, Sihtp wrote:
> >>> hebben geen last.
> >>> (kernel bouwen, skype, transmission, etc)
> >>
> >> Boeit niet, zulke (hardware) storingen kunnen hele specifieke oorzaken
> >> hebben. 
> 
> Die de specifieke problemen niet zomaar verklaren.
> 
> >>Denk aan al die problemen met rowhammer enz., daar merk je
> >> normaal gesproken ook niks van.
> 
> Waarom zou een gare CPU (met on-die memorycontroller) of gare DIMM dan
> de specifieke paketten keer op keer laten crashen? Door alle security
> heen op disk laten schrijven als user?
> En niet de overige software?
> 
> >> Probeer het gewoon.
> > 
> > En hoe ging het?
> 
> Vandaag 5.6.7 geboot.
> Komende week meer tijd om te bekijken, evenals memtest86+.


Laat a.u.b. weten hoe het gaat.  Je mag natuurlijk ookal nu vertellen
hoe oud de computer in kwestie is.  En of het dezelfde computer is waar
je eind vorig jaar vage klachten had.

Eerder schreef ik in deze thread "het verschil is telkens 40". Ik had
toen niet gezegd dat het octaal 40 is. En binair is dat  100000.

Zojuist eindelijk naar de afstand in de locatie gekeken. 
<screenshot>
stappers op trancilo:~/src/memdist
$ ./memdist 27453361 71229873 71562161 72162737
0x29bfa00
0x51200
0x92a00
stappers op trancilo:~/src/memdist
$ ./memdist 12417457 76546993 85652401 98344369
0x3d28a00
0x8af000
0xc1aa00
stappers op trancilo:~/src/memdist
$ 
</screenshot>

Niet bepaalt een bevesting van mijn vermoeden van telkens
dezelfde onderlinge afstand tot een rotte geheugenlocatie.

Maar tegen de overlap in eindcijfers kijk ik nog raar aan.


Groeten
Geert Stappers
-- 
#!/usr/bin/env python3
import sys


def distance(l):
    i = 0  # starting up
    for _ in l:
        if i == 0:
            i += 1  # we are started
            continue
        print(hex (int(l[i]) - int(l[i-1]) ))
        i += 1
    return

               
distance(sys.argv[1:])
# l l