Re: [Plib-users] pui help

[Steve B. <sjb...@ai...>]

Brian Smith wrote:

> the callback function for this button (backButtonCallback) is this:
> 
> void backButtonCallback(puObject *) {
>    glutKeyboardFunc(NULL);
>    glutSpecialFunc(NULL);
>    glutIdleFunc(Main_Display);
>    glutDisplayFunc(Main_Display);
>    glutPassiveMotionFunc(Main_MouseMove);
>    glutMouseFunc(Main_MouseChoose);
>    hideTeamButtons();
> }
> 
> and hide TeamButtons() is this:
> 
> void hideTeamButtons() {
>    backButton->hide();
> }

Hmmm - what's unusual about this is switching all of those GLUT function
callbacks within a PUI callback which presumably is in turn inside one of
those very GLUT callbacks that you're changing.

I've never tried to do that kind of thing.  I'd usually have just one GLUT
callback for each of those events - and use an 'if' statement at the start
of the callback to make it do nothing in 'back-button' mode.   That somehow
seems 'kinder' than switching the callbacks around all the time.

So I wonder if this is some kind of a GLUT screwup.

Have you tried building this application against 'freeglut' (and if you
have - have you tried building it against the classic 'GLUT')?  There are
several freeglut developers on this list - so it's not like I'm just trying
to punt the problem over to someone else!

I'm thinking that if somehow the return stack was being corrupted - then
backButton->hide() would be the first thing to attempt to do a 'return',
so it would be the thing that would show up in the crash report even though
it is not the code with the bug in it.

It's a long shot - but that's the only odd thing I can see from the
information you've given us.

The actual hide function itself is *FAR* too simple to cause this problem
unless either the stack or the 'backButton' pointer is corrupted.

You could discount the latter possibility by doing:

   fprintf ( stderr, "backButton=%p\n", backButton ) ;

...and sticking that in the line just below the 'new OneShot' - and again
just before the call to 'hide()'.  If the address changes then that's
what screwed up.  If it doesn't change then it's something else.

However, this is very likely to be some kind of general memory screwup -
which means that the odds are high that this will eventually turn out to
be an application bug.

> Unhandled exception in program.exe: 0xC0000005:  Access Violation.

I don't know Windows/MSVC - but if that '0xC0000005' is a memory address
then it's a suspiciously round number...such as you might get in the
scenario I'm suggesting above where the return address has been screwed up.

It's very hard to diagnose these things at long range.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----