Bug 1017551

Just for the record: this is not the same problem as in the bug #831336: Here I'm pretty sure that cgx is doing something it should not (changing menus while active) and the new freeglut checks for this behaviour.

Will take a better look just to be sure.

Hi Tomas,

a) yes, it is a different bug.
b) No, the check in freeglut is too strict:
glut clears __glutMappedMenu before the callback, i.e. a callback is allowed to modify the menu entries. with freeglut, this doesn't work anymore.

glut_menu.c:
> void
> __glutFinishMenu(Window win, int x, int y)
> {
> [...]
> /* Setting __glutMappedMenu to NULL permits operations that
>     change menus or destroy the menu window again. */
>   __glutMappedMenu = NULL;
> 
>   /* If an item is selected and it is not a submenu trigger,
>      generate menu callback. */
>   if (__glutItemSelected && !__glutItemSelected->isTrigger) {
>     __glutSetWindow(__glutMenuWindow);
>     /* When menu callback is triggered, current menu should be
>        set to the callback menu. */
>     __glutSetMenu(__glutItemSelected->menu);
>     __glutItemSelected->menu->select(
>       __glutItemSelected->value);
>   }

Dee asked me to update bugzilla:

On 01/17/2014 05:14 PM, Diederick C. Niehorster wrote:
> Hi Manfred,
>
> I dove into this deeper and tried to emulate your situation, only to
> find that no crash occurs. Looking into what happened, i see that the
> behavior was changed in svn r 1583: we now first close/deactivate the
> menu and then call the callback as the last thing. So trunk code is
> compatible with GLUT again in this respect (though the change was
> simply made because the menu would stay open while the callback
> executes, and that can look nasty and unresponsive if it is a long
> callback. glad it fixes this issue too.)
>
> Rest assured that in the next release, things will work again. You can
> also update the bugzilla stating that it is indeed our problem, and
> that this problem will only exist in freeglut 2.8.1.
>

Thomas:
Your choice how to proceed (cherry-pick r 1583, revert to freeglut-2.8.0-7.fc18.x86_64, ...(

Hi Manfred,
  thanks for the update. I have seen the upstream svn and since the behaviour was really included on purpose I didn't feel like reverting it.  With the Diedericks explanation I think the best option would be to revert the one patch that introduced the new behaviour.

Regards.

I've taken look at the patch in upstream revision 1583. I've even tried to backport it but it would be a really huge overwrite of the 2.8.1 release: much has changed since then.  Trying to re-implement the new behaviour also sounds a bit risky.

I'm actually considering the least-effort path an simply remove the new checks.  Seeing the reasoning for their introduction I don't think it may actually break anything.

I'll post the testing packages today.

Regards.

freeglut-2.8.1-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/freeglut-2.8.1-3.fc19

freeglut-2.8.1-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/freeglut-2.8.1-3.fc20

Package freeglut-2.8.1-3.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing freeglut-2.8.1-3.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-1423/freeglut-2.8.1-3.fc19
then log in and leave karma (feedback).

freeglut-2.8.1-3.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

freeglut-2.8.1-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.