kdl in pthread_cond_wait on netsurf buildslave

[pulkomandy]

Anothre KDL from NetSurf's build slave. We have tried to extract as much info as possible over IRC. This happens somewhere in OpenJDK. It seems the condition variable doesn't exist and two threads are accessing it.

This is on a virtual machine installed as follows: ​http://wiki.netsurf-browser.org/Continuous_Integration_Manual_Haiku_Slave_Setup

[pulkomandy]

Backtraces of the two threads and KDL message

[pulkomandy]

cvars list and attempt to access the cvar

[pulkomandy]

Attempt to list the area.

[bonefish]

The immediate cause of the panic is just a missing

DEBUG_PAGE_ACCESS_END(context.page);

in vm_soft_fault() before ​unlocking everything when having to wait for a to-be-unmapped page to become unwired.

Unfortunately that will leave another issue to be resolved: The page we want to unmap isn't actually wired in this case. We have two threads that want to wire the same virtual page for writing. The way wire_page() works, they both first mark the respective address range wired before calling vm_soft_fault() to map a writable page (there's only a readable one from a lower cache). Either thread ignores its own pre-wired range, but not that of the other thread. Hence the read-only page looks wired and cannot be unmapped. Both threads would wait forever.

Not sure how involved a solution would be. It might be possible to mark pre-wired ranges respectively and ignore them in vm_soft_fault(), but this needs to be thought through thoroughly (particularly when to unmark the ranges).

[pulkomandy]

Same panic occured again, attaching complete syslog.

[pulkomandy]

Attached another backtrace of apparently the same or a similar problem.

[bonefish]

Please don't attach more stuff to this ticket (unless it's a solution or a small test case). The problem itself is understood, as documented in comment:1. Adding more comments/attachments will just bury that comment.

If you run into an issue which you think might be different, please create a new ticket. The pattern here is: one thread panic()s in fault_get_page() while another thread waits in vm_soft_fault().

[korli]

For reference, it would be nice to know the actual virtual machine software and version.

[bonefish]

(In #11000) Closing as duplicate of #10977.

[bonefish]

Test program to reproduce the issue

[bonefish]

Attached a test program that fairly reliably reproduces the issue on (virtual) hardware with 3 or more CPUs. Tested with qemu.

Compile with:

g++ -Wall -o 10977 10977.cpp

Run with:

while ./10977; do true; done

[bonefish]

The ASSERT is no longer triggered with hrev48140 (it also fixes a previously not considered follow-up issue), the issue mentioned in comment:1 is fixed in hrev48145.