close_fd() page fault

[ttcoder]

Looks like some backtraces from #4157 deps

hrev48411

First time we see that one but we'll try to eventually get rid of /bin/wget forking/utilization and use native sockets instead, anyway.

[anevilyak]

Most likely a duplicate of #4473 (taking into account team cleanup refactoring in the intervening years), but I'll let bonefish make the call there.

[ttcoder]

same computer as before

[ttcoder]

That second one is clearly a duplicate of 4473 (?), crashes in put_fd() instead of close_fd()

Anyway that's odd, we never saw that before and today, occurs twice in a row on a machine we meant to ship. Investigating as to how that machine differs from others..

[ttcoder]

dsuden did a pkgman update today (so to 48700+ whereabouts) and it has not KDL'ed yet; we're going to ship it; the improvement could be due to...

• some kernelland fixes in that rev range, or (more likely I suppose)
• the fact that re-ordering packages sometimes exposes bugs that were hidden, as observed by a few people during the last few months.

(edit: the helpful *g* contribution below might be referring to this: ticket:11666#comment:3)

[anevilyak]

Replying to ttcoder:

• the fact that re-ordering packages sometimes exposes bugs that were hidden, as observed by a few people during the last few months.

Please stop making this your boogeyman for every sporadically reproducible problem you encounter. The only instance where file order is actually relevant is for add-ons, and in the specific cases where it occurred it was because two different add-ons claimed support for the same format with the same priority. This is a very special case scenario that only really comes into play for the media kit and translation kit, and isn't relevant in pretty much any other scenario, so please stop jumping on it at every possible chance as you seem to have developed a tendency to do in recent weeks.