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