mozilla se po upg nespouští

Pavel Kankovsky peak na argo.troja.mff.cuni.cz
Pátek Únor 24 00:45:17 CET 2006


On Sun, 19 Feb 2006, Miroslav Benes wrote:

> 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)
[...]
> Takže na fd 4 a 5 je nějaká roura "odnikud nikam".

Takze to uz dava smysl. Mozna ji to pouziva na nejakou synchronizaci ci
komunikaci v ramci jednoho procesu mezi thready. A mozna to byl nakonec 
red herring. Nebo taky ne, ale to uz se asi tezko zjisti.

> >>Takže se ověřuje, že na nějaké adrese (0xb7d7abf8) je hodnota (14662). 
> > 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 (?).

Ne. 14662 je tid (thread id). A 0xb7d7abf8 je adresa, kde je to ulozene.
(Trochu mne mate, ze parent_tidptr a child_tidptr je totez, ale asi je to 
tak dobre.)

> 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 :

Presne tak, prostor, kde je umistena dynamicka knihovna, se pozna z tech
kombinaci open() a mmap(). V nasem pripade to nebyla knihovna (vy mate asi
ExecShield, nebo jak se to jmenuje, ze to strka knihovny takhle nizko,
co?). Z vyse uvedeneho vyplyva, ze to byl zasobnik nejakeho nove
vytvareneho threadu.

> 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
> To je ale pod adresou 0xb7d7abf8, na kterou "sahá" futex.

Nad? Spis pod. 0xb7d7b000 > 0xb7d7abf8. Aspon u nas doma. :)


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."



Další informace o konferenci Linux