Subject: re: [RFC2] new findPointCoords implementation (fwd)
From: sam th (sam@uchicago.edu)
Date: Sun Jun 04 2000 - 03:22:03 CDT
---------- Forwarded message ----------
Date: Sat, 3 Jun 2000 06:55:23 -0500 (CDT)
From: sam th <sam@uchicago.edu>
To: Martin Sevior <msevior@mccubbin.ph.unimelb.edu.au>
Cc: jskov@redhat.com, abiword-dev@abisource.com
Subject: re: [RFC2] new findPointCoords implementation
Further debugging results for the crash in bug 449 (as I mentioned in my
last email).
The basic problem is that when we call
pRun->findPointCoords(iRelOffset, x, y, height);
pRun does not exist (== 0x0)
It might also be a problem that x and y are random values, since they were
never intialized before being passed into this function. But that's not
the immediate problem, since they don't cause the segfault.
Now, pRun intially gets its value on line 923. This works fine. In fact,
everything goes fine until we get to the while loop on line 955. Here, we
iterate until pRun is nil, and then continue on. pRun never recovers.
We then hit the assert on line 964, and assert. This assert is really bad
news, becuase we are now guaranteed to segfault. Here's why:
We know that if we call a method of pRun, we segfault. But on line 978,
we have an if statement involving just such methods. The only way not to
segfault here is to short circut, which is possible if bEOL is false. So
in order to avoid disaster, bEOL must be false. So far so good.
But on line 991, we have another conditional, this time an or involving
!bEOL. Since we know that bEOL is false, we follow this if. Now this if
leads us to another if, that is
if (bCoordOfPrevRun && pRun->letPointPass())
Now, if bCoordOfPrevRun is true, then we call pRun->letPointPass() and
segfault. But if bCoordOfPrevRun is false, we go to the else statment,
which is
} else {
pRun->findPointCoords(iRelOffset, x, y, height);
and call a different method of pRun, and still segfault. This is actually
the point where we have been segfaulting.
So, if we assert on line 964
UT_ASSERT(NULL != pRun);
We are going to segfault, no matter what. This is bad.
I hope you know what to fix, Jesper.
sam th
sam@uchicago.edu
http://sam.rh.uchicago.edu
PS - GDB !!!
------------ Output from gpg ------------
gpg: Good signature from "Sam Tobin-Hochstadt <sytobinh@uchicago.edu>"
This archive was generated by hypermail 2b25 : Sun Jun 04 2000 - 03:23:17 CDT