C-extensions in bzr.dev cause "bzr gcommit" to issue exception: assert False, "How did we get here?"

Can you give a bit more context?

For example, what does "bzr status" give? Does it give something different if you do or don't have the extensions compiled?

Can you add a debug statement right before the assertion? Something like:

print (file_id, paths, changed_content, versioned, parent_ids, names, kinds, executables, present_source, present_target)

Looking at the code in question, it would seem that it might be getting back an entry which the gtk/diff.py code considers unchanged.

Actually, never mind, I tracked it down.

The specific code in bzr-gtk is saying:
elif changed_content is True or executables[0] != executables[1]:

however, the pyrex iter_changes code returns "0" or "1" and not True or False. So "changed_content is True" is failing.

Instead, the gtk code should be doing:
elif changed_content or executables[0] != executables[1]:

Arguably, this is also an issue for iter_changes as it changed the api to return something that evaluates to True, rather than True itself. I'm uploading a patch to bzr.dev that could be used

Attached is a possible fix. If you compile this with pyrex 0.9.8.5 it should still be fast, as that version understands the objects Py_True and Py_False. So at runtime it generates the C code:

__pyx_2 = __pyx_v_content_change;
if (__pyx_2) {
  Py_INCREF(Py_True);
  Py_DECREF(__pyx_v_cchange);
  __pyx_v_cchange = Py_True;
  goto __pyx_L39;
}
/*else*/ {
  Py_INCREF(Py_False);
  Py_DECREF(__pyx_v_cchange);
  __pyx_v_cchange = Py_False;
}

Older versions of Pyrex might have to do a lookup for the object "True" or "False" which would be rather slow. However, I have not tried compiling with them to prove whether this is true or not. (Note that releases are generally compiled with pyrex 0.9.6, as it is what is in Hardy.)

Thanks John. gtk-fix.patch alone fixes my problem. use_True_False.diff alone also does.

To refine what was said about iter_changes, it's _process_entry() which, for the third element of the tuple which it returns, returns an int in the version of _dirtstate_helpers_c.pyx (content_change variable is int), and a bool in the version of dirstate.py.

I got the same error as Guilhem:

What I did to get it was:
- Branch a tree (mysql-6.0)
- Merge with another tree (mysql-5.1-maria) with bzr merge --weave
- Fixed merge issues, did make and make test to verify tre
- bzr resolved --all
- bzr gcommit

I am now stuck and can't continue developing until this is fixed.
Please prioritize this bug accordingly (we have a support contract with Canonical)

bzr status output looks sane (it completes with no errors or warnings(

I am using bzr version 1.8 and gtk plugin 0.96.0dev1
I applied the gtk-fix.patch, but it didn't help; Now I get another error instead.

Here is the output from bzr gcommit after the patch was applied:

(/my/mysql-6.0-maria-tmp) bzr gcommit
bzr: ERROR: exceptions.AssertionError:

Traceback (most recent call last):
  File "/usr/local/lib/python2.5/site-packages/bzrlib/commands.py", line 849, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/usr/local/lib/python2.5/site-packages/bzrlib/commands.py", line 795, in run_bzr
    ret = run(*run_argv)
  File "/usr/local/lib/python2.5/site-packages/bzrlib/commands.py", line 495, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/home/monty/.bazaar/plugins/gtk/__init__.py", line 394, in run
    dlg = CommitDialog(wt)
  File "/home/monty/.bazaar/plugins/gtk/commit.py", line 121, in __init__
    self.fill_in_data()
  File "/home/monty/.bazaar/plugins/gtk/commit.py", line 135, in fill_in_data
    self._fill_in_files()
  File "/home/monty/.bazaar/plugins/gtk/commit.py", line 193, in _fill_in_files
    ) in iter_changes_to_status(self._basis_tree, self._wt):
  File "/home/monty/.bazaar/plugins/gtk/diff.py", line 659, in iter_changes_to_status
    assert kinds[0] is not None
AssertionError

bzr 1.8 on python 2.5.1 (linux2)
arguments: ['/usr/local/bin/bzr', 'gcommit']
encoding: 'ANSI_X3.4-1968', fsenc: 'ANSI_X3.4-1968', lang: 'C'
plugins:
  difftools /home/monty/.bazaar/plugins/difftools [0.91.0]
  extmerge /home/monty/.bazaar/plugins/extmerge [unknown]
  gtk /home/monty/.bazaar/plugins/gtk [0.96.0dev1]
  launchpad /usr/local/lib/python2.5/site-packages/bzrlib/plugins/launchpad [unknown]
  multiparent /usr/local/lib/python2.5/site-packages/bzrlib/plugins/multiparent.py [unknown]
*** Bazaar has encountered an internal error.
    Please report a bug at https://bugs.launchpad.net/bzr/+filebug
    including this traceback, and a description of what you
    were doing when the error occurred.

Here is the associated output from .bzr.log

0.042 encoding stdout as sys.stdout encoding 'ANSI_X3.4-1968'
0.044 bzr arguments: [u'gcommit']
0.044 looking for plugins in /home/monty/.bazaar/plugins
0.234 importmbox not available unless bzrtools is installed
0.274 looking for plugins in /usr/local/lib/python2.5/site-packages/bzrlib/plugins
0.275 Plugin name __init__ already loaded
0.275 Plugin name gtk already loaded
0.275 Plugin name __init__ already loaded
0.278 looking for plugins in /usr/lib/python2.5/site-packages/bzrlib/plugins
0.308 encoding stdout as sys.stdout encoding 'ANSI_X3.4-1968'
1.138 opening working tree '/home/my/mysql-6.0-maria-tmp'
10.902 Traceback (mos...

Michael Widenius wrote:
> - bzr gcommit
>
> I am now stuck and can't continue developing until this is fixed.

I believe you can continue by using the command line commit, e.g. 'bzr
commit' instead of gcommit.
This will open your shell editor so that you can enter a commit message.
Alternatively, you can issue 'bzr commit -m "Commit message"

Jasper

Hi Jasper. Yes, commit would work. Monty and I use gcommit over commit, because gcommit allows entering per-file comments: one revision comment per file. This is useful for documenting large patches.

On Mon, 2008-10-20 at 11:41 +0000, Michael Widenius wrote:
> I got the same error as Guilhem:
>
> What I did to get it was:
> - Branch a tree (mysql-6.0)
> - Merge with another tree (mysql-5.1-maria) with bzr merge --weave
> - Fixed merge issues, did make and make test to verify tre
> - bzr resolved --all
> - bzr gcommit
>
> I am now stuck and can't continue developing until this is fixed.

Please try 'bzr commit' rather than 'bzr gcommit'. Its extremely likely
that you are running into a bzr gtk specific issue and that 'bzr commit'
will just work. If it doesn't, then there is an issue in bzr's core that
I'll be delighted to help analyse and fix.

> Please prioritize this bug accordingly (we have a support contract with Canonical)

To ensure that your bugs are triaged and managed appropriately, please
be sure to all issues via the Canonical support team, who can help
ensure everyone relevant is aware of your issue and looking at it.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Hi Michael,

Michael Widenius wrote:
> I got the same error as Guilhem:
[...]
> File "/home/monty/.bazaar/plugins/gtk/diff.py", line 659, in iter_changes_to_status
> assert kinds[0] is not None
> AssertionError

This appears to be a different error, actually. It's failing on an
earlier assertion, and I don't think it's related to the bug that causes
the “How did we get here?” assertion. It appears that this assertion is
tripped when kinds == (None, None).

It's probably best to file a separate bug report for your issue.

Andrew Bennetts wrote:
> Hi Michael,
>
> Michael Widenius wrote:
>> I got the same error as Guilhem:
> [...]
>> File "/home/monty/.bazaar/plugins/gtk/diff.py", line 659, in iter_changes_to_status
>> assert kinds[0] is not None
>> AssertionError
>
> This appears to be a different error, actually. It's failing on an
> earlier assertion, and I don't think it's related to the bug that causes
> the “How did we get here?” assertion. It appears that this assertion is
> tripped when kinds == (None, None).
>
> It's probably best to file a separate bug report for your issue.

I filed this as bug #286834 (https://bugs.launchpad.net/bzr-gtk/+bug/286834).

Just my few cents,
Mats Kindahl

--
Mats Kindahl
Lead Software Developer
Replication Team
MySQL AB, www.mysql.com

AIUI, the proposed fix was rejected for bzr, marking as won't fix there.

Sorry for wrong assignment.

A reply to Andrew Bennetts comment:

- I originally had exactly the same assert as Guilhem. The difference between his and my problem was that after applying the gtk-fix patch things worked for Guilhem, but I did instead get the above new crash.