Re: lug-bg: libgtk2.0-bin.deb undefined symbol

[peyo <peyo@xxxxxxxxx>]

On Thursday 30 September 2004 14:19, George Danchev wrote:
> On Thursday 30 September 2004 12:44, peyo wrote:
> --cut--
>
> > Нека обобщя:
> >
> > - Обвиняемите библиотеки са читави(?) или поне са това, което трябва да
> > е. (debsum, md5sum)
> >
> > - Указателят за местонахождението на динамичните библиотеки е правилен
> > - Няма счупени зависимости и/или грешки по glibc
> > - Обекта gdk_threads_lock си съществува и е описан (очевидно)
> > - Няма указания за предварително зареждане (ld.so.preload)
> > - и в _двата_ случая линкера си намира библиотеката
> > ----
>
> Хубаво, че тези изключихме ;-)

 не е много, но пак е нещо:)

>
> > - По неясни причини в лошият случай обърни внимание:
> >
> > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> > 0) = 0x407d0000
> > забелязвам смяна на режима на достъп към read/write
> >  --> mprotect(0x402fe000, 376832, PROT_READ|PROT_WRITE) = 0
> > и тук веднага(без междувременно да се случва нещо там) смяна към
> > read/exec --> mprotect(0x402fe000, 376832, PROT_READ|PROT_EXEC) = 0
>
> интересно от къде се появи пък mprotect(), тогава PROT_WRITE става успешно
> PROT_EXEC (връща 0), като оставя тази памет вече като не-readable и
> не-writeable, а само изпълнима ;-/

Те за т'ва и а говоря:(
(ама според мен става read/exec)

>
> > writev(2, [{"gtk-query-immodules-2.0", 23}, {": ", 2}, {"relocation
> > error", 16}, {": ", 2}, {"/usr/lib/libgtk-x11-2.0.so.0", 28}, {": ", 2},
> > {"undefined symbol: gdk_threads_lo"..., 34}, {"", 0}, {"", 0}, {"\n",
> > 1}], 10) = 108 exit_group(127)                         = ?
>
>  и тук пък writev()...
>
> Може ли да ни кажеш какъв кернел ползваш, версия, секюрити опции нещо ?

2.4.26 - 6 кхм...с дебиански кръпки
и никакви секюрити опции. Каквото и да значи това:)

>
> > Последните три реда ги няма в читавото изпълнение, което означава, че
> > между "мапването " и "ънмапването"(което го има в нормалното изпълнение)
> > се случва нещо, което предизвиква последователна смяна на режима на
> > достъп(което пък въобще го няма в нормалното изпълнение)
> >
> > Което пък ме кара да се обърна към gdb да видя ако мога какво става
> > междувременно.
>
> а какво откриваш ?

Че debug за ДОС беше чудна и нещата тогава бяха по-прости:)
Шегичка ей! Да не ме заплюете сега:) 

Открих, че е компилирано(gtk-immodules....) без дебъг символи и ще трябва да 
отделя повече свободно време за да се занимая с това. 

Все пак се надявам (искрено) да изскочи по-човешко решение. 

Така и така се заговорихме за gdb...  понеже не съм много наясно с 
"фийчърсите" му, мога ли с него да деасемблирам?
Че търсих, ама не намерих:( 

Много ми се иска да видя кое е това с mprotect-ите и какава ли чудна мазаница 
го предизвиква?

Хммм.... възможно ли е, нещо някъде да използва  памет и да е пропуснало да си 
признае, че я използва? Как мислиш? 



-- 
---
"Времето е еднопосочно. 
Няма начин да се върнеш назад,
за да си допиеш."
***
Ако не отговарям на писмата Ви - погледнете тук: http://6lyokavitza.org/mail
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================