Bug 1017551 - freeglut-2.8.1 regression with Calculix-cgx (menu not shown)
freeglut-2.8.1 regression with Calculix-cgx (menu not shown)
Product: Fedora
Classification: Fedora
Component: freeglut (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Tomas Smetana
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-10-10 03:12 EDT by Manfred Spraul
Modified: 2014-01-31 23:02 EST (History)
2 users (show)

See Also:
Fixed In Version: freeglut-2.8.1-3.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 831336
Last Closed: 2014-01-31 23:00:50 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Manfred Spraul 2013-10-10 03:12:16 EDT
+++ This bug was initially created as a clone of Bug #831336 +++

Description of problem:
calculix cgx does not work properly with freeglut-2.8.1
with freeglut-2.8.0, everything works.

Version-Release number of selected component (if applicable):

How reproducible:
100% reproducible:
1. cgx -f /usr/share/cgx-examples-2.6.1/result.frd
2. left mouse click on the left of the image
3. select "Dataset" (first entry)
4. select "1 DISP ..." (first entry)
5. crash with message
    freeglut (cgx): Menu manipulation not allowed while menus in use.

Tested with cgx-2.6.1:
1. Download & install cgx-2.6.1-1, libSNL-0.2-2 from http://calculix-rpm.sourceforge.net/

Actual results:
cgx killed

Expected results:
Dataset selected

Additional info:
After manually downgrading to freeglut-2.8.0-7.fc18.x86_64, everything works.
Comment 1 Tomas Smetana 2013-10-31 06:11:31 EDT
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.
Comment 2 Manfred Spraul 2013-10-31 14:08:45 EDT
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.

> 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);
>   }
Comment 3 Manfred Spraul 2014-01-18 06:20:07 EST
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.

Your choice how to proceed (cherry-pick r 1583, revert to freeglut-2.8.0-7.fc18.x86_64, ...(
Comment 4 Tomas Smetana 2014-01-21 03:03:54 EST
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.

Comment 5 Tomas Smetana 2014-01-23 03:43:48 EST
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.

Comment 6 Fedora Update System 2014-01-23 09:28:21 EST
freeglut-2.8.1-3.fc19 has been submitted as an update for Fedora 19.
Comment 7 Fedora Update System 2014-01-23 09:28:31 EST
freeglut-2.8.1-3.fc20 has been submitted as an update for Fedora 20.
Comment 8 Fedora Update System 2014-01-24 02:40:57 EST
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:
then log in and leave karma (feedback).
Comment 9 Fedora Update System 2014-01-31 23:00:50 EST
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.
Comment 10 Fedora Update System 2014-01-31 23:02:48 EST
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.

Note You need to log in before you can comment on or make changes to this bug.