Nope we think we have identified the leak. On CPU realize
(ppc_cpu_realize) the translator sets up its tables
(create_ppc_opcodes). This will happen for each thread created. This
would be fine but linux_user cpu_copy function then does:
memcpy(new_env, env, sizeof(CPUArchState));
which will b
Could you try an experiment and put a final 30 second sleep before the
program exits. I suspect the RCU cleanup of the per-thread data never
gets a chance to cleanup.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launch
By running:
valgrind --leak-check=yes ./qemu-ppc tests/testthread
I can replicate a leak compared to qemu-arm with the same test
==25789==at 0x483577F: malloc (vg_replace_malloc.c:299)
The thread creating is not failing. The thread is just running the function
with line: 'std::this_thread::sleep_for( 10ms );'
in the thread, thus waiting for 10ms. Once finished, the thread function ends,
which should also end and cleanup the thread.
(when putting some std::cout console output b
Forgive my ignorance of the C++ threading semantics but when do these
threads end? Inspection shows we do clear-up CPU and thread structures
on exit. That said we do have a comment in linux-user that says:
/* TODO: Free new CPU state if thread creation failed. */
So I wonder if thread creati
** Tags added: ppc
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1836558
Title:
Qemu-ppc Memory leak creating threads
Status in QEMU:
New
Bug description:
When creating c++ threads (with c++
