Am Tue, 18 Jun 2013 19:12:06 -0700
schrieb Sean Kelly :
> On Jun 18, 2013, at 7:01 AM, Marco Leise wrote:
>
> > Am Mon, 17 Jun 2013 10:46:19 -0700
> > schrieb Sean Kelly :
> >
> >> On Jun 13, 2013, at 2:22 AM, Marco Leise wrote:
> >>
> >>> Here is an excerpt from a stack trace I got while pro
On Jun 18, 2013, at 7:01 AM, Marco Leise wrote:
> Am Mon, 17 Jun 2013 10:46:19 -0700
> schrieb Sean Kelly :
>
>> On Jun 13, 2013, at 2:22 AM, Marco Leise wrote:
>>
>>> Here is an excerpt from a stack trace I got while profiling
>>> with OProfile:
>>>
>>> #0 sem_wait () from /lib64/libpthread
Am Mon, 17 Jun 2013 10:46:19 -0700
schrieb Sean Kelly :
> On Jun 13, 2013, at 2:22 AM, Marco Leise wrote:
>
> > Here is an excerpt from a stack trace I got while profiling
> > with OProfile:
> >
> > #0 sem_wait () from /lib64/libpthread.so.0
> > #1 thread_suspendAll () at core/thread.d:2471
>
On Jun 13, 2013, at 2:22 AM, Marco Leise wrote:
> Here is an excerpt from a stack trace I got while profiling
> with OProfile:
>
> #0 sem_wait () from /lib64/libpthread.so.0
> #1 thread_suspendAll () at core/thread.d:2471
> #2 gc.gcx.Gcx.fullcollect() (this=...) at gc/gcx.d:2427
> #3 gc.gcx.
One more note: I get this consistently during profiling, but
not without.
I don't count kernel involvement out either, since OProfile is
a kernel based profiler and there could be a quirk in its
interaction with semaphores.
--
Marco
Here is an excerpt from a stack trace I got while profiling
with OProfile:
#0 sem_wait () from /lib64/libpthread.so.0
#1 thread_suspendAll () at core/thread.d:2471
#2 gc.gcx.Gcx.fullcollect() (this=...) at gc/gcx.d:2427
#3 gc.gcx.Gcx.bigAlloc() (this=..., size=16401, poolPtr=0x7fc3d4bfe3c8,
a