On 4 November 2018 at 22:03, Paolo Bonzini wrote:
> On 02/11/2018 14:33, Peter Maydell wrote:
>> On 9 October 2018 at 12:16, Paolo Bonzini wrote:
>>> Yup, we have to stop using pthread_key_create. Luckily, these days
>>> there is always qemu_thread_start that wraps the thread, so we can call
>>>
On 02/11/2018 14:33, Peter Maydell wrote:
> On 9 October 2018 at 12:16, Paolo Bonzini wrote:
>> On 08/10/2018 18:40, Kevin Wolf wrote:
I'm pretty confident this analysis of the problem is correct:
unfortunately I have no idea what the right way to fix it is...
>>> Yes, I agree with
On 9 October 2018 at 12:16, Paolo Bonzini wrote:
> On 08/10/2018 18:40, Kevin Wolf wrote:
>>>
>>> I'm pretty confident this analysis of the problem is correct:
>>> unfortunately I have no idea what the right way to fix it is...
>> Yes, I agree with your analysis. If __thread variables can be destr
On 08/10/2018 18:40, Kevin Wolf wrote:
>>
>> I'm pretty confident this analysis of the problem is correct:
>> unfortunately I have no idea what the right way to fix it is...
> Yes, I agree with your analysis. If __thread variables can be destructed
> before pthread_key_create() destructors are call
Am 08.10.2018 um 21:53 hat Eric Blake geschrieben:
> On 10/8/18 11:40 AM, Kevin Wolf wrote:
> > Am 08.10.2018 um 17:43 hat Peter Maydell geschrieben:
> > > Looking at the backtraces I'm wondering if this is the result of
> > > an implicit reliance on the order in which per-thread destructors
> > >
On 10/8/18 11:40 AM, Kevin Wolf wrote:
Am 08.10.2018 um 17:43 hat Peter Maydell geschrieben:
Looking at the backtraces I'm wondering if this is the result of
an implicit reliance on the order in which per-thread destructors
are called (which is left unspecified by POSIX) -- the destructor
functi
On 8 October 2018 at 17:40, Kevin Wolf wrote:
> By the way, can you reproduce this with virtio-blk/scsi and an iothread
> in a real QEMU or is it only the test case that fails? In theory, I
> don't see what would prevent QEMU from hanging at shutdown.
I haven't tested, but I suspect this is less
Am 08.10.2018 um 17:43 hat Peter Maydell geschrieben:
> Looking at the backtraces I'm wondering if this is the result of
> an implicit reliance on the order in which per-thread destructors
> are called (which is left unspecified by POSIX) -- the destructor
> function qemu_thread_atexit_run() is cal
On 8 October 2018 at 10:12, Peter Maydell wrote:
> I looked back at the backtrace/etc that I posted earlier in this
> thread, and it looked to me like maybe a memory corruption issue.
> So I tried running the test under valgrind on Linux, and:
...which goes away if I do a complete build from clea
On 5 October 2018 at 19:09, Kevin Wolf wrote:
> And if we disable it wholesale, then nobody has any incentive to fix any
> bug that the test case could have uncovered.
Yes, that's fair. I'm sorry; I was a bit grumpy when I wrote
that email because my test runs had been bumping into it all day.
>
Am 05.10.2018 um 18:54 hat Peter Maydell geschrieben:
> On 5 October 2018 at 17:17, Kevin Wolf wrote:
> > Am 05.10.2018 um 16:41 hat Peter Maydell geschrieben:
> >> On 5 October 2018 at 15:38, Peter Maydell wrote:
> >> > The test-bdrv-drain test fails at least 50% of the time
> >> > on my OS buil
On 5 October 2018 at 17:17, Kevin Wolf wrote:
> Am 05.10.2018 um 16:41 hat Peter Maydell geschrieben:
>> On 5 October 2018 at 15:38, Peter Maydell wrote:
>> > The test-bdrv-drain test fails at least 50% of the time
>> > on my OS build system. Disable the test until we can figure
>>
>> This is a t
Am 05.10.2018 um 16:41 hat Peter Maydell geschrieben:
> On 5 October 2018 at 15:38, Peter Maydell wrote:
> > The test-bdrv-drain test fails at least 50% of the time
> > on my OS build system. Disable the test until we can figure
>
> This is a typo: I meant "OSX build system".
>
> > out what's go
On 5 October 2018 at 15:38, Peter Maydell wrote:
> The test-bdrv-drain test fails at least 50% of the time
> on my OS build system. Disable the test until we can figure
This is a typo: I meant "OSX build system".
> out what's going on, as this makes pull request processing
> very difficult.
>
>
14 matches
Mail list logo
