No subject
Fri Aug 12 09:01:57 CEST 2011
allocating resources inside pthread_mutex_init, actually in objectallocate.c
-> chainget.c -> chain.inl.
At first, I though the problem was related to RTEMS running out of memory
(and even tried to increase QEMU memory), but after taking a look to
chain.inl, I think that the problem may be the omni_mutex
constructor calling pthread_mutex_init and therefore allocating resources
before RTEMS is completly ready. Although, RTEMS is the one calling
__do_global_ctors_aux.
I hope any of you can spread some light. In the meantime, what I have in
mind is modify omniORB and delay the pthread_mutex_init call in omni_mutex.
Kind regards,
Ana
P.S. In order to simplify the understanding of the problem, I attach the
code from mutexinit.c (http://pastebin.com/cC6G2UjF), and
since _Thread_Disable_dispatch(), _POSIX_Mutex_Allocate()
and _Thread_Enable_dispatch() are inline functions, I also attached
the unrolled version (http://pastebin.com/MxwXCCj5).
On Fri, Sep 16, 2011 at 9:45 AM, Anita <ana.vazquez.alonso at gmail.com> wrote:
> Hi,
>
> I managed to compile and link all the dependencies libraries together
> with RTEMS 4.10.1 and Newlib, producing a final binary of about 32Mb.
> I run it with QEMU but a problem in runtime arose:
>
> The problem happens inside a c++ constructor, called from
> __do_global_ctors_aux (which if I understand it correctly, basically
> call all the constructors from the table of pointers to constructor
> defined in the .ctors section (i386-rtems-objdump -s -j .ctors
> message_producer_test | vim -)).
>
> __do_global_ctors_aux is called from RTEMS (_Thread_Handler
> ->INIT_NAME -> _init).
>
> The constructor is part of omniORB, omni_mutex::omni_mutex
> (http://pastebin.com/Pcd50Bni). Inside this constructor, a call to
> pthread_mutex_init is produced.
>
> From the gdb log (http://pastebin.com/QrRxWxse) I fear that the
> problem is allocating resources inside pthread_mutex_init, actually in
> objectallocate.c -> chainget.c -> chain.inl.
>
> At first, I though the problem was related to RTEMS running out of
> memory (and even tried to increase QEMU memory), but after taking a
> look to chain.inl, I think that the problem may be the omni_mutex
> constructor calling pthread_mutex_init and therefore allocating
> resources before RTEMS is completly ready. Although, RTEMS is the one
> calling __do_global_ctors_aux.
>
> I hope any of you can spread some light. In the meantime, what I have
> in mind is modify omniORB and delay the pthread_mutex_init call in
> omni_mutex.
>
> Kind regards,
> Ana
>
> P.S. In order to simplify the understanding of the problem, I attach
> the code from mutexinit.c (http://pastebin.com/cC6G2UjF), and since
> _Thread_Disable_dispatch(), _POSIX_Mutex_Allocate() and
> _Thread_Enable_dispatch() are inline functions, I also attached the
> unrolled version (http://pastebin.com/MxwXCCj5).
>
--20cf3001b50929639a04ad0e5c4c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi, according to<br><br><a href=3D"http://www.dfki.de/pipermail/rock-dev/20=
11-September/000842.html">http://www.dfki.de/pipermail/rock-dev/2011-Septem=
ber/000842.html</a><br><br>only half of my mail has been sent. I do not kno=
w why, but just in<br>
cases, here it is the whole mail: <a href=3D"http://pastebin.com/aPaXWWqu">=
http://pastebin.com/aPaXWWqu</a><br><br><div>Hi,<br><br>I managed to compil=
e and link all the dependencies libraries together=A0with RTEMS 4.10.1 and =
Newlib, producing a final binary of about 32Mb.<br>
I run it with QEMU but a problem in =A0runtime arose:<br><br>The problem ha=
ppens inside a c++ constructor, called from=A0__do_global_ctors_aux (which =
if I understand it correctly, basically=A0call all the constructors from th=
e table of pointers to constructor=A0defined in the .ctors section (i386-rt=
ems-objdump -s -j .ctors=A0message_producer_test | vim -)).<br>
<br>__do_global_ctors_aux is called from RTEMS (_Thread_Handler->INIT_NA=
ME -> _init).<br><br>The constructor is part of omniORB, omni_mutex::omn=
i_mutex=A0(<a href=3D"http://pastebin.com/Pcd50Bni">http://pastebin.com/Pcd=
50Bni</a>). Inside this constructor, a call to=A0pthread_mutex_init is prod=
uced.<br>
<br>From the gdb log (<a href=3D"http://pastebin.com/QrRxWxse">http://paste=
bin.com/QrRxWxse</a>) I fear that the=A0problem is allocating resources ins=
ide pthread_mutex_init, actually in=A0objectallocate.c -> chainget.c -&g=
t; chain.inl.<br>
<br>At first, I though the problem was related to RTEMS running out of=A0me=
mory (and even tried to increase QEMU memory), but after taking a=A0look to=
chain.inl, I think that the problem may be the omni_mutex<br>constructor c=
alling pthread_mutex_init and therefore allocating=A0resources before RTEMS=
is completly ready. Although, RTEMS is the one=A0calling __do_global_ctors=
_aux.<br>
<br>I hope any of you can spread some light. In the meantime, what I have=
=A0in mind is modify omniORB and delay the pthread_mutex_init call in=A0omn=
i_mutex.<br><br>Kind regards,<br>Ana<br><br></div><div>P.S. In order to sim=
plify the understanding of the problem, I attach=A0the code from mutexinit.=
c (<a href=3D"http://pastebin.com/cC6G2UjF">http://pastebin.com/cC6G2UjF</a=
>), and since=A0_Thread_Disable_dispatch(), _POSIX_Mutex_Allocate() and=A0_=
Thread_Enable_dispatch() are inline functions, I also attached the=A0unroll=
ed version (<a href=3D"http://pastebin.com/MxwXCCj5">http://pastebin.com/Mx=
wXCCj5</a>).<br>
<br></div><div><br>On Fri, Sep 16, 2011 at 9:45 AM, Anita <<a href=3D"ma=
ilto:ana.vazquez.alonso at gmail.com">ana.vazquez.alonso at gmail.com</a>> wro=
te:<br>> Hi,<br>><br>> I managed to compile and link all the depen=
dencies libraries together<br>
> with RTEMS 4.10.1 and Newlib, producing a final binary of about 32Mb.<=
br>> I run it with QEMU but a problem in =A0runtime arose:<br>><br>&g=
t; The problem happens inside a c++ constructor, called from<br>> __do_g=
lobal_ctors_aux (which if I understand it correctly, basically<br>
> call all the constructors from the table of pointers to constructor<br=
>> defined in the .ctors section (i386-rtems-objdump -s -j .ctors<br>>=
; message_producer_test | vim -)).<br>><br>> __do_global_ctors_aux is=
called from RTEMS (_Thread_Handler<br>
> ->INIT_NAME -> _init).<br>><br>> The constructor is part o=
f omniORB, omni_mutex::omni_mutex<br>> (<a href=3D"http://pastebin.com/P=
cd50Bni">http://pastebin.com/Pcd50Bni</a>). Inside this constructor, a call=
to<br>
> pthread_mutex_init is produced.<br>><br>> From the gdb log (<a h=
ref=3D"http://pastebin.com/QrRxWxse">http://pastebin.com/QrRxWxse</a>) I fe=
ar that the<br>> problem is allocating resources inside pthread_mutex_in=
it, actually in<br>
> objectallocate.c -> chainget.c -> chain.inl.<br>><br>> At =
first, I though the problem was related to RTEMS running out of<br>> mem=
ory (and even tried to increase QEMU memory), but after taking a<br>> lo=
ok to chain.inl, I think that the problem may be the omni_mutex<br>
> constructor calling pthread_mutex_init and therefore allocating<br>>=
; resources before RTEMS is completly ready. Although, RTEMS is the one<br>=
> calling __do_global_ctors_aux.<br>><br>> I hope any of you can s=
pread some light. In the meantime, what I have<br>
> in mind is modify omniORB and delay the pthread_mutex_init call in<br>=
> omni_mutex.<br>><br>> Kind regards,<br>> Ana<br>><br>> =
P.S. In order to simplify the understanding of the problem, I attach<br>
> the code from mutexinit.c (<a href=3D"http://pastebin.com/cC6G2UjF">ht=
tp://pastebin.com/cC6G2UjF</a>), and since<br>> _Thread_Disable_dispatch=
(), _POSIX_Mutex_Allocate() and<br>> _Thread_Enable_dispatch() are inlin=
e functions, I also attached the<br>
> unrolled version (<a href=3D"http://pastebin.com/MxwXCCj5">http://past=
ebin.com/MxwXCCj5</a>).<br>><br><br></div>
--20cf3001b50929639a04ad0e5c4c--
More information about the Rock-dev
mailing list