On May 11, 2010, at 12:58 AM, Thomas Adam wrote: > On 11 May 2010 00:34, Omar Zakaria <[email protected]> wrote: >> Hey everyone. I'm seeing a strange problem with FVWM v2.5.27. I'm >> not sure if it's a bug or some odd configuration on my end or what, >> but I'd appreciate some help all the same. > > Use 2.5.30, please.
Thanks for getting back to me so quickly, Tom. Just compiled and installed it now. I'm afraid there's no change. Actually, I now have to kill the program twice before I can open windows correctly. I just went back and confirmed that this has always been the case: On first launch, I only get to the app's splash screen before it hangs. On the second launch, I get to the app's main window, and on the third launch, I can use the app freely. > >> So, I've got 2.5.27 installed on a Redhat EL5.5 machine and in >> general, it seems to work fine. We also have installed on the >> machine an in-house Smalltalk app that runs using Cincom >> Visualworks 7. When we open the app, the first window >> appears just fine, but if we try to open any other of the >> application's windows, the whole thing freezes, the new window >> does not appear, and we have to forcibly kill the process. Then, >> even stranger, the next time we load up the app, everything >> works fine and we can open as many windows are our hearts >> desire. But, when we reboot, log out, or otherwise end our login >> session, we have to repeat the process over again (i.e. launch >> the app, close it, and launch it again before we can actually use >> it.) > > What is this program written in? Smalltalk you say? Yes. In case you're not familiar with it, it's a language that runs in a VM. The premise behind it is very similar to how Java works: you have to provide the VM with an image file -- the Smalltalk equivalent of java's jar files -- which the user creates. The VM then executes the image file. We use Cincom's VisualWorks VM version 7.3. > >> I launched the smalltalk app in gdb and found that it was hanging >> in an Xlib call: XPeekIfEvent(). I can't really introspect it more than >> that, I'm afraid. Strangely, when I launched the app in gdb again >> afterwards (the second time, so everything should be cool) and >> asked it to break on an XPeekIfEvent() call, I found that no such >> call was made. > > Can you get a proper stack trace, please? Aye aye. I'm afraid it's not particularly helpful, but here it is: #0 0xb7f72402 in __kernel_vsyscall () #1 0x008a088d in ___newselect_nocancel () from /lib/libc.so.6 #2 0x009861d5 in ?? () from /usr/lib/libxcb.so.1 #3 0x00987bac in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #4 0x009e58f1 in ?? () from /usr/lib/libX11.so.6 #5 0x009e5c17 in ?? () from /usr/lib/libX11.so.6 #6 0x009cf5ee in XPeekIfEvent () from /usr/lib/libX11.so.6 #7 0x080cf438 in ?? () #8 0x099b0ba0 in ?? () #9 0xbf928900 in ?? () #10 0x080cf360 in ?? () #11 0xbf928984 in ?? () #12 0x00000000 in ?? () I suppose it could be our version of libX11 that's problematic... we're using libX11 from an rpm: libX11-1.1.3-4.el5. > >> Does anyone have any ideas as to what's going on or whether >> this is indeed a bug? > > Is there a way for me to get ahold of this application so I can see if > I can reproduce it myself? Or can you find some other application > which does the same thing? It could be *anything* at this point -- > maybe some of the windows are still in the Withdrawn state when > they're mapped, etc.,e tc., but that's just pure speculation, and I've > no way of verifying that. I'll see if I can get authorization to send you the image. You might first download the Cincom VisualWorks VM. Like I said, we're using v7.3.1. I think you can download that particular version from here: http://cincomsmalltalk.com/scripts/DownloadCD.ssp. I'll see about getting something else to act the same way. At the very least, I might be able to whip up a simple Smalltalk app that does the same thing. Thanks again. -- Omar Zakaria Agilent Technologies W: 707-577-4214
