Robert Webb (robertw++at++wormald.COM.AU)
Tue, 20 Feb 1996 16:05:32 +1100 (EST)
This bug is driving me mad. I wrote earlier:
> My Performer 2.0 application is crashing, and I don't know why. I have a
> billboard with a number of geosets in it. I am setting the position
> within the billboard of each geoset explicitly (I know there are some
> problems with 2.0 if you do not). It may well be something I am doing
> wrong, but I can't see why Performer should ever die where it is dying.
>
> ...
>
> Note also that this bug has only appeared since we started using a separate
> DBASE process, although this billboard is created and modified only in the
> APP.
Here's some more info. It turns out I can make my application crash in one
of two completely unrelated ways (I think), just by swapping two lines. I
can't see why it should crash in either case, or why it should make a
difference.
Some history: At first my DBASE process just crashed immediately. We
discovered that we MUST call pfFrame() BEFORE our main loop, and before
setting up our DBASE function in order for it not to crash. Note that when
it did crash, it would run for two or three frames before doing so anyway.
So we thought, fine, we'll just call pfFrame() before setting up our DBASE
function. We were happy for a while, but then we realised it crashes now
whenever we create one of a number of effects of ours which are based on
billboards. If we take out the extra pfFrame() at the start, then this
doesn't crash (although then it crashes, as described above, whenever we use
a DBASE process). With the extra pfFrame() in, it will crash when this
particular geometry is created, whether or not we are using a DBASE process.
So we can choose which of these forms of core dump we get now by swapping
these lines:
pfFrame();
node = pfNewScene();
Where 'node' is passed to the DBASE process as part of the data allocated
with pfAllocDBaseData(). The DBASE process then attaches paged-in terrain
to this node.
I have wasted a lot of time just discovering this much. Someone must know
something about how this sort of bug could possibly happen. It is bizarre
that calling pfFrame() an extra time at the start can cause a core dump some
time down the track when certain geometry is created.
PLEASE HELP! Someone! ANYONE!!.. :-/
Here are the stack traces:
With the lines in this order:
pfFrame();
node = pfNewScene();
the DBASE process is OK, but (some of) the billboard geometry causes a core
dump:
> 0 pfSprite::pr_transform(pfGeoSet*)(0x1856ba50, 0x0, 0x101888a8, 0x4, 0x3cb0b3da) ["../../../lib/libpr/pfSprite.C":1082, 0x5d1056e0]
1 genDrawGSet(pfGeoSet*,char*,char*,char*,char*)(0x40447104, 0x1856b990, 0x101888a8, 0x186032c0, 0x1856b950) ["../gsdraw.C":4493, 0x5d1043ec]
2 pfGeoSet::pr_draw(pfGeoState*,pfDispList*,pfStatsValGeom*)(0x1856ba50, 0x1856ab30, 0x101888a8, 0x3f315cad, 0x0) ["../../../lib/libpr/pfGeoSet.C":1700, 0x5d112d24]
3 pfBillboard::pf_draw(pfGeoState*,pfDispList*,pfStatsValGeom*,int,_pfCuller*,pfVec3*)(0x18618ec0, 0x1856ab30, 0x0, 0x0, 0x0) ["../../../lib/libpf/pfBillboard.C":513, 0x5d11190c]
4 _pfCuller::nb_draw(int)(0x18618ec0, 0x0, 0x5e0e5510, 0x5e0e5250, 0x0) ["../../../lib/libpf/pfCuller.C":1424, 0x5d1195e8]
5 beginDraw(int)(0x18618ec0, 0x928bb352, 0x3d66f50c, 0x1, 0x100133e0) ["../../../lib/libpf/pfProcess.C":3847, 0x5d13bed0]
6 pfDraw(0x18618ec0, 0x1, 0x0, 0x5e0e0388, 0x4) ["../../../lib/libpf/pfProcess.C":3873, 0x5d1423ec]
7 DrawChannel(channel = 0x180e08f0, data = 0x181bfc00) ["draw_func.c":308, 0x41f8b0]
8 pfChannel::pf_callDrawFunc()(0x40447103, 0xd3493db7, 0x5e0e9bb0, 0x0, 0x0) ["../../../lib/libpf/pfChannel.C":1805, 0x5d13cde0]
9 doDraw(pfChannel*)(0x1807bf90, 0x5d143280, 0x5e0e9bb0, 0x53ca34, 0x40447103) ["../../../lib/libpf/pfProcess.C":3768, 0x5d13ad9c]
10 appCullDraw(int)(0x80a, 0x5d143280, 0x5e0e9bb0, 0x0, 0x404470b0) ["../../../lib/libpf/pfProcess.C":2402, 0x5d1cbd98]
11 pfFrame(0x1, 0x5d143280, 0x5e0e9bb0, 0x0, 0x7fffac60) ["../../../lib/libpf/pfProcess.C":2703, 0x5d1ccbac]
12 main(argc = 16, argv = 0x7fffaec4) ["main.c":499, 0x43a27c]
With the lines in this order:
node = pfNewScene();
pfFrame();
the DBASE process dies after a few frames:
> 0 pfBuffer::pf_destroyMem(0x100312c0, 0x18590980, 0x5e0c8040, 0x0, 0x5e0e5690) ["../../../lib/libpf/pfBuffer.C":1377, 0x5d184648]
1 pfDBase(0x100312c0, 0x18590980, 0x5e0c8040, 0x0, 0x404e0000) ["../../../lib/libpf/pfProcess.C":2994, 0x5d1cd658]
2 pageDBase(data = 0x18522a10) ["ladbm.c":94, 0x4698d0]
3 mpDBase()(0x18522a10, 0x18590980, 0x5e0c8040, 0x0, 0x1) ["../../../lib/libpf/pfProcess.C":3093, 0x5d1cda7c]
4 pfConfig(0x18522a10, 0x18590980, 0x5e0c8040, 0x0, 0x7fffac60) ["../../../lib/libpf/pfProcess.C":1705, 0x5d15a9a0]
5 main(argc = 16, argv = 0x7fffaec4) ["main.c":315, 0x439aa8]
Thanks to anyone who can shed any light on this,
Rob.
____________________________________________________________________________
| ""--..__---....__ |
| _ "-._--,_ """"---...__ |
| |_) _ |_ _ ._ _|_ \ / _ |_ |_ "-. """--.._ ""--.|
| | \(_)|_)(/_| |_ \/\/ (/_|_)|_)o "-.--._ "-._ |
| "-. "-. "-._ |
| robertw++at++wormald.com.au ", "-. `.|
| ', "-_ |
| ', `. |
| "You don't have to put on clothes, ', `|
| Nobody has to hide, ', |
| 'coz everyone already knows" - Cat Stevens. \ |
| \ |
| \|
+----------------------------------------------------------------------------+
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:26 PDT