| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #2588
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 4 - High, e.g. key functionality not working |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | MacOS |
|---|
| Summary: | Mac FLTK 1.3.x crashes when mixed with new Cocoa-based Tcl/Tk 8.5.9... |
|---|
| Version: | 1.3.0 |
|---|
| Created By: | johns.ks.uiuc |
|---|
| Assigned To: | manolo |
|---|
| Fix Version: | 1.3.0 (SVN: v8546) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | johns.ks.uiuc
14:31 Mar 10, 2011 |
| The FLTK library crashes in an uncaught exception when the Cocoa version of the Tk library is in the process of initializing itself. This issue is specific to the Cocoa-based versions of FLTK and Tk. The old Carbon-based FLTK and Tk versions don't have this problem. The Cocoa versions are required in order to build 64-bit applications for MacOS X, thus we are running into this problem now that we've ported our code to MacOS X 10.6 with the new FLTK and new Tk versions. I am assuming that the problem also occurs with 32-bit Cocoa builds, but since we are currently using Carbon based FLTK/Tk on 32-bit builds, I haven't tested that case yet.
If we disable Tk and just use the Tcl scripting only (no GUI windows), then no crash occurs, and FLTK seems to operate fine.
When both FLTK and Tk are enabled, during the initialization of Tk in our application startup, we get the following traceback:
Info) http://www.ks.uiuc.edu/Research/vmd/
Info) Email questions and bug reports to vmd@ks.uiuc.edu
Info) Please include this reference in published work using VMD:
Info) Humphrey, W., Dalke, A. and Schulten, K., `VMD - Visual
Info) Molecular Dynamics', J. Molec. Graphics 1996, 14.1, 33-38.
Info) -------------------------------------------------------------
Info) Multithreading available, 16 CPUs detected.
Info) OpenCL Platform[0]: Apple, FULL_PROFILE Devices: 2
Info) [0] Quadro FX 4800 24 CU @ 1.18 GHz, 1610MB RAM
Info) [1] Intel(R) Xeon(R) CPU E5620 @ 2.40GHz 16 CU @ 2.34 GHz, 19327MB RAM
Info) OpenGL renderer: NVIDIA Quadro FX 4800 OpenGL Engine
Info) Features: STENCIL MTX NPOT PS GLSL(VF)
Info) GLSL rendering mode is NOT available.
Info) Textures: 2-D (8192x8192), 3-D (2048x2048x2048), Multitexture (8)
2011-03-10 15:52:48.047 vmd_MACOSXX86_64[12459:903] -[FLApplication _setup:]: unrecognized selector sent to instance 0x1015091a0
2011-03-10 15:52:48.049 vmd_MACOSXX86_64[12459:903] An uncaught exception was raised
2011-03-10 15:52:48.049 vmd_MACOSXX86_64[12459:903] -[FLApplication _setup:]: unrecognized selector sent to instance 0x1015091a0
2011-03-10 15:52:48.050 vmd_MACOSXX86_64[12459:903] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[FLApplication _setup:]: unrecognized selector sent to instance 0x1015091a0'
*** Call stack at first throw:
(
0 CoreFoundation 0x00007fff865c97b4 __exceptionPreprocess + 180
1 libobjc.A.dylib 0x00007fff85f740f3 objc_exception_throw + 45
2 CoreFoundation 0x00007fff86623110 +[NSObject(NSObject) doesNotRecognizeSelector:] + 0
3 CoreFoundation 0x00007fff8659b91f ___forwarding___ + 751
4 CoreFoundation 0x00007fff86597a68 _CF_forwarding_prep_0 + 232
5 Tk 0x000000010048aa3e TkpInit + 491
6 Tk 0x00000001003f8587 Tk_PkgInitStubsCheck + 2142
7 Tk 0x00000001003f862d Tk_Init + 9
8 vmd_MACOSXX86_64 0x00000001000f442e _ZN13TclTextInterpC2EP6VMDApp + 442
9 vmd_MACOSXX86_64 0x00000001000b8f50 _ZN6UITextC2EP6VMDApp + 132
10 vmd_MACOSXX86_64 0x00000001000bfbca _ZN6VMDApp7VMDinitEiPPcPKcPiS4_ + 1092
11 vmd_MACOSXX86_64 0x00000001000dd121 main + 154
12 vmd_MACOSXX86_64 0x00000001000035f4 start + 52
)
terminate called after throwing an instance of 'NSException'
Abort | |
| |
| #2 | manolo
09:40 Mar 11, 2011 |
| Could you, please, tell if the attached cocoa.patch
solves your problem ? | |
| |
| #3 | johns.ks.uiuc
16:37 Mar 11, 2011 |
| Hi, I tried using the patch on the latest snapshot r8514, but I still get a crash. I contacted Daniel Steffen, the Apple engineer that used to maintain the Cocoa port of Tk about this as well. He suggested that the likely cause of the problem is that Tk Cocoa assumes that it can create its own TKApplication subclass of NSApplication and control its behaviors by the methods in that class, and that one might be able to fix the problem by comparing what the Tk cocoa is doing in its NSApplication subclass vs. what FLTK is doing in its FLApplication class.
I know nothing about cocoa personally (thus the reason I use FLTK!) so it isn't obvious to me what the ramifications of this are, or what would have to be done in either or both of FLTK and Tk to make them coexist under Cocoa like they do have for the last 10 years under X11 and Carbon...
I asked Daniel what portion of the Tk code is relevant and he suggested that the best place to look for starters is in the code that creates the TKApplication class, in TkpInit(), in the tkMacOSXInit.c source file.
The cocoa-version of Tk 8.5.9 I'm building against is available here:
https://github.com/das/tcltk/downloads
The traceback for the crash that occurs with the patched version of FLTK r8514 is similar but not identical to the one I posted originally. In particular, in this one, I don't see any mention of "FLApplication" now:
Info) VMD for MACOSXX86_64, version 1.9 (March 11, 2011)
Info) http://www.ks.uiuc.edu/Research/vmd/
Info) Email questions and bug reports to vmd@ks.uiuc.edu
Info) Please include this reference in published work using VMD:
Info) Humphrey, W., Dalke, A. and Schulten, K., `VMD - Visual
Info) Molecular Dynamics', J. Molec. Graphics 1996, 14.1, 33-38.
Info) -------------------------------------------------------------
Info) Multithreading available, 16 CPUs detected.
Info) OpenCL Platform[0]: Apple, FULL_PROFILE Devices: 2
Info) [0] Quadro FX 4800 24 CU @ 1.18 GHz, 1610MB RAM
Info) [1] Intel(R) Xeon(R) CPU E5620 @ 2.40GHz 16 CU @ 2.34 GHz, 19327MB RAM
Info) OpenGL renderer: NVIDIA Quadro FX 4800 OpenGL Engine
Info) Features: STENCIL MTX NPOT PS GLSL(VF)
Info) GLSL rendering mode is NOT available.
Info) Textures: 2-D (8192x8192), 3-D (2048x2048x2048), Multitexture (8)
2011-03-11 18:17:01.657 VMD[60134:903] -[NSApplication _setup:]: unrecognized selector sent to instance 0x101607b40
2011-03-11 18:17:01.659 VMD[60134:903] An uncaught exception was raised
2011-03-11 18:17:01.659 VMD[60134:903] -[NSApplication _setup:]: unrecognized selector sent to instance 0x101607b40
2011-03-11 18:17:01.670 VMD[60134:903] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSApplication _setup:]: unrecognized selector sent to instance 0x101607b40'
*** Call stack at first throw:
(
0 CoreFoundation 0x00007fff865c97b4 __exceptionPreprocess + 180
1 libobjc.A.dylib 0x00007fff85f740f3 objc_exception_throw + 45
2 CoreFoundation 0x00007fff86623110 +[NSObject(NSObject) doesNotRecognizeSelector:] + 0
3 CoreFoundation 0x00007fff8659b91f ___forwarding___ + 751
4 CoreFoundation 0x00007fff86597a68 _CF_forwarding_prep_0 + 232
5 Tk 0x000000010042da3e TkpInit + 491
6 Tk 0x000000010039b587 Tk_PkgInitStubsCheck + 2142
7 Tk 0x000000010039b62d Tk_Init + 9
8 VMD 0x00000001000f40e2 _ZN18CmdDelAtomSelMacroD1Ev + 66750
9 VMD 0x00000001000b8c00 _ZN8UIObject11check_eventEv + 990
10 VMD 0x00000001000bf87e _ZN8UIObject11check_eventEv + 28764
11 VMD 0x00000001000dcdd5 _ZN18Vrml2DisplayDeviceD1Ev + 18901
12 VMD 0x0000000100003308 _ZN9Fl_PixmapC2EPKPKc + 708
)
terminate called after throwing an instance of 'NSException'
/Scratch/VMD 1.9.app/Contents/MacOS/startup.command: line 7: 60134 Abort trap "$p/../Resources/VMD.app/Contents/MacOS/VMD" $*
logout
[Process completed] | |
| |
| #4 | manolo
23:56 Mar 11, 2011 |
| I also thought the problem lies around Tk and FLTK each subclassing
NSApplication and adding new member functions. The patch removed
the FLTK side of this (that's why FLApplication disappeared in
the traceback).
Could you try exchanging the order with which the cocoa system
is initialized? This is done by calling fl_open_display() for FLTK
or by calling Tk_Init() for Tk.
That is, if Tk_Init() is now called before fl_open_display() or before
the first window show(), please inverse the order of these calls.
And conversely if FLTK enters stage before Tk.
If that is not enough, could you prepare a minimal program that
calls Tk and FLTK and crashes? | |
| |
| #5 | manolo
00:19 Mar 12, 2011 |
| This is to be done with cocoa.patch applied. | |
| |
| #6 | manolo
14:59 Mar 20, 2011 |
| The traceback indicates fl_open_display() is called before Tcl/Tk
is initialized. Please, reverse this order by calling
Tk_Init() before fl_open_display() will be called, either directly
or indirectly by a show() of a window.
Apply also the patch to the FLTK library.
Please, post here whether this change solves this STR. | |
| |
| #7 | johns.ks.uiuc
20:02 Mar 20, 2011 |
| Manolo,
I had to make a production release last week so was unable to perform your test earlier, and I'm currently traveling out of the office all this week. I will try reversing the initialization order first thing upon my return next Monday (March 28). I appreciate your help and will get back to you ASAP when I have run the new tests. | |
| |
| #8 | johns.ks.uiuc
10:56 Mar 29, 2011 |
| Manolo, I'm back in town now and I'm working on changing our application so that Tcl/Tk gets initialized before FLTK, so I can re-try your patch.
I hope to have some test results soon, I've just got a few little things to tweak so that the change of initialization order doesn't break anything else.
Cheers,
John | |
| |
| #9 | johns.ks.uiuc
11:22 Mar 29, 2011 |
| Manolo,
After working through some issues with reversing the initialization code so that FLTK gets initialized after Tcl/Tk, our program successfully makes it through startup and appears (didn't test thoroughly) to work. During the initialization code, a warning message is displayed which I've never seen before:
"2011-03-29 13:11:51.766 vmd_MACOSXX86_64[7400:903] _createMenuRef called with existing principal MenuRef already associated with menu"
The VMD initialization otherwise looks normal:
Info) VMD for MACOSXX86_64, version 1.9.1a1 (March 29, 2011)
Info) http://www.ks.uiuc.edu/Research/vmd/
Info) Email questions and bug reports to vmd@ks.uiuc.edu
Info) Please include this reference in published work using VMD:
Info) Humphrey, W., Dalke, A. and Schulten, K., `VMD - Visual
Info) Molecular Dynamics', J. Molec. Graphics 1996, 14.1, 33-38.
Info) -------------------------------------------------------------
Info) Multithreading available, 16 CPUs detected.
Info) OpenCL Platform[0]: Apple, FULL_PROFILE Devices: 2
Info) [0] Quadro FX 4800 24 CU @ 1.18 GHz, 1610MB RAM
Info) [1] Intel(R) Xeon(R) CPU E5620 @ 2.40GHz 16 CU @ 2.34 GHz, 19327MB RAM
2011-03-29 13:11:51.766 vmd_MACOSXX86_64[7400:903] _createMenuRef called with existing principal MenuRef already associated with menu
Info) OpenGL renderer: NVIDIA Quadro FX 4800 OpenGL Engine
Info) Features: STENCIL MDE CVA MTX NPOT PP PS GLSL(OVF)
Info) Full GLSL rendering mode is available.
Info) Textures: 2-D (8192x8192), 3-D (2048x2048x2048), Multitexture (8)
vmd >
Let me know if you have a suggestion regarding the "MenuRef" warnings...
Do you think the cocoa patch you sent me could go into the mainline FLTK, or is it merely a short-term workaround?
Cheers,
John | |
| |
| #10 | manolo
13:00 Mar 29, 2011 |
| Great. We are making good progress.
Yes, I will commit this patch to the FLTK 1.3 source tree.
The error message is most probably because FLTK and either your
application or Tk both want to create an application menu.
Could you, please, check if this error message is created by your
code ? I would bet yes. In that case, I think fair to consider that
you would have to adapt your code to the new state of things
prepared by FLTK, that is, a working application menu, with an
optional "Print front window" item. Your code could add more items
to this menu if needed. | |
| |
| #11 | johns.ks.uiuc
13:19 Mar 29, 2011 |
| Manolo,
Our application doesn't create an application menu, but I believe that Tk does... Maybe Tk and FLTK are both trying to create an application menu and colliding with each other there. I'll look into this some more and let you know what I find.
Cheers,
John | |
| |
| #12 | manolo
13:30 Mar 29, 2011 |
| Fixed in Subversion repository.
The fix works but requires that the NSApplication subclass be
initialized before the FLTK fl_open_display() function is called. | |
| |
| #13 | manolo
14:03 Mar 29, 2011 |
| Could you try cocoa.patch2 (very small). It may fix the application
menu conflict. | |
| |
| #14 | johns.ks.uiuc
12:28 Mar 31, 2011 |
| Manolo,
The second patch does not fix the warnings about the menuRef stuff.
I spent some time tracking this down by inserting a large number of
printf() calls in the Fl_cocoa.mm startup code until I tracked down the cause. It appears that the root cause of that warning message is this line of code near the top of fl_open_display():
[NSApp finishLaunching];
If I comment out that line of code, then the program starts up and no warning messages are generated. In fact, I can revert the second cocoa patch and still not get warnings if that line of code is commented out. Let me know what you want to try next. I didn't exercise the program thoroughly to see if commenting out that line of code had significant adverse effects, but it seemed to run normally when I was playing with it briefly. | |
| |
| #15 | manolo
01:34 Apr 01, 2011 |
| John,
Please try the last svn version (r.8551) that hopefully will
close this STR. | |
| |
| #16 | johns.ks.uiuc
15:38 Apr 01, 2011 |
| Manolo,
So far, this appears to work pretty well. I will test it thoroughly next Monday and Tuesday, but assuming no problems crop up, then I think we will be able to close this STR.
Cheers,
John Stone | |
| |
| #17 | manolo
23:35 Apr 08, 2011 |
| John reported (offline) that his tests revealed no other
problem in the FLTK/Tk interaction.
Thus I close this STR. | |
[ Return to Bugs & Features ]
|
| |
