15.10.2021 12:38, Paolo Bonzini wrote:
On 14/10/21 18:14, Vladimir Sementsov-Ogievskiy wrote:
iotest 30 failing is a long story.. And as I understand the main source of all
these crashes is that we do diffreent graph modifications simultaneously from
parallel block jobs.
In past I sent RFC
On 14/10/21 18:14, Vladimir Sementsov-Ogievskiy wrote:
iotest 30 failing is a long story.. And as I understand the main source
of all these crashes is that we do diffreent graph modifications
simultaneously from parallel block jobs.
In past I sent RFC series with global mutext, to fix a
14.10.2021 00:50, John Snow wrote:
In trying to replace the QMP library backend, I have now twice stumbled upon a
SIGSEGV in iotest 030 in the last three weeks or so.
I didn't have debug symbols on at the time, so I've got only this stack trace:
(gdb) thread apply all bt
Thread 8 (Thread
14.10.2021 16:20, Hanna Reitz wrote:
On 13.10.21 23:50, John Snow wrote:
In trying to replace the QMP library backend, I have now twice stumbled upon a
SIGSEGV in iotest 030 in the last three weeks or so.
I didn't have debug symbols on at the time, so I've got only this stack trace:
(gdb)
On Thu, Oct 14, 2021 at 9:20 AM Hanna Reitz wrote:
> On 13.10.21 23:50, John Snow wrote:
> > In trying to replace the QMP library backend, I have now twice
> > stumbled upon a SIGSEGV in iotest 030 in the last three weeks or so.
> >
> > I didn't have debug symbols on at the time, so I've got
On 13.10.21 23:50, John Snow wrote:
In trying to replace the QMP library backend, I have now twice
stumbled upon a SIGSEGV in iotest 030 in the last three weeks or so.
I didn't have debug symbols on at the time, so I've got only this
stack trace:
(gdb) thread apply all bt
Thread 8 (Thread
In trying to replace the QMP library backend, I have now twice stumbled
upon a SIGSEGV in iotest 030 in the last three weeks or so.
I didn't have debug symbols on at the time, so I've got only this stack
trace:
(gdb) thread apply all bt
Thread 8 (Thread 0x7f0a6b8c4640 (LWP 1873554)):
#0
