GNOME Bugzilla – Bug 702356
Base conversions cause an iterator assertion error
Last modified: 2013-06-18 15:21:28 UTC
I often use gnome-calculator (well, gcalctool) to do number conversions from different bases. However, gnome-calculator seems to have a regression from previous versions is that base conversion is no longer possible. This applies to v3.8.1 Steps to reproduce: 1. Enter Programming mode 2. Enter a number in the text field and then store it as Ans by hitting [Enter]. 3. Now, select a different number base (Hexadecimal, Binary, Octal). The usual behavior is that the number in the box would get converted to the new base, however now the number gets cleared and an error is dumped to the console that says: (gnome-calculator:3243): Gtk-WARNING **: Invalid text buffer iterator: either the iterator is uninitialized, or the characters/pixbufs/widgets in the buffer have been modified since the iterator was created. You must use marks, character numbers, or line numbers to preserve a position across buffer modifications. You can apply tags and insert marks without invalidating your iterators, but any mutation that affects 'indexable' buffer contents (contents that can be referred to by character offset) will invalidate all outstanding iterators (gnome-calculator:3243): Gtk-CRITICAL **: gtk_text_buffer_insert_with_tags: assertion `gtk_text_iter_get_buffer (iter) == buffer' failed
Thank you for your bug report. I confirm the bug. It's a regression since the code has been converted to Vala. And still exists in master branch. However from version 3.7.4, we have a new feature to convert bases. Now you can type the base you want to convert the number to. e.g. "120 in hex" will result into "78₁₆" "120₈ in dec" will result into "80" The same can go on with all the bases. Binary (bin) Octal (oct) Decimal (dec) Hexadecimal (hex) Hope this helps.
That's nice, if not a little cumbersome. I guess it's a matter of preference, but I much preferred using the Ctrl+H, Ctrl+D, etc. key commands to do my conversion (as documented in the help) which is now impossible due to this bug. On top of that the "in hex", "in dec", etc. commands are undocumented in the help that I can find so this is not obvious what-so-ever. I guess I should clarify that I'm using an Ubuntu package from the Gnome3-Team PPA, however the source builds the yelp help, so that should be of little concern. I had a look at the code and while I'm not familiar with VALA per se, I get the gist of it. It appears to be a VALA->C conversion problem. But reading the raw C code is clear as mud. It looks like a dissembled binary with all kinds of generically-named "tmp" variables which makes it very hard to follow and track down the actual problem.
I'm attaching a patch, it appears to work as it should. Thought, it differs a bit from the classical behavior that I remember. 1. Enter programming mode 2. Enter 25 and press [Enter] to store it as Ans 3. Press Ctrl+H or select Hexadecimal from the number base drop-down 4. The number is converted to 25<sub>10</sub> rather than the 37 that I expected. But then again, this may be the new behavior as things seem to have changed quite a bit for gcalctool/gnome-calculator. I suspect that the problem is the Vala implementation of Gtk.TextBox.delete() doesn't actually follow the rules as it is supposed to. As per the GTK documentation: "Because the textbuffer is modified, all outstanding iterators become invalid after calling this function; however, start and end will be re-initialized to point to the location where text was deleted." It appears to leave the start and end references invalidated rather than updating them as it should. So, I just added a couple of lines that re-assigned ans_start and ans_end to their new location. This is my first patch ever submitted. I believe it is in the correct format, if it's not I'm sorry about that; please forgive my ignorance. That said, I do have limited experience in GTK in C/C++, but I can't guarantee that I know what I'm doing either. But it appears to work to resolve the issue though more testing may be required.
Created attachment 247070 [details] [review] Fixes the base conversion assertion error
Created attachment 247167 [details] [review] Fix Gtk.TextBufferIterator error in Base conversion githlar, Thank you for your patch. :) The patch seems okay. But there were few changes required along with it to make it work properly. I've fixed the problem in current master branch. Once again, thanks a lot :)