Bug 1017551 - freeglut-2.8.1 regression with Calculix-cgx (menu not shown)
Summary: freeglut-2.8.1 regression with Calculix-cgx (menu not shown)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: freeglut
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Tomas Smetana
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-10 07:12 UTC by Manfred Spraul
Modified: 2014-02-01 04:02 UTC (History)
2 users (show)

Fixed In Version: freeglut-2.8.1-3.fc19
Clone Of: 831336
Environment:
Last Closed: 2014-02-01 04:00:50 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Manfred Spraul 2013-10-10 07:12:16 UTC
+++ 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):
freeglut-2.8.1

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 10:11:31 UTC
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 18:08:45 UTC
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);
>   }

Comment 3 Manfred Spraul 2014-01-18 11:20:07 UTC
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, ...(

Comment 4 Tomas Smetana 2014-01-21 08:03:54 UTC
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.

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

Comment 6 Fedora Update System 2014-01-23 14:28:21 UTC
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

Comment 7 Fedora Update System 2014-01-23 14:28:31 UTC
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

Comment 8 Fedora Update System 2014-01-24 07:40:57 UTC
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).

Comment 9 Fedora Update System 2014-02-01 04:00:50 UTC
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-02-01 04:02:48 UTC
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.