uninstall failure: "an invalid entry was passed"

[jasperfrumau@…]

I have been stuck upgrading my ports. Ports wants to uninstall and reinstall iso-codes, but cannot. Here is the relevant debug report:

DEBUG: delete: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/iso-codes/work
DEBUG: Removing directory: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_iso-codes/iso-codes
DEBUG: delete: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_iso-codes/iso-codes
DEBUG: Uninstalling iso-codes 3.34_0
DEBUG: Changing to port directory: /opt/local/var/macports/registry/portfiles/iso-codes/3.34_0
DEBUG: OS darwin/11.4.0 (Mac OS X 10.7) arch i386
DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.unload registered provides 'unload', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.distfiles registered provides 'distfiles', a pre-existing procedure. Target override will not be provided
DEBUG: only one arch supported, so not adding the default universal variant
DEBUG: Starting logging for iso-codes
DEBUG: Executing org.macports.main (iso-codes)
DEBUG: uninstall phase started at Thu May 17 11:03:09 ICT 2012
DEBUG: Executing org.macports.uninstall (iso-codes)
--->  Unable to uninstall iso-codes @3.34_0, the following ports depend on it:
Error: org.macports.uninstall for port iso-codes returned: an invalid entry was passed
DEBUG: Error code: registry::invalid
DEBUG: Backtrace: an invalid entry was passed
    while executing
"$depport name"
    (procedure "registry::check_dependents" line 19)
    invoked from within
"registry::check_dependents $port ${uninstall.force} "uninstall""
    (procedure "registry_uninstall::uninstall" line 83)
    invoked from within
"registry_uninstall $subport $version $revision $portvariants [array get user_options]"
    (procedure "portuninstall::uninstall_main" line 3)
    invoked from within
"$procedure $targetname"
Warning: targets not executed for iso-codes: org.macports.uninstall
Please see the log file for port iso-codes for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_iso-codes_3.34_0/iso-codes/main.log
DEBUG: an invalid entry was passed
    while executing
"$depport name"
    (procedure "registry::check_dependents" line 19)
    invoked from within
"registry::check_dependents $port ${uninstall.force} "uninstall""
    (procedure "registry_uninstall::uninstall" line 83)
Warning: Failed to execute portfile from registry for iso-codes @3.34_0
--->  Unable to uninstall iso-codes @3.34_0, the following ports depend on it:
DEBUG: an invalid entry was passed
    while executing
"$depport name"
    (procedure "registry::check_dependents" line 19)
    invoked from within
"registry::check_dependents $port ${uninstall.force} "uninstall""
    (procedure "registry_uninstall::uninstall" line 83)
    invoked from within
"registry_uninstall::uninstall $newname $version_in_tree $revision_in_tree $portinfo(canonical_active_variants) [array get options]"
Error: Uninstall iso-codes 3.34_0 failed: an invalid entry was passed
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets

[jasperfrumau@…]

I found another user has a similar issue here: #30847 . No solution found there yet either though

[jmroot (Joshua Root)]

Cf. #31878 as well

[jasperfrumau@…]

Yeah, so it is an issue that has been around for a while. Really looking forward to a patch.

[neverpanic (Clemens Lang)]

Seems like referential integrity is broken in your registry database. Not sure we can provide a patch for that specific incarnation of the problem (it will probably require manual intervention in the registry to fix).

That being said, our code isn't optimal here for it apparently doesn't wrap the delete operations in a transaction, like it should to prevent this kind of problems when randomly interrupting the port command.

Do you mind compressing your registry database and mailing it to me so I can have a look?

[jasperfrumau@…]

Just emailed you a Dropbox link to download the registry as I have it on my MBP.

[neverpanic (Clemens Lang)]

The query that selects the dependents of a given port from the database is:

sqlite> SELECT dependencies.id FROM ports port INNER JOIN dependencies USING(name) INNER JOIN ports dependent USING (id) WHERE port.id=2220;
1407
1664
2344

1664 and 2344 are existing IDs in your ports table, however 1407 is not.

Your registry has a couple of other dependency relations pointing to a non-existing port:

sqlite> SELECT * FROM dependencies WHERE id = 1407;
1407|gconf|
1407|iso-codes|
1407|enchant|
1407|xorg-libsm|
1407|py27-pygtksourceview|
sqlite> SELECT id,name,version FROM ports WHERE id = 1407;
sqlite>

This entry 1407 is the only entry referenced from the dependencies table missing in the ports table:

sqlite> SELECT dependencies.id,dependencies.name FROM dependencies WHERE dependencies.id NOT IN (SELECT DISTINCT id FROM ports);
1407|gconf
1407|iso-codes
1407|enchant
1407|xorg-libsm
1407|py27-pygtksourceview

So knowing this missing port 1407 must be a dependency of gconf, iso-codes, enchant, xorg-libsm and py27-pygtksourceview we can just create the intersection of the dependencies of those ports, leaving us with pkgconfig as only common dependency. You do have pkgconfig installed in version 0.26, however with a different ID:

sqlite> SELECT id,name,version FROM ports WHERE name LIKE 'pkgconfig';
2323|pkgconfig|0.26

So, to fix your problem, change all occurrences of 1407 in the dependencies table to 2323:

sqlite> UPDATE dependencies SET id = 2323 WHERE id = 1407;

This should fix your problem and allow you using port(1) again.

The more interesting question from a developer point of view is how that problem came into existence and how it could have been prevented. Changing the query that fetches dependents from

sqlite> SELECT dependencies.id FROM ports port INNER JOIN dependencies USING(name) INNER JOIN ports dependent USING (id) WHERE port.id=2220;

to

sqlite> SELECT dependencies.id FROM ports port INNER JOIN dependencies USING(name) INNER JOIN ports dependent ON dependent.id = dependencies.id WHERE port.id=2220;

doesn't return the broken rows; but is this really what we want? We would exchange aborting using the correct error message (there is no port with an ID of 1407 after all, so an invalid entry _was_ passed) with ignoring broken entries in the dependencies table and uninstalling anyway.

We should rather aim to find the location (if any) where a port can be uninstalled without its entries in the dependencies table being removed.

[jasperfrumau@…]

I ran the sqlite query

sqlite> UPDATE dependencies SET id = 2323 WHERE id = 1407;

to replace the id of the missing port in the database with the id used by pkgconfig. It worked like a charm. I can now do

sudo upgrade outdated

again and continue. Thanks! What I however do not understand is what pkgconfig has to do with the the other ports who were listed having port 1407 as a dependency of them. Is pkgconfig related to gconfig? I did not find a man page for pkgconfig. You said it is a common dependency. In what way?

[neverpanic (Clemens Lang)]

If you look at the list of dependencies of gconf, iso-codes, enchant, xorg-libsm and py27-pygtksourceview using port deps $portname you will see only one port is in all of those lists, and that one port is pkgconfig. Since the database records told me that all those ports had a dependency on a specific port with ID 1407 and there is only one dependency in all those lists it was clear that 1407 used to be the ID of pkgconfig in your database.

[cdeil (Christoph Deil)]

I have been getting this error for a few weeks, don't know when it appeared exactly:

$ sudo port uninstall inactive
an invalid entry was passed
    while executing
"$dependent name"
    (procedure "receipt_sqlite::list_dependents" line 18)
    invoked from within
"${macports::registry.format}::list_dependents $name $version $revision $variants"
    (procedure "registry::list_dependents" line 3)
    invoked from within
"registry::list_dependents $pvals(name)"
    (procedure "portlist_sortdependents" line 7)
    invoked from within
"portlist_sortdependents $portlist"
    (procedure "action_uninstall" line 17)
    invoked from within
"$action_proc $action $portlist [array get global_options]"
    (procedure "process_cmd" line 95)
    invoked from within
"process_cmd $remaining_args"
    invoked from within
"if { [llength $remaining_args] > 0 } {

    # If there are remaining arguments, process those as a command
    set exit_status [process_cmd $remaining..."
    (file "/opt/local/bin/port" line 4784)

This is with Macports 2.1.1 and XCode 4.3.3 on Lion.

[cdeil (Christoph Deil)]

Cc Me!

[neverpanic (Clemens Lang)]

Christoph, can you also mail me your registry.db?

[cdeil (Christoph Deil)]

Replying to cal@…:

Christoph, can you also mail me your registry.db?

Here it is: ​https://dl.dropbox.com/u/4923986/bug_reports/registry.db.bz2

[neverpanic (Clemens Lang)]

You have the same problem, however your case is less clear.

You do have incorrect dependencies in your dependencies table:

sqlite> SELECT * FROM dependencies WHERE id NOT IN (SELECT DISTINCT id FROM ports);
243|python27|
243|py27-dateutil|
243|py27-tz|
243|py27-numpy|
243|py27-configobj|
243|py27-pyobjc-cocoa|
243|freetype|
243|libpng|
243|py27-cairo|
243|py27-gtk|

However, I couldn't identify one correct package that is a depdency of all those ports listed; it might be zlib, though. You do have zlib installed:

sqlite> SELECT id,name,version,variants,date,requested,state,installtype FROM ports WHERE name LIKE 'zlib';
3|zlib|1.2.6||1330561572|0|imaged|image
573|zlib|1.2.6|+universal|1334344790|0|imaged|image
686|zlib|1.2.7|+universal|1336335065|0|installed|image

So, I suggest you create a backup of your registry.db open it with sqlite3 and run:

UPDATE dependencies SET id = 686 WHERE id = 243;

[cdeil (Christoph Deil)]

So, I suggest you create a backup of your registry.db open it with sqlite3 and run:

UPDATE dependencies SET id = 686 WHERE id = 243;

Thanks, that solved the problem.

This now works:

$ sudo port uninstall inactive

And this SELECT query you mentioned comes up empty:

$ sqlite3 registry.db 
sqlite> SELECT * FROM dependencies WHERE id NOT IN (SELECT DISTINCT id FROM ports);

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #35281.

[rrg@…]

I've been having the same problem for a while. "sudo port uninstall inactive" has failed this way for a while, and now so does "sudo port uninstall libiconv" (apparently needed as part of the rebuild following the Mountain Lion update). Can you please take a look at my registry db as well?

​https://www.dropbox.com/s/4mpt8s7lxcgnxc5/registry.db.bz2

Thanks.

[rrg@…]

Cc Me!

[neverpanic (Clemens Lang)]

I have just looked at this problem again and apparently while some of my findings were correct I confused "dependencies" and "dependents" in the progress of advising users on how to fix this. This also means that my previous advise on how to fix this was probably wrong and might leave you with a couple of uninstallable packages (you can just use -f in this case).

To explain this: I was under the impression that the missing port referenced by the now invalid ID causing this issue was a common dependency of the ports listed by name in the dependencies table, i.e.,

sqlite> SELECT * FROM dependencies WHERE id NOT IN (SELECT DISTINCT id FROM ports);
618|apr|
618|expat|
618|libiconv|
618|db46|
618|sqlite3|

means that port 618 must be a dependency of apr, expat, libiconv, db46 and sqlite3. However, it really is the other way around: The missing has dependencies to apr, expat, libiconv, db46 and sqlite3. Since you will never be able to uninstall this port or manage any of its files using macports again without the missing entry in ports, those entries in the dependencies table are superfluous and can simply be removed. In fact, not only these, but also all entries in the files table with the same id can be removed (and if there are any with the active flag set, they should also be deleted on disk, but if that really happened there would be some serious problems with your installation).

So, in your case the missing ID 618 must have the ports apr, expat, libiconv, db46 and sqlite3 as dependencies. This would match the apr-util port. We can reassure the missing port is apr-util by looking at the files table:

sqlite> SELECT active,path FROM files WHERE id = 618;
0|/opt/local/bin/apu-1-config
0|/opt/local/include/apr-1/apr_anylock.h
0|/opt/local/include/apr-1/apr_base64.h
0|/opt/local/include/apr-1/apr_buckets.h
0|/opt/local/include/apr-1/apr_date.h
0|/opt/local/include/apr-1/apr_dbd.h
0|/opt/local/include/apr-1/apr_dbm.h
0|/opt/local/include/apr-1/apr_hooks.h
0|/opt/local/include/apr-1/apr_ldap.h
0|/opt/local/include/apr-1/apr_ldap_init.h
0|/opt/local/include/apr-1/apr_ldap_option.h
0|/opt/local/include/apr-1/apr_ldap_rebind.h
0|/opt/local/include/apr-1/apr_ldap_url.h
0|/opt/local/include/apr-1/apr_md4.h
0|/opt/local/include/apr-1/apr_md5.h
0|/opt/local/include/apr-1/apr_memcache.h
0|/opt/local/include/apr-1/apr_optional.h
0|/opt/local/include/apr-1/apr_optional_hooks.h
0|/opt/local/include/apr-1/apr_queue.h
0|/opt/local/include/apr-1/apr_reslist.h
0|/opt/local/include/apr-1/apr_rmm.h
0|/opt/local/include/apr-1/apr_sdbm.h
0|/opt/local/include/apr-1/apr_sha1.h
0|/opt/local/include/apr-1/apr_strmatch.h
0|/opt/local/include/apr-1/apr_thread_pool.h
0|/opt/local/include/apr-1/apr_uri.h
0|/opt/local/include/apr-1/apr_uuid.h
0|/opt/local/include/apr-1/apr_xlate.h
0|/opt/local/include/apr-1/apr_xml.h
0|/opt/local/include/apr-1/apu.h
0|/opt/local/include/apr-1/apu_version.h
0|/opt/local/include/apr-1/apu_want.h
0|/opt/local/lib/apr-util-1/apr_dbd_odbc-1.so
0|/opt/local/lib/apr-util-1/apr_dbd_odbc.a
0|/opt/local/lib/apr-util-1/apr_dbd_odbc.la
0|/opt/local/lib/apr-util-1/apr_dbd_odbc.so
0|/opt/local/lib/apr-util-1/apr_dbd_sqlite3-1.so
0|/opt/local/lib/apr-util-1/apr_dbd_sqlite3.a
0|/opt/local/lib/apr-util-1/apr_dbd_sqlite3.la
0|/opt/local/lib/apr-util-1/apr_dbd_sqlite3.so
0|/opt/local/lib/apr-util-1/apr_dbm_db-1.so
0|/opt/local/lib/apr-util-1/apr_dbm_db.a
0|/opt/local/lib/apr-util-1/apr_dbm_db.la
0|/opt/local/lib/apr-util-1/apr_dbm_db.so
0|/opt/local/lib/aprutil.exp
0|/opt/local/lib/libaprutil-1.0.3.12.dylib
0|/opt/local/lib/libaprutil-1.0.dylib
0|/opt/local/lib/libaprutil-1.a
0|/opt/local/lib/libaprutil-1.dylib
0|/opt/local/lib/libaprutil-1.la
0|/opt/local/lib/pkgconfig/apr-util-1.pc

These are the files that once were installed by the now missing port. The version number of the libaprutil-1.0.3.12.dylib file tells us it's an old version of apr-util. The first column being 0 in all lines also tells us there are no files in the filesystem owned by this port. We can thus safely delete these rows:

DELETE FROM dependencies WHERE id = 618;
DELETE FROM files WHERE id = 618;

(Please, keep a backup before doing this)

This also gives more insight into how this issue might have been created: For some reason, the entry corresponding to those in files and dependencies has gone missing. That means it either was never added (that's impossible, because it's ID was known before the other entries were created) or it was deleted without deleting the other rows. This must have happened after apr-util was deactivated, because (assuming it was activated at some point in time) there probably is no way to modify any of the other tables without the missing row in ports. Maybe there is a way to uninstall a port but not delete the lines from files and dependencies.

[neverpanic (Clemens Lang)]

I could finally reproduce this problem! In my case, it showed up when I tried to run

:) clemens@cSchlepptop:~$ port outdated 
Error: port installed failed: an invalid entry was passed
No ports are installed.

The key here was that I was uninstalling one of the ports that were previously listed in the outdated list simultaneously in a different shell (which fixed itself automatically once the uninstall was complete). I'm thus assuming that everybody who saw this issue (permanently) somehow interrupted an uninstall process.

The correct fix for the problem would be to wrap the uninstall process in a transaction, so that both concurrently running instances of port and the database on disk will either see/have the changes completely, or not at all.

[neverpanic (Clemens Lang)]

This should be fixed in r100219.

[neverpanic (Clemens Lang)]

Merged into release branch in r100223. This will be part of the next MacPorts release, no matter whether it'll be a minor or major one.

[davidfavor (David Favor)]

This bug has been lingering now for a month.

Be great if a minor macports release could be done to resolve this.

[neverpanic (Clemens Lang)]

Replying to david@…:

Be great if a minor macports release could be done to resolve this.

While I do agree, note that this will only prevent new breakage, but not fix installations that already are broken. To fix those, follow the steps in comment 21.

[davidfavor (David Favor)]

Thanks.

[davidfavor (David Favor)]

To simplify fixing this, in existing situations, I've attached the script file I used to fix my installation.