En/na Wolfgang Sourdeau ha escrit:
It's very difficult to determine what causes your problem here...
Because we don't know which methods are executed at the listed
locations. You could send us the result of "objdump -t
/usr/lib/libNGCards.so" and hopefully we will find some information there.
Before I spam the list with the output of objdump, I'd like to know how
to map the addresses, i.e., the stack trace is like this:
/usr/lib/libNGCards.so.4.9[0xb758b754]
/usr/lib/libNGCards.so.4.9[0xb757f2d0]
/usr/lib/libNGCards.so.4.9[0xb758730c]
/usr/lib/libNGCards.so.4.9[0xb7582626]
/usr/lib/libNGCards.so.4.9[0xb7582ba2]
later there's a memory map in the log:
b7562000-b7593000 r-xp 00000000 08:01 209310
/usr/lib/libNGCards.so.4.9.0
b7593000-b75a2000 rw-p 00031000 08:01 209310
/usr/lib/libNGCards.so.4.9.0
Do I just subtract, say 0xb7562000 (the address in the memory map) from
0xb758b754 (the address in the backtrace) to get the address in objdump?
That's 0x29754, and I see no matching (or higher) address in the output
of objdump -t, the highest text address I find is this:
00026650 l F .text 00000000 __do_global_ctors_aux
Also, make sure you are using the last version of the sope-gsmake2.diff
and sope-patchset-r1664.diff patches when building your RPMS.
I took those from the 1.2.2 tarball.
Bye
--
Luca Olivetti
Wetron Automatización S.A. http://www.wetron.es/
Tel. +34 93 5883004 (Ext.133) Fax +34 93 5883007
--
users@sogo.nu
https://inverse.ca/sogo/lists
