r238860: bsdtar: eating up 100% CPU, hanging
Garrett Cooper
yanegomi at gmail.com
Sat Jul 28 18:16:45 UTC 2012
On Sat, Jul 28, 2012 at 10:21 AM, O. Hartmann
<ohartman at zedat.fu-berlin.de> wrote:
> When updating ports (like databases/sqlite3 or graphics/png via portmaster
> graphics/png), the installation process comes to a point where a backup of
> the old port is created with bsdtar. The process hangs then:
>
> ===>>> Starting build for graphics/png <<<===
>
> ===>>> All dependencies are up to date
>
>
> ===>>> Creating a backup package for old version png-1.5.12
> load: 1.38 cmd: bsdtar 99286 [running] 1301.04r 1296.34u 0.00s 100% 5656k
>
>
> And a look on top:
>
> last pid: 3365; load averages: 1.49, 1.44, 1.41
> up 0+04:39:08 19:17:44
> 65 processes: 2 running, 63 sleeping
> CPU: 50.4% user, 0.0% nice, 1.0% system, 0.0% interrupt, 48.6% idle
> Mem: 521M Active, 3599M Inact, 3424M Wired, 32M Cache, 826M Buf, 323M Free
> ARC: 1970M Total, 672M MRU, 1224M MFU, 48K Anon, 46M Header, 28M Other
> Swap: 32G Total, 32G Free
>
> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU
> COMMAND
> 99286 root 1 103 0 71724K 5672K CPU1 1 24:10 100.00%
> bsdtar
> 1339 root 1 21 0 3221M 38008K select 1 3:02 1.71% Xorg
> 3364 ohartmann 28 20 0 634M 301M uwait 1 0:06 0.63%
> thunderbird
> 737 root 1 20 0 16520K 1492K select 0 0:42 0.00%
> moused
> 3286 ohartmann 22 20 0 681M 368M uwait 1 0:14 0.00%
> firefox
> 1469 ohartmann 1 20 0 72364K 10612K select 1 0:05 0.00%
> xterm
>
>
> I can circumvent by doing a make reinstall in the port's directory, but this
> doesn't work for ports which copy files around using tar - like www/firefox
> and mail/thunderbird (which also get stuck when bsdtar is involved).
>
> My operating system is
> FreeBSD 10.0-CURRENT #0 r238860: Sat Jul 28 11:28:38 CEST 2012
>
> buildworld and kernel from today's sources, ports seem to be up to date, I
> updated everything successfully before installing the new world which seems
> to be faulty.
>
> I also recompiled usr.bin/tar separately and installed it, but without
> success.
>
> What to do?
Debugging with FreeBSD 101:
1. Build application and library with DEBUG_FLAGS=-g .
2. Install application and libraries.
3. Trigger issue again.
4. gcore <pid of hanging process>
5. gdb `which tar` <corefile>
6. Type in bt and hit enter.
Other things that are always needed for developers when tracking
down issues:
- Simple reproductions: I do X, Y happens (exact commands are a must).
- Provide your environment: Quantifying `environment` can be tricky
(it can extend to grabbing shell environment info, machine info, etc),
but in this case grabbing your /etc/make.conf and /etc/src.conf and
providing a date when you synced from ports *should* suffice.
Send the backtrace in 6., the reproduction, and your environment,
to the upstream/local maintainer (in this case kientzle@/mm@) so the
issue can be resolved locally then pulled back in at a later date from
upstream.
Thanks!
-Garrett
PS If your situation is reproducible, I might hit this in a bit when I
upgrade my VMs and have to do ports upgrades. This is always another
helpful datapoint.
More information about the freebsd-current
mailing list