Bug 116546 fix

Matthew Vanecek mevanecek at yahoo.com
Wed Jul 23 19:14:29 CDT 2003


On Wed, 2003-07-23 at 13:34, Derek Atkins wrote:
> Matthew:
> 
> 1) you should use kvp_frame_delete(), not g_free().

Ah, I did not see that.

> 2) You should never have to set data to NULL when you free it.

You should *always* set the pointer to NULL when you free it.  You know
that.  You can find it in any competent C reference.  It prevents
dangling pointers and situations like this.

> 3) It sounds like the REAL problem is that the postgres backend is
>    referencing a deleted book -- why is it doing that?  You should
>    try to fix that, rather than trying to fix the symbols of accessing
>    freed data.
> 

The *real* problem may be a combination of a lack of functionality in
the PG backend, plus dangling pointers in the engine not being set to
NULL like they should.  There is currently no way I can see to remove a
book from the PG backend's booklist.  The PG backend and engine and glib
*do*, however, check for NULL before accessing data a pointer points to.

The PG backend retrieves the book from the session, or is told what the
book is by the Engine or Session.  The PG backend doesn't create books
willy-nilly (not yet =P), so if a book in the PG backend's book list has
dangling pointers, there's really nothing it can do about it at this
point.

To me, it is simpler to fix the dangling pointers, especially since the
memory that the pointers point to has already been freed and is no
longer accessible (thus causing the segmentation fault when accessed). 
Certainly issues exist in the existing backend; that's why it's being
re-written.  But the entire call chain *does* check for NULL before
accessing the data.  The data is not NULL, so a segmentation fault
ensues.

I'll change the kvp_frame thing to use kvp_frame_delete and resubmit the
patch...

> -derek
> 
> Matthew Vanecek <mevanecek at yahoo.com> writes:
> 
> > This patch corrects Bug 116546.  There is still a problem in qofid.c
> > that was exposed by the fix--the PG backend doesn't fully support the
> > entity type lookups yet, or something.  Too late to diagnose now, must
> > sleep, but here's the patch for the bug fix.
> > 
> > The patch is agains head.  I'll submit the 1.8.x branch patch tomorrow
> > after I've tested it.
> > 
> > Thanks, 
> > -- 
> > Matthew Vanecek
> > perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
> > ********************************************************************************
> > For 93 million miles, there is nothing between the sun and my shadow except me.
> > I'm always getting in the way of something...
> > 
> > _______________________________________________
> > gnucash-patches mailing list
> > gnucash-patches at lists.gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-patches
-- 
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20030723/d302ef56/attachment.bin


More information about the gnucash-devel mailing list