pkg

pkg copied to clipboard

Here is the scenario:

# pkg upgrade -f 
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (2548 candidates):  10%
swig13 has no direct installation candidates, change it to swig30? [Y/n]: y
Checking for upgrades (2548 candidates):  55%
llvm37 has no direct installation candidates, change it to llvm33? [Y/n]: n
llvm37 has no direct installation candidates, change it to llvm34? [Y/n]: n
llvm37 has no direct installation candidates, change it to llvm35? [Y/n]: n
llvm37 has no direct installation candidates, change it to llvm38? [Y/n]: Y
Checking for upgrades (2548 candidates):  93%
clang36 has no direct installation candidates, change it to clang33? [Y/n]: n
clang36 has no direct installation candidates, change it to clang34? [Y/n]: n
clang36 has no direct installation candidates, change it to clang35? [Y/n]: n
clang36 has no direct installation candidates, change it to clang38? [Y/n]: Y
Checking for upgrades (2548 candidates):  97%
arangodb33 has no direct installation candidates, change it to arangodb32? [Y/n]: 
Checking for upgrades (2548 candidates): 100%
Processing candidates (2548 candidates): 100%
Child process pid=73891 terminated abnormally: Segmentation fault

Deleting arangodb33 and problematic llvmNN packages helped.

pkg-1.10.4

Can confirm on FreeBSD 11 stable and 1.10.5.

Happens also on 12.0.

Every time I see "X has no direct installation candidates, change it to Y", I know already that pkg is going to crash.

Workaround is to delete all these mentioned packages and try pkg upgrade -f again.

I have been experiencing this as well.

Please: is what's below an occurrence of this issue?

If not, should I make a separate bug report?

…

Postscript: moved to #2045

… ah,

(moved to https://github.com/freebsd/pkg/issues/2045#issuecomment-1147037686)

If off-topic from 1659: I'll hide, and apologies for the noise.

Obviously, pkg(8) should never be seg faulting. Analyzing the core dump may suggest where the problem is occurring. I don't know if the original reported problem here (in 2018) is the same as the seg fault described a few hours ago in this thread. But enough time has passed and code has changed that I would probably be inclined to open a new bug for the comment just added by @grahamperrin - preferably with a stack trace and a description of the exact version of pkg and possibly some picture of the state of the pkg db. 'pkg info' might be a good start.

The (null) entries indicate something is wrong in the environment, or at least unexpected by the pkg tool. The pkg(8) code may just not be accounting for an edge case that is actually possible (but perhaps not common). Or the pkg db is seriously damaged (still pkg(8) should not be seg faulting, nonetheless).

I know that I have seen dependencies show up as -(null) when a port is updated without a dependent port getting rebuilt. Just as an example, when one updates to a new perl version, say perl5.30 -> perl5.32, when building ports from source, it's not uncommon to see lots of p5-* ports showing a dependency on perl5.32-(null) until those p5 ports are rebuilt or updated from binary packages. Those '-(null)' ports would show up in 'pkg info -dra'.