On Mon, Nov 23, 2009 at 09:28:35PM -0500, Stuart Anderson wrote: > On Mon, 23 Nov 2009, Tim Retout wrote: >> I don't think there's anything complicated going on here. The 'priv' >> pointer is not initialized to NULL in 'cb_tree_cursor_changed', so >> contains random memory values. > > This fits with the 32 vs 64 issue I wanted to look for. What I'm > wondering now, is should priv ever get a junk value? It looks like there > are other places that use priv->page with out checking it, so if we get > a bad value here, might it also show up elsewhere?
This hunch is at least partly true; ideally pointers would be consistently initialized to NULL throughout the codebase - once this happens, the g_return_if_fail assertions actually trigger. > If you'd like to give 0.2pre1-10 a test drive, I'll take one more look over > it, and then upload it. > > http://www.netsweng.com/~anderson/pornview_0.2pre1-10_amd64.deb > > Thanks for taking the time to explain your analysis. This package does work for me. I couldn't find your source code to review your changes, but from the changelog: there is an unmatched parenthesis in the line for this bug, and there was probably no need to leave the NMU entry in there, since it was never uploaded. I'll hold off on the NMU for a couple more days; there are two RC bugs older than 7 days, so this is quite pressing. Lintian reports other problems (like out of date autotools files) which could affect some architectures, so at some later date it would be nice if these got fixed. A long-term fix for #527714 is to remove the use of deprecated GTK+ elements. This isn't an immediate priority, though. Regards, -- Tim Retout <t...@retout.co.uk> -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
