mozilla se po upg nespouští

[Miroslav Benes]

>>open("/usr/lib/mozilla-1.7.12/plugins/flashplayer.xpt", 
>>O_RDONLY|O_LARGEFILE) = 4
>>
>
>Ja Vam verim... A nebylo tam aspon v mezitim nejake fcntl(), co by
>ten O_NONBLOCK nastavilo? I tak by to bylo neobvykle, ale uz aspon
>opodstatnene. Vracet EAGAIN (tedy spis EWOULDBLOCK, ale na Linuxu je to
>totez) bez O_NONBLOCK je dost divne, skoro az chybne.
>
Ono je to trošku jinak, jak jsem zjistil při podrobnějším zkoumání. 
Hledal jsem totiž soubor, který se otvírá pro fd 4 -> tedy poslední 
operaci open() s výsledkem 4. Jenže ono je to včechno trochu zamotanější :

...
stat64("/usr/lib/mozilla-1.7.12/plugins/flashplayer.xpt", 
{st_mode=S_IFREG|0755, st_size=856, ...}) = 0
open("/usr/lib/mozilla-1.7.12/plugins/flashplayer.xpt", 
O_RDONLY|O_LARGEFILE) = 4
read(4, "XPCOM\nTypeLib\r\n\32\1\2\0\3\0\0\3X\0\0\0\"\0\0\0u"..., 856) = 856
close(4)                                = 0
open("/usr/lib/mozilla-1.7.12/components/xpti.dat.tmp", 
O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EACCES (Permission
denied)
brk(0x8629000)                          = 0x8629000
access("/usr/lib/mozilla-1.7.12/xpicleanup.dat", F_OK) = -1 ENOENT (No 
such file or directory)
pipe([4, 5])                            = 0
fcntl64(4, F_GETFL)                     = 0 (flags O_RDONLY)
fcntl64(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
fcntl64(5, F_GETFL)                     = 0x1 (flags O_WRONLY)
fcntl64(5, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
... (zde se s deskriptory 4 a 5 nepracuje) ...
futex(0xb7d7abf8, FUTEX_WAIT, 14662, NULL) = 0
read(4, 0xbfbd0693, 1)                  = -1 EAGAIN (Resource 
temporarily unavailable)
unlink("/home/benesm/.mozilla/default/o5t48xbu.slt/lock") = 0
close(4)                                = 0
close(5)                                = 0

Takže na fd 4 a 5 je nějaká roura "odnikud 
nikam".stat64("/usr/lib/mozilla-1.7.12/plugins/flashplayer.xpt", 
{st_mode=S_IFREG|0755, st_size=856, ...}) = 0


>>Takže se ověřuje, že na nějaké adrese (0xb7d7abf8) je hodnota (14662). 
>>Ale proč ?!?
>>
>
>Kdyz tak na to koukam, tak neobvykla je nejen ta hodnota, ale i ta
>adresa, ktera je nekde strasne vysoko. V zasobniku to asi nebude (tedy 
>jestli nemate nejakou randomizaci adresoveho prostoru), ale mohlo by to 
>byt v nejake sdilene knihovne, ktere se podle noveho svetoveho poradku 
>strkaji nekam k vrcholu adresoveho prostoru. Pokud to je skutecne nejaka 
>sdilena knihovna a mate jeste ten vystup z strace, tak by z toho melo jit 
>zjistit, ktera to byla.
>
Našel jsem toto :

clone(child_stack=0xb7d7a4c4, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLON
E_PARENT_SETTID|CLONE_CHILD_CLEARTID|CLONE_DETACHED, 
parent_tidptr=0xb7d7abf8, {entry_number:6, base_addr:0xb7d7abb0, limit:
1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, 
seg_not_present:0, useable:1}, child_tidptr=0xb7d7abf8
) = 14662
sched_setscheduler(14662, SCHED_OTHER, { 0 }) = 0

Takže 14662 je počet bytů, který se _odněkud_ _někam_ kopíruje (?).

Jak se dá zjistit, která knihovna do toho "problematického" prostoru 
sahala ? Většinou je po příkazu open na knihovnu něco jako :

open("/usr/lib/mozilla-1.7.12/components/libembedcomponents.so", 
O_RDONLY) = 6
read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\310R\0"..., 
512) = 512
fstat64(6, {st_mode=S_IFREG|0755, st_size=168804, ...}) = 0
old_mmap(NULL, 167568, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 
6, 0) = 0x205000
old_mmap(0x22c000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x27000) = 0x22c000
close(6)     

Takže spíš nízké adresy.

Na takhle vysokou adresu ještě sahají příkazy :
open("/usr/share/locale/cs/LC_MESSAGES/libc.mo", O_RDONLY) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=86276, ...}) = 0
mmap2(NULL, 86276, PROT_READ, MAP_PRIVATE, 6, 0) = 0xb7d7b000
close(6)                                = 0

To je ale pod adresou 0xb7d7abf8, na kterou "sahá" futex.


>>BTW pomohla "reinstalace" jazykového balíčku s češtinou (viz jiné 
>>příspěvky v tomto vlákně).
>>
>
>To jsem si vsimnul a je to dost zvlastni. Te reinstalace to mozna
>nejak reorganizovala, takze se uz ty operace, co delaly problem driv, 
>neprovadeji.
>
Možná. Proto bych tomu rád přišel na kloub. Ale nemám k tomu dost 
znalostí a zkušeností, takže musím prudit tady :-\

Děkuji za ochotu a doufám, že se nakonec k něčemu dobereme.