summaryrefslogtreecommitdiff
path: root/service_solahart_jakarta_selatan__082122541663/pfinet.mdwn
blob: 7aadd736db968f9be24e74293297301c06e0b2e1 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!tag open_issue_hurd]]

In certain situations, pfinet spawns more and more threads,
apparently without any bounds.

The thread creation happens in bursts rather than continuously.
According to a backtrace in GDB,
all the threads are functional and waiting for client requests.
(The bursts are getting smaller as the number of threads rises,
but probably only because the enormous number of existing threads
slows down processing in general.)

This can be triggered quite reliably by X clients running on the Hurd system,
connected to an X server on another machine over TCP,
and transferring fairly large amounts of data.
The easiest way to reproduce it I found is launching freeciv-gtk2,
pressing the "new game" button, and then simply waiting for a while.