pkgin segfaults on upgrade about pkgin

[iMilnb]

What version of pkgin are you running? On which platform?

[Licenser]

I'm having the same issue with 0.6.0nb1 on SmartOS for me it seems to be related to having multiple repositories the issue also documented here TritonDataCenter/pkgsrc#32 with a crashdump attatched.

Cheers,
Heinz

Yum - multiple repos would be nice but I rsync to my own location.

---

W. A. Khushil Dep - [email protected] - 07905 374 843
High Performance Web Platforms Architect & Engineer
@ http://www.facebook.com/GlobalOverlordkhushil

On 19 July 2013 15:55, Heinz N. Gies [email protected] wrote:

I'm having the same issue with 0.6.0nb1 on SmartOS for me it seems to be
related to having multiple repositories the issue also documented here
TritonDataCenter/pkgsrc#32 TritonDataCenter/pkgsrc#32 with a
crashdump attatched.

Cheers,
Heinz

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-21254486
.

[iMilnb]

@Licenser @khushil well yes, multiple repos is a feature that's not actually implemented, I plan to work on it at some point as it is #1 requested feature as of now :)
Thanks for the feedback, I'll update this thread whenever the work really starts on this subject :)

[jacques]

Multiple repositories works fine until pkgin update no longer works. Delete the pkgin.db file and pkgin up and no joy. Imil any idea as to when mutliple repository support will work correctly out the box?

This is actually a big bug bear. Also, random core dumps when upgrading
packages created by using pkg_create, though this maybe because there is
scant information on what must be included in build-info...

On Saturday, 14 September 2013, Jacques Marneweck wrote:

Multiple repositories works fine until pkgin update no longer works.
Delete the pkgin.db file and pkgin up and no joy. Imil any idea as to when
mutliple repository support will work correctly out the box?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-24452399
.

Sent from Gmail Mobile on my iPad2

iMil also, the problem seems to be 'pkgin upgrade' when the packages I build are marked as keepable. If I mark them non keepable the upgrades work fine.

[Licenser]

Given this is a bigger problem for me (or Project FiFo) I've opened a bounty source bounty for this issue

https://www.bountysource.com/issues/914106-pkgin-segfaults-on-upgrade

Cheers,
Heinz

[bahamat]

@khushil I'm getting bit by this too, but marking the package unkeep works.

[iMilnb]

All, I've changed the way remote packages are looked on when multiple repositories are declared, that may have a positive effect on the bug you're witnessing, could anyone give a try to master/github version of pkgin? Thanks.

[bahamat]

Is there an easy way to pick up these changes for testing on SmartOS?

[iMilnb]

No news from reporters for 6 moths+, closing this issue.

[bahamat]

Sorry, I thought I had commented.

I did manage to get this compiled to test on SmartOS. As of the last time I tested I still got segfaults even with these changes.

[bahamat]

I just tried again with the most recent code. Still segfaults.

[iMilnb]

Ok, could you paste here a scenario that fails so I can reproduce it? I've seen that report TritonDataCenter/pkgsrc#32 but I can't reproduce it as I don't have an x86_64 zone.

[bahamat]

After a bit of experimentation I discovered that the segfault only occurs if a installed package has the same name as a package available from the pkgsrc repository. This happens whether the package is installed with pkg_add or if additional repositories are added to etc/pkgin/repositories.conf

To demonstrate I created this Makefile to build a fake package named AnonymousPro. The fake package merely contains a single test file. AnonymousPro from the pkgsrc repository contains a truetype font. The package name isn't important so long as it overlaps with an existing package. I chose AnonymousPro because it won't really break anything if the package contents are replaced.

AnonymousPro-2.001fake1.tgz: build-info pkls comment desc r/tmp/testfile
        pkg_create -B build-info -c comment -d desc -I / -f pkls -U $@

build-info:
        pkg_info -X pkg_install | egrep '^(MACHINE_ARCH|OPSYS|OS_VERSION|PKGTOOLS_VERSION)' > $@

pkls: r/tmp/testfile
        echo '@cwd r' > $@
        ( cd r ; find . -type f ) >> $@

r/tmp/testfile:
        mkdir -p r/tmp
        echo "Test" > $@

comment:
        echo "Test Package" > $@

desc:
        echo "Test Package" > $@

.PHONY: test
test:
        pkg_add ./AnonymousPro-2.001fake1.tgz
        pkg_info | grep AnonymousPro-2.001fake1
        pkgin up -f
        pkgin ls | grep AnonymousPro-2.001fake1
        pkgin fug

.PHONY: clean
clean:
        rm -r r build-info pkls comment desc AnonymousPro-2.001fake1.tgz

This Makefile will reliably reproduce the crash on a clean SmartOS 14.3.0 image without installing any additional software. A free dev tier instance in the Joyent cloud can be provisioned for testing. If you've already used up your dev-tier let me know and I'll see if I can get you some billing credits (since I'm a Joyent employee).

To crash, run:

bmake
bmake test

And after a bit of digging through the source, I think the crash happens in actions.c in narrow_match() at line 723, 724 or 730.

Here's a stack trace of the core:

[root@wasp (barovia) /zones/592c6444-67ac-ec04-db16-d4f85fe76e35/cores]# pstack core.pkgin.87167
core 'core.pkgin.87167' of 87167:   ./pkgin fug
 fffffd7fff189ed6 strcmp () + 16
 0000000000410494 pkgin_upgrade () + a4
 000000000041f39e main () + 5be
 000000000040be3c _start () + 6c

[iMilnb]

Wow now this a perfect report! I'll definitely be able to work with this :)
Thanks a lot!

[iMilnb]

So I figured out that this particular segfault is caused by PKGPATH being NULL for this fake package. I secured strcmp calls, but please note that wrong packages like this one can lead to more inconsistencies.
Checkout latest commit for the fix.

[mamash]

Emile, this more or less confirms by suspicions. Segfaults were often reported when packages were involved that were manually constructed using pkg_create. Most people would have likely used jperkin's guide here:

http://www.perkin.org.uk/posts/creating-local-smartos-packages.html

Creating packages this way is most attractive to 3rd party vendors (possibly even those who used to provide SVR4 packages for closed source software), as they do not want to carry the burden of a full pkgsrc building tree and actually build static binaries with no non-platform dependencies.

[iMilnb]

Hmm, makes sense then, but I fear this could lead to a couple of upgrade issues, PKG_PATH is used to check there's no abusive automatic upgrade, i.e. mysql 5.1 -> 5.5.
Is this packaging method widely used at Joyent? If yes I'd rather add a specific !NULL check.

Update

I've added a specific check for those packages that will not prevent their upgade, not sure if pkgpath being NULL will not bit somewhere else though...

[bahamat]

I use it for building newer binaries for existing packages. E.g., Cfengine in pkgsrc is 3.4.2, but the latest is 3.6.3 and as of 3.6 depends on lmdb which isn't in pkgsrc.

I tried creating an lmdb package and updating Cfengine in the pkgsrc way but I wasn't able to get it working properly. But using jperkins' guide provides usable packages. Jperkins also provides a tutorial for creating a repository which I also do. I used to add my private repo to /opt/local/etc/pkgin/repositories.confuntil I realized that I was getting segfaults. I switched to using pkg_add http://repo/package instead, but since my package names still overlap I'm still getting segfaults.

So, is there something about jperkins' guide that can be updated so that packages will get a proper PKG_PATH? Or, if there were better tutorials (or perhaps more easy to fine tutorials?) about creating/updating pkgsrc packages then we wouldn't need to update them outside of pkgsrc? Can you recommend a good tutorial on pkgsrc?

I'll also try out the new pkgin as soon as I can get to it.

[bahamat]

I've confirmed that the new version doesn't segfault on full-upgrade anymore. But I am still interested in seeing if there's something else or better we should be doing.

[mamash]

I'd say that bahamat's usage above is not exactly legitimate, but understandable given the pkgsrc steep learning curve. The proper approach there would be to import lmdb into pkgsrc and update cfengine of course.

However, it makes sense for closed source software vendors if they feel the need to provide SmartOS binaries. I know Basho does release Riak this way, although they mess things up in other ways too, and we prefer to build Riak ourselves (based on wip/riak).

We can certainly suggest that people put some foo/bar nonsense as PKGPATH, but maybe it's just as easy to have pkgin assume a non-match if PKGPATH empty?

[iMilnb]

@bahamat latest commit should not crash anymore when pkgin fug'ing with NULL PKG_PATH packages, let me know how it goes!

[bahamat]

@iMilnb Confirmed, does not crash anymore on fug.

[iMilnb]

@mamash indeed, I've added what's needed today in order to ignore those packages. It is also already available in wip/pkgin.

[iMilnb]

@bahamat yay! thanks for the report. I'll close that issue unless anything shows up.

[Licenser]

@iMilnb you should claim https://www.bountysource.com/issues/914106-pkgin-segfaults-on-upgrade ;)