Core dump in resolve_rels()

I am trying to get Qt 3.1.0 up and running fully under QNX 6.2, and I have
run into a problem, which seems to have been posted on before. The problem
seems to be if you try to do a dlopen() from a shared library that it will
dump core in resolve_rels().

Following posting seem to address same issue, but there was never any
solution posted:

http://groups.google.com/groups?q=core+dump+resolve_rels+group:qdn.public.qn
xrtp.os&hl=en&lr=lang_en&ie=UTF-8&oe=UTF-8&safe=off&selm=9c76o9%244be%242%40
nntp.qnx.com&rnum=1


The gdb bt gives following:

#0 0xb032bd7b in resolve_rels () from /x86/lib/libc.so.2
(gdb) bt
#0 0xb032bd7b in resolve_rels () from /x86/lib/libc.so.2
#1 0xb032becb in resolve () from /x86/lib/libc.so.2
#2 0xb032b917 in dlopen () from /x86/lib/libc.so.2
#3 0xb87cb993 in QLibraryPrivate::loadLibrary () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#4 0xb87e8fb4 in QLibrary::load () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#5 0xb87d0f42 in QComLibrary::createInstanceInternal ()
from /root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#6 0xb87d168a in QComLibrary::qtVersion () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#7 0xb87e69cf in QGPluginManager::featureList () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#8 0x0809a7ca in MainWindow::setupPluginManagers ()
#9 0x080836c6 in MainWindow::MainWindow ()
#10 0x080828ce in main ()


QNX version is 6.2.0
Qt. version 3.1.0/X11-free

Colin - any idea?

Thanks
Jens

This is interesting - after compiling and linking with CC instead of g++ (so
basically it now uses libcpp.so instead of libc++.so) the problem seems to
have gone away.

Any takers - Colin, you are normally the expert on these things,

Thanks
Jens


“Jens H Jorgensen” <jhj@remove-nospam-videk.com> wrote in message
news:atarpt$flt$1@inn.qnx.com

I am trying to get Qt 3.1.0 up and running fully under QNX 6.2, and I have
run into a problem, which seems to have been posted on before. The problem
seems to be if you try to do a dlopen() from a shared library that it will
dump core in resolve_rels().

Following posting seem to address same issue, but there was never any
solution posted:


http://groups.google.com/groups?q=core+dump+resolve_rels+group:qdn.public.qn

xrtp.os&hl=en&lr=lang_en&ie=UTF-8&oe=UTF-8&safe=off&selm=9c76o9%244be%242%40
nntp.qnx.com&rnum=1


The gdb bt gives following:

#0 0xb032bd7b in resolve_rels () from /x86/lib/libc.so.2
(gdb) bt
#0 0xb032bd7b in resolve_rels () from /x86/lib/libc.so.2
#1 0xb032becb in resolve () from /x86/lib/libc.so.2
#2 0xb032b917 in dlopen () from /x86/lib/libc.so.2
#3 0xb87cb993 in QLibraryPrivate::loadLibrary () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#4 0xb87e8fb4 in QLibrary::load () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#5 0xb87d0f42 in QComLibrary::createInstanceInternal ()
from /root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#6 0xb87d168a in QComLibrary::qtVersion () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#7 0xb87e69cf in QGPluginManager::featureList () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#8 0x0809a7ca in MainWindow::setupPluginManagers ()
#9 0x080836c6 in MainWindow::MainWindow ()
#10 0x080828ce in main ()


QNX version is 6.2.0
Qt. version 3.1.0/X11-free

Colin - any idea?

Thanks
Jens

My mistake - it also occurs when using cc and CC (libcpp.so). What happend
was that some of the shared libraries were still compiled with g++ and they
were not being loaded because the application discovered that they were not
compiled with the same profile as the main shared library, and therefore
they were not being loaded.

So we are back to the fact that dlopen() will cause a core dump (SEGV) if
called from a shared library.


Jens


“Jens H Jorgensen” <jhj@remove-nospam-videk.com> wrote in message
news:atd1uj$t90$1@inn.qnx.com

This is interesting - after compiling and linking with CC instead of g++
(so
basically it now uses libcpp.so instead of libc++.so) the problem seems to
have gone away.

Any takers - Colin, you are normally the expert on these things,

Thanks
Jens


“Jens H Jorgensen” <> jhj@remove-nospam-videk.com> > wrote in message
news:atarpt$flt$> 1@inn.qnx.com> …
I am trying to get Qt 3.1.0 up and running fully under QNX 6.2, and I
have
run into a problem, which seems to have been posted on before. The
problem
seems to be if you try to do a dlopen() from a shared library that it
will
dump core in resolve_rels().

Following posting seem to address same issue, but there was never any
solution posted:



http://groups.google.com/groups?q=core+dump+resolve_rels+group:qdn.public.qn


xrtp.os&hl=en&lr=lang_en&ie=UTF-8&oe=UTF-8&safe=off&selm=9c76o9%244be%242%40
nntp.qnx.com&rnum=1


The gdb bt gives following:

#0 0xb032bd7b in resolve_rels () from /x86/lib/libc.so.2
(gdb) bt
#0 0xb032bd7b in resolve_rels () from /x86/lib/libc.so.2
#1 0xb032becb in resolve () from /x86/lib/libc.so.2
#2 0xb032b917 in dlopen () from /x86/lib/libc.so.2
#3 0xb87cb993 in QLibraryPrivate::loadLibrary () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#4 0xb87e8fb4 in QLibrary::load () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#5 0xb87d0f42 in QComLibrary::createInstanceInternal ()
from /root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#6 0xb87d168a in QComLibrary::qtVersion () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#7 0xb87e69cf in QGPluginManager::featureList () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#8 0x0809a7ca in MainWindow::setupPluginManagers ()
#9 0x080836c6 in MainWindow::MainWindow ()
#10 0x080828ce in main ()


QNX version is 6.2.0
Qt. version 3.1.0/X11-free

Colin - any idea?

Thanks
Jens
\

So we are back to the fact that dlopen() will cause a core dump (SEGV) if
called from a shared library.

It’s more likly that there is an issue with the shared library that is
trying to be loaded from the other shared library. For instance, there
are no issues with io-blk.so dlopen()'ing fs-qnx4.so.

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

I believe it may be caused by a number of different problems. I ran into
this because one of my static data structures was declared as const. Try to
check
section headers in your dll for “rel.rodata” and “rel.text”.

objdump -h

Sincerely,

Serge

“Jens H Jorgensen” <jhj@remove-nospam-videk.com> wrote in message
news:atarpt$flt$1@inn.qnx.com

I am trying to get Qt 3.1.0 up and running fully under QNX 6.2, and I have
run into a problem, which seems to have been posted on before. The problem
seems to be if you try to do a dlopen() from a shared library that it will
dump core in resolve_rels().

Following posting seem to address same issue, but there was never any
solution posted:


http://groups.google.com/groups?q=core+dump+resolve_rels+group:qdn.public.qn

xrtp.os&hl=en&lr=lang_en&ie=UTF-8&oe=UTF-8&safe=off&selm=9c76o9%244be%242%40
nntp.qnx.com&rnum=1


The gdb bt gives following:

#0 0xb032bd7b in resolve_rels () from /x86/lib/libc.so.2
(gdb) bt
#0 0xb032bd7b in resolve_rels () from /x86/lib/libc.so.2
#1 0xb032becb in resolve () from /x86/lib/libc.so.2
#2 0xb032b917 in dlopen () from /x86/lib/libc.so.2
#3 0xb87cb993 in QLibraryPrivate::loadLibrary () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#4 0xb87e8fb4 in QLibrary::load () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#5 0xb87d0f42 in QComLibrary::createInstanceInternal ()
from /root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#6 0xb87d168a in QComLibrary::qtVersion () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#7 0xb87e69cf in QGPluginManager::featureList () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#8 0x0809a7ca in MainWindow::setupPluginManagers ()
#9 0x080836c6 in MainWindow::MainWindow ()
#10 0x080828ce in main ()


QNX version is 6.2.0
Qt. version 3.1.0/X11-free

Colin - any idea?

Thanks
Jens

Serge Yuschenko <serge.yuschenko@rogers.com> wrote in message
news:ate9cj$as3$1@inn.qnx.com

I believe it may be caused by a number of different problems. I ran into
this because one of my static data structures was declared as const. Try
to
check section headers in your dll for “rel.rodata” and “rel.text”.

objdump -h <your dll

Yeap. And then you can "objdump -d " try to match the offset
showes
in rel.text/rel.rodata, to figure with function is holding them, and then
figure out
which .c (.cpp) this function belongs to, and check if that file is compiled
with
-shared or not.

-xtang

Sincerely,

Serge

“Jens H Jorgensen” <> jhj@remove-nospam-videk.com> > wrote in message
news:atarpt$flt$> 1@inn.qnx.com> …
I am trying to get Qt 3.1.0 up and running fully under QNX 6.2, and I
have
run into a problem, which seems to have been posted on before. The
problem
seems to be if you try to do a dlopen() from a shared library that it
will
dump core in resolve_rels().

Following posting seem to address same issue, but there was never any
solution posted:



http://groups.google.com/groups?q=core+dump+resolve_rels+group:qdn.public.qn


xrtp.os&hl=en&lr=lang_en&ie=UTF-8&oe=UTF-8&safe=off&selm=9c76o9%244be%242%40
nntp.qnx.com&rnum=1


The gdb bt gives following:

#0 0xb032bd7b in resolve_rels () from /x86/lib/libc.so.2
(gdb) bt
#0 0xb032bd7b in resolve_rels () from /x86/lib/libc.so.2
#1 0xb032becb in resolve () from /x86/lib/libc.so.2
#2 0xb032b917 in dlopen () from /x86/lib/libc.so.2
#3 0xb87cb993 in QLibraryPrivate::loadLibrary () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#4 0xb87e8fb4 in QLibrary::load () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#5 0xb87d0f42 in QComLibrary::createInstanceInternal ()
from /root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#6 0xb87d168a in QComLibrary::qtVersion () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#7 0xb87e69cf in QGPluginManager::featureList () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#8 0x0809a7ca in MainWindow::setupPluginManagers ()
#9 0x080836c6 in MainWindow::MainWindow ()
#10 0x080828ce in main ()


QNX version is 6.2.0
Qt. version 3.1.0/X11-free

Colin - any idea?

Thanks
Jens
\

This is the output from objdump -h dll-file - for one of the .so which cause
a segv when being dlopen()'ed.


libcppeditor.so: file format elf32-i386

Sections:
Idx Name Size VMA LMA File off Algn
0 .hash 000041f4 000000b4 000000b4 000000b4 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .dynsym 00008760 000042a8 000042a8 000042a8 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .dynstr 00011d46 0000ca08 0000ca08 0000ca08 20
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .rel.text 0000a5e0 0001e750 0001e750 0001e750 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .rel.gcc_except_table 0000bcd0 00028d30 00028d30 00028d30 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .rel.eh_frame 000065a0 00034a00 00034a00 00034a00 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .rel.rodata 000007d0 0003afa0 0003afa0 0003afa0 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .rel.data 000047c8 0003b770 0003b770 0003b770 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .rel.ctors 00000070 0003ff38 0003ff38 0003ff38 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .rel.dtors 00000070 0003ffa8 0003ffa8 0003ffa8 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 .rel.got 00000300 00040018 00040018 00040018 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
11 .rel.plt 00002928 00040318 00040318 00040318 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .init 00000008 00042c40 00042c40 00042c40 20
CONTENTS, ALLOC, LOAD, READONLY, CODE
13 .plt 00005260 00042c48 00042c48 00042c48 2
2
CONTENTS, ALLOC, LOAD, READONLY, CODE
14 .text 00033b7c 00047ea8 00047ea8 00047ea8 22
CONTENTS, ALLOC, LOAD, READONLY, CODE
15 .fini 00000008 0007ba24 0007ba24 0007ba24 2
0
CONTENTS, ALLOC, LOAD, READONLY, CODE
16 .rodata 000043ca 0007ba40 0007ba40 0007ba40 25
CONTENTS, ALLOC, LOAD, READONLY, DATA
17 .note0 00000000 0007fe0a 0007fe0a 0007fe0a 2
0
CONTENTS, ALLOC, LOAD, READONLY, DATA
18 .data 00004708 00080e20 00080e20 0007fe20 25
CONTENTS, ALLOC, LOAD, DATA
19 .eh_frame 0001c1bc 00085528 00085528 00084528 2
2
CONTENTS, ALLOC, LOAD, DATA
20 .gcc_except_table 00005f90 000a16e4 000a16e4 000a06e4 22
CONTENTS, ALLOC, LOAD, DATA
21 .ctors 00000040 000a7674 000a7674 000a6674 2
2
CONTENTS, ALLOC, LOAD, DATA
22 .dtors 00000040 000a76b4 000a76b4 000a66b4 22
CONTENTS, ALLOC, LOAD, DATA
23 .got 00001620 000a76f4 000a76f4 000a66f4 2
2
CONTENTS, ALLOC, LOAD, DATA
24 .dynamic 000000c8 000a8d14 000a8d14 000a7d14 22
CONTENTS, ALLOC, LOAD, DATA
25 .bss 0000023c 000a8ddc 000a8ddc 000a7ddc 2
2
ALLOC
26 .comment 000005ca 00000000 00000000 000a7ddc 20
CONTENTS, READONLY
27 .note 0000030c 00000000 00000000 000a83a6 2
0
CONTENTS, READONLY


I see .rel.rodata and .rel.text - what does that mean?

Thanks
Jens



“Serge Yuschenko” <serge.yuschenko@rogers.com> wrote in message
news:ate9cj$as3$1@inn.qnx.com

I believe it may be caused by a number of different problems. I ran into
this because one of my static data structures was declared as const. Try
to
check
section headers in your dll for “rel.rodata” and “rel.text”.

objdump -h <your dll

Sincerely,

Serge

“Jens H Jorgensen” <> jhj@remove-nospam-videk.com> > wrote in message
news:atarpt$flt$> 1@inn.qnx.com> …
I am trying to get Qt 3.1.0 up and running fully under QNX 6.2, and I
have
run into a problem, which seems to have been posted on before. The
problem
seems to be if you try to do a dlopen() from a shared library that it
will
dump core in resolve_rels().

Following posting seem to address same issue, but there was never any
solution posted:



http://groups.google.com/groups?q=core+dump+resolve_rels+group:qdn.public.qn


xrtp.os&hl=en&lr=lang_en&ie=UTF-8&oe=UTF-8&safe=off&selm=9c76o9%244be%242%40
nntp.qnx.com&rnum=1


The gdb bt gives following:

#0 0xb032bd7b in resolve_rels () from /x86/lib/libc.so.2
(gdb) bt
#0 0xb032bd7b in resolve_rels () from /x86/lib/libc.so.2
#1 0xb032becb in resolve () from /x86/lib/libc.so.2
#2 0xb032b917 in dlopen () from /x86/lib/libc.so.2
#3 0xb87cb993 in QLibraryPrivate::loadLibrary () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#4 0xb87e8fb4 in QLibrary::load () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#5 0xb87d0f42 in QComLibrary::createInstanceInternal ()
from /root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#6 0xb87d168a in QComLibrary::qtVersion () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#7 0xb87e69cf in QGPluginManager::featureList () from
/root/QT/qt-x11-free-3.1.0/lib/libqt-mt.so.3
#8 0x0809a7ca in MainWindow::setupPluginManagers ()
#9 0x080836c6 in MainWindow::MainWindow ()
#10 0x080828ce in main ()


QNX version is 6.2.0
Qt. version 3.1.0/X11-free

Colin - any idea?

Thanks
Jens
\

Hi Jens,

Now you need to get rid of those sections. Unfortunately I don’t know easy
way to find out what caused their appearance. What I can offer you is kind a
roundabout way, but if you desperate you can try it. I think, before
starting doing this it would be helpful to take a look at the ELF
specification:
http://x86.ddj.com/ftp/manuals/tools/elf.pdf

Here is the step by step instruction how to figure out what causes
…rel.rodata section appearance.

  1. You already have found the section offset in your dll. According the
    listing you’ve got, it is 00003afa0. The same information you can get from
    map file.

  2. Now you need to take a look at content of this section. You can do it
    with objdump -s command. According to your listing it contains
    250 entries
    (section size: 7D0 / sizeof(Elf32_Rel)) representing Elf32_Rel structures.
    First 4 bytes of the structure is offset of the object inside your dll to be
    relocated. Let’s say you found that first 4 bytes of the section are 20 BC
    07 00.

  3. Now you need to find out what symbol inside the dll this address belongs
    to. You can get a good map of the dll with the objdump -DS . You don’t
    actually
    need all that disassembled stuff. What you really need is a symbol name
    corresponding to 0007BC20 address or “covering” this address.

  4. Let’s imagine, again, you found the address we’re looking for inside of
    <abc.25> data structure, located at 0007BC0A. You can see that the problem
    with
    the relocation was caused by some field inside of the abc structure at 0xA
    offset (0007BC20 - 0007BC0A).

It is up to you how to fix it. Most likely the place we localized is a
pointer to a function or static data structure. As I said before this sort
of problem
can happen if your abc structure is declared as const, and, I believe this
is not only reason.

If you found out that this address doesn’t belong to any of your data, but
some other library, most likely this library shouldn’t be linked with a dll.

To figure out where did the .rel.text come from take a look at the LOAD
lines in the map file. I believe those lines shouldn’t contain any static
libraries
except libgcc.a and libcS.a. Put also -v in the cc command line to make sure
that everything is compiled with the -fPIC option.

Phew…
I think it is enough for a start :slight_smile:.

Good luck,

Serge


P.S. I don’t challenge a first place in the dll troubleshooting. It would be
really interesting to see other approaches.



“Jens H Jorgensen” <jhj@remove-nospam-videk.com> wrote in message
news:atkt49$i6k$1@inn.qnx.com

This is the output from objdump -h dll-file - for one of the .so which
cause
a segv when being dlopen()'ed.


libcppeditor.so: file format elf32-i386

Sections:
Idx Name Size VMA LMA File off Algn
0 .hash 000041f4 000000b4 000000b4 000000b4 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .dynsym 00008760 000042a8 000042a8 000042a8 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .dynstr 00011d46 0000ca08 0000ca08 0000ca08 20
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .rel.text 0000a5e0 0001e750 0001e750 0001e750 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .rel.gcc_except_table 0000bcd0 00028d30 00028d30 00028d30 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .rel.eh_frame 000065a0 00034a00 00034a00 00034a00 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .rel.rodata 000007d0 0003afa0 0003afa0 0003afa0 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .rel.data 000047c8 0003b770 0003b770 0003b770 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .rel.ctors 00000070 0003ff38 0003ff38 0003ff38 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .rel.dtors 00000070 0003ffa8 0003ffa8 0003ffa8 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 .rel.got 00000300 00040018 00040018 00040018 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
11 .rel.plt 00002928 00040318 00040318 00040318 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .init 00000008 00042c40 00042c40 00042c40 20
CONTENTS, ALLOC, LOAD, READONLY, CODE
13 .plt 00005260 00042c48 00042c48 00042c48 2
2
CONTENTS, ALLOC, LOAD, READONLY, CODE
14 .text 00033b7c 00047ea8 00047ea8 00047ea8 22
CONTENTS, ALLOC, LOAD, READONLY, CODE
15 .fini 00000008 0007ba24 0007ba24 0007ba24 2
0
CONTENTS, ALLOC, LOAD, READONLY, CODE
16 .rodata 000043ca 0007ba40 0007ba40 0007ba40 25
CONTENTS, ALLOC, LOAD, READONLY, DATA
17 .note0 00000000 0007fe0a 0007fe0a 0007fe0a 2
0
CONTENTS, ALLOC, LOAD, READONLY, DATA
18 .data 00004708 00080e20 00080e20 0007fe20 25
CONTENTS, ALLOC, LOAD, DATA
19 .eh_frame 0001c1bc 00085528 00085528 00084528 2
2
CONTENTS, ALLOC, LOAD, DATA
20 .gcc_except_table 00005f90 000a16e4 000a16e4 000a06e4 22
CONTENTS, ALLOC, LOAD, DATA
21 .ctors 00000040 000a7674 000a7674 000a6674 2
2
CONTENTS, ALLOC, LOAD, DATA
22 .dtors 00000040 000a76b4 000a76b4 000a66b4 22
CONTENTS, ALLOC, LOAD, DATA
23 .got 00001620 000a76f4 000a76f4 000a66f4 2
2
CONTENTS, ALLOC, LOAD, DATA
24 .dynamic 000000c8 000a8d14 000a8d14 000a7d14 22
CONTENTS, ALLOC, LOAD, DATA
25 .bss 0000023c 000a8ddc 000a8ddc 000a7ddc 2
2
ALLOC
26 .comment 000005ca 00000000 00000000 000a7ddc 20
CONTENTS, READONLY
27 .note 0000030c 00000000 00000000 000a83a6 2
0
CONTENTS, READONLY


I see .rel.rodata and .rel.text - what does that mean?

Thanks
Jens

Hi Serge,

Thanks for all your help - I will follow you instructions and try to
determine the problem.

How did you get so deeply into shared libraries?

Thanks
Jens


“Serge Yuschenko” <serge.yuschenko@rogers.com> wrote in message
news:atoosr$3b8$1@inn.qnx.com

Hi Jens,

Now you need to get rid of those sections. Unfortunately I don’t know easy
way to find out what caused their appearance. What I can offer you is kind
a
roundabout way, but if you desperate you can try it. I think, before
starting doing this it would be helpful to take a look at the ELF
specification:
http://x86.ddj.com/ftp/manuals/tools/elf.pdf

Here is the step by step instruction how to figure out what causes
.rel.rodata section appearance.

  1. You already have found the section offset in your dll. According the
    listing you’ve got, it is 00003afa0. The same information you can get from
    map file.

  2. Now you need to take a look at content of this section. You can do it
    with objdump -s command. According to your listing it contains
    250 entries
    (section size: 7D0 / sizeof(Elf32_Rel)) representing Elf32_Rel structures.
    First 4 bytes of the structure is offset of the object inside your dll to
    be
    relocated. Let’s say you found that first 4 bytes of the section are 20 BC
    07 00.

  3. Now you need to find out what symbol inside the dll this address
    belongs
    to. You can get a good map of the dll with the objdump -DS . You
    don’t
    actually
    need all that disassembled stuff. What you really need is a symbol name
    corresponding to 0007BC20 address or “covering” this address.

  4. Let’s imagine, again, you found the address we’re looking for inside of
    abc.25> data structure, located at 0007BC0A. You can see that the problem
    with
    the relocation was caused by some field inside of the abc structure at 0xA
    offset (0007BC20 - 0007BC0A).

It is up to you how to fix it. Most likely the place we localized is a
pointer to a function or static data structure. As I said before this sort
of problem
can happen if your abc structure is declared as const, and, I believe this
is not only reason.

If you found out that this address doesn’t belong to any of your data, but
some other library, most likely this library shouldn’t be linked with a
dll.

To figure out where did the .rel.text come from take a look at the LOAD
lines in the map file. I believe those lines shouldn’t contain any static
libraries
except libgcc.a and libcS.a. Put also -v in the cc command line to make
sure
that everything is compiled with the -fPIC option.

Phew…
I think it is enough for a start > :slight_smile:> .

Good luck,

Serge


P.S. I don’t challenge a first place in the dll troubleshooting. It would
be
really interesting to see other approaches.



“Jens H Jorgensen” <> jhj@remove-nospam-videk.com> > wrote in message
news:atkt49$i6k$> 1@inn.qnx.com> …
This is the output from objdump -h dll-file - for one of the .so which
cause
a segv when being dlopen()'ed.


libcppeditor.so: file format elf32-i386

Sections:
Idx Name Size VMA LMA File off Algn
0 .hash 000041f4 000000b4 000000b4 000000b4 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .dynsym 00008760 000042a8 000042a8 000042a8 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .dynstr 00011d46 0000ca08 0000ca08 0000ca08 20
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .rel.text 0000a5e0 0001e750 0001e750 0001e750 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .rel.gcc_except_table 0000bcd0 00028d30 00028d30 00028d30 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .rel.eh_frame 000065a0 00034a00 00034a00 00034a00 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .rel.rodata 000007d0 0003afa0 0003afa0 0003afa0 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .rel.data 000047c8 0003b770 0003b770 0003b770 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .rel.ctors 00000070 0003ff38 0003ff38 0003ff38 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .rel.dtors 00000070 0003ffa8 0003ffa8 0003ffa8 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 .rel.got 00000300 00040018 00040018 00040018 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
11 .rel.plt 00002928 00040318 00040318 00040318 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .init 00000008 00042c40 00042c40 00042c40 20
CONTENTS, ALLOC, LOAD, READONLY, CODE
13 .plt 00005260 00042c48 00042c48 00042c48 2
2
CONTENTS, ALLOC, LOAD, READONLY, CODE
14 .text 00033b7c 00047ea8 00047ea8 00047ea8 22
CONTENTS, ALLOC, LOAD, READONLY, CODE
15 .fini 00000008 0007ba24 0007ba24 0007ba24 2
0
CONTENTS, ALLOC, LOAD, READONLY, CODE
16 .rodata 000043ca 0007ba40 0007ba40 0007ba40 25
CONTENTS, ALLOC, LOAD, READONLY, DATA
17 .note0 00000000 0007fe0a 0007fe0a 0007fe0a 2
0
CONTENTS, ALLOC, LOAD, READONLY, DATA
18 .data 00004708 00080e20 00080e20 0007fe20 25
CONTENTS, ALLOC, LOAD, DATA
19 .eh_frame 0001c1bc 00085528 00085528 00084528 2
2
CONTENTS, ALLOC, LOAD, DATA
20 .gcc_except_table 00005f90 000a16e4 000a16e4 000a06e4 22
CONTENTS, ALLOC, LOAD, DATA
21 .ctors 00000040 000a7674 000a7674 000a6674 2
2
CONTENTS, ALLOC, LOAD, DATA
22 .dtors 00000040 000a76b4 000a76b4 000a66b4 22
CONTENTS, ALLOC, LOAD, DATA
23 .got 00001620 000a76f4 000a76f4 000a66f4 2
2
CONTENTS, ALLOC, LOAD, DATA
24 .dynamic 000000c8 000a8d14 000a8d14 000a7d14 22
CONTENTS, ALLOC, LOAD, DATA
25 .bss 0000023c 000a8ddc 000a8ddc 000a7ddc 2
2
ALLOC
26 .comment 000005ca 00000000 00000000 000a7ddc 20
CONTENTS, READONLY
27 .note 0000030c 00000000 00000000 000a83a6 2
0
CONTENTS, READONLY


I see .rel.rodata and .rel.text - what does that mean?

Thanks
Jens
\

OK, Here is the easy way I learned from somemasters :slight_smile:

  1. Look at how each .o is compiled for libcppeditor.so, there must be “some”
    file
    compiled without -shared. (remove all the .o for libcppeditor.so, and do
    a make -n,
    keep the output in a log and look through them line by line :slight_smile:

  2. If there are tons of files, and you are lazy as me don’t like to look
    large log files :slight_smile:
    you can do this:

readelf -r libcppeditor.so > /tmp/rels

Look into /tmp/rels, especially those number under “Offset”, pick one

objdump -d libcppeditor.so > /tmp/libcppeditor.txt

Look the /tmp/libcppeditor.txt, it have address dumped out, you then
looking at the address arround offset you picked, you can figure out
which function th offset is belonged to.
As you get the function name, it’s just a metter of “grep” to find out
which
source file (.c or .cpp) this function belongs to.

And now you know THAT file is NOT compiled with -shared :slight_smile:

-xtang


Jens H Jorgensen <jhj@remove-nospam-videk.com> wrote in message
news:atq4r3$j5g$1@inn.qnx.com

Hi Serge,

Thanks for all your help - I will follow you instructions and try to
determine the problem.

How did you get so deeply into shared libraries?

Thanks
Jens


“Serge Yuschenko” <> serge.yuschenko@rogers.com> > wrote in message
news:atoosr$3b8$> 1@inn.qnx.com> …
Hi Jens,

Now you need to get rid of those sections. Unfortunately I don’t know
easy
way to find out what caused their appearance. What I can offer you is
kind
a
roundabout way, but if you desperate you can try it. I think, before
starting doing this it would be helpful to take a look at the ELF
specification:
http://x86.ddj.com/ftp/manuals/tools/elf.pdf

Here is the step by step instruction how to figure out what causes
.rel.rodata section appearance.

  1. You already have found the section offset in your dll. According the
    listing you’ve got, it is 00003afa0. The same information you can get
    from
    map file.

  2. Now you need to take a look at content of this section. You can do it
    with objdump -s command. According to your listing it
    contains
    250 entries
    (section size: 7D0 / sizeof(Elf32_Rel)) representing Elf32_Rel
    structures.
    First 4 bytes of the structure is offset of the object inside your dll
    to
    be
    relocated. Let’s say you found that first 4 bytes of the section are 20
    BC
    07 00.

  3. Now you need to find out what symbol inside the dll this address
    belongs
    to. You can get a good map of the dll with the objdump -DS . You
    don’t
    actually
    need all that disassembled stuff. What you really need is a symbol name
    corresponding to 0007BC20 address or “covering” this address.

  4. Let’s imagine, again, you found the address we’re looking for inside
    of
    abc.25> data structure, located at 0007BC0A. You can see that the
    problem
    with
    the relocation was caused by some field inside of the abc structure at
    0xA
    offset (0007BC20 - 0007BC0A).

It is up to you how to fix it. Most likely the place we localized is a
pointer to a function or static data structure. As I said before this
sort
of problem
can happen if your abc structure is declared as const, and, I believe
this
is not only reason.

If you found out that this address doesn’t belong to any of your data,
but
some other library, most likely this library shouldn’t be linked with a
dll.

To figure out where did the .rel.text come from take a look at the LOAD
lines in the map file. I believe those lines shouldn’t contain any
static
libraries
except libgcc.a and libcS.a. Put also -v in the cc command line to make
sure
that everything is compiled with the -fPIC option.

Phew…
I think it is enough for a start > :slight_smile:> .

Good luck,

Serge


P.S. I don’t challenge a first place in the dll troubleshooting. It
would
be
really interesting to see other approaches.



“Jens H Jorgensen” <> jhj@remove-nospam-videk.com> > wrote in message
news:atkt49$i6k$> 1@inn.qnx.com> …
This is the output from objdump -h dll-file - for one of the .so which
cause
a segv when being dlopen()'ed.


libcppeditor.so: file format elf32-i386

Sections:
Idx Name Size VMA LMA File off Algn
0 .hash 000041f4 000000b4 000000b4 000000b4 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .dynsym 00008760 000042a8 000042a8 000042a8 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .dynstr 00011d46 0000ca08 0000ca08 0000ca08 20
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .rel.text 0000a5e0 0001e750 0001e750 0001e750 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .rel.gcc_except_table 0000bcd0 00028d30 00028d30 00028d30 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .rel.eh_frame 000065a0 00034a00 00034a00 00034a00 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .rel.rodata 000007d0 0003afa0 0003afa0 0003afa0 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .rel.data 000047c8 0003b770 0003b770 0003b770 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .rel.ctors 00000070 0003ff38 0003ff38 0003ff38 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .rel.dtors 00000070 0003ffa8 0003ffa8 0003ffa8 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 .rel.got 00000300 00040018 00040018 00040018 22
CONTENTS, ALLOC, LOAD, READONLY, DATA
11 .rel.plt 00002928 00040318 00040318 00040318 2
2
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .init 00000008 00042c40 00042c40 00042c40 20
CONTENTS, ALLOC, LOAD, READONLY, CODE
13 .plt 00005260 00042c48 00042c48 00042c48 2
2
CONTENTS, ALLOC, LOAD, READONLY, CODE
14 .text 00033b7c 00047ea8 00047ea8 00047ea8 22
CONTENTS, ALLOC, LOAD, READONLY, CODE
15 .fini 00000008 0007ba24 0007ba24 0007ba24 2
0
CONTENTS, ALLOC, LOAD, READONLY, CODE
16 .rodata 000043ca 0007ba40 0007ba40 0007ba40 25
CONTENTS, ALLOC, LOAD, READONLY, DATA
17 .note0 00000000 0007fe0a 0007fe0a 0007fe0a 2
0
CONTENTS, ALLOC, LOAD, READONLY, DATA
18 .data 00004708 00080e20 00080e20 0007fe20 25
CONTENTS, ALLOC, LOAD, DATA
19 .eh_frame 0001c1bc 00085528 00085528 00084528 2
2
CONTENTS, ALLOC, LOAD, DATA
20 .gcc_except_table 00005f90 000a16e4 000a16e4 000a06e4 22
CONTENTS, ALLOC, LOAD, DATA
21 .ctors 00000040 000a7674 000a7674 000a6674 2
2
CONTENTS, ALLOC, LOAD, DATA
22 .dtors 00000040 000a76b4 000a76b4 000a66b4 22
CONTENTS, ALLOC, LOAD, DATA
23 .got 00001620 000a76f4 000a76f4 000a66f4 2
2
CONTENTS, ALLOC, LOAD, DATA
24 .dynamic 000000c8 000a8d14 000a8d14 000a7d14 22
CONTENTS, ALLOC, LOAD, DATA
25 .bss 0000023c 000a8ddc 000a8ddc 000a7ddc 2
2
ALLOC
26 .comment 000005ca 00000000 00000000 000a7ddc 20
CONTENTS, READONLY
27 .note 0000030c 00000000 00000000 000a83a6 2
0
CONTENTS, READONLY


I see .rel.rodata and .rel.text - what does that mean?

Thanks
Jens


\

Hi Serge,

Thanks for all your help - I will follow you
instructions and try to determine the problem.

You’re welcome!

How did you get so deeply into shared libraries?

It’s just my curiosity :slight_smile:

Thanks
Jens

Serge

[snip]

OK, Here is the easy way I learned from somemasters > :slight_smile:

  1. Look at how each .o is compiled for libcppeditor.so,
    there must be “some” file compiled without -shared.
    (remove all the .o for for libcppeditor.so, and do
    a make -n, keep the output in a log and look through
    them line by line > :slight_smile:

  2. If there are tons of files, and you are lazy as me
    don’t like to look large log files > :slight_smile:
    you can do this:

readelf -r libcppeditor.so > /tmp/rels

Look into /tmp/rels, especially those number
ber under “Offset”, pick one

For some symbols a symbol name is shown in the /tmp/rels, so you may not need to do objdump -d and look for offset.

objdump -d libcppeditor.so > /tmp/libcppeditor.txt

Look the /tmp/libcppeditor.txt, it have address
ess dumped out, you then looking at the address arround
offset you picked, you can figure out which function
th offset is belonged to.
As you get the function name, it’s just a metter
of “grep” to find out which source file (.c or .cpp)
this function belongs to.

If you work with modules, which source code you don’t have you can track a function in your map file.

And now you know THAT file is NOT compiled with
-shared > :slight_smile:

-xtang

It works for .rel.text, but not for .rel.rodata. However, I think, it is quite possible if you have both - they belong to the same module.

Serge

[snip]