bugGNUstep - Bugs: bug #21571, Giant blank app-windows under IceWM


bug #21571: Giant blank app-windows under IceWM

Submitter:  Ingolf Jandt <ingolf>
Submitted:  Tue 13 Nov 2007 03:33:37 PM UTC
Category:  Backend Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  FredKiefer
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Fri 07 Mar 2008 11:53:56 PM UTC, comment #18: 

Closed as this is reported to be fixed.

Fred Kiefer <FredKiefer>
Project Member
Fri 07 Mar 2008 01:22:42 PM UTC, comment #17: 

Ok, from the looks of it, the original fix DID work.

Kargor <kargor>
Fri 07 Mar 2008 10:52:54 AM UTC, comment #16: 

Hm... I have a 64 bit Debian at home, but none of the X-servers from them is working (xvfb crashes just about every application, and xorg doesn't like my Intel G965 chipset). And I can't install icewm on Xming :-)

I'm using a 32 bit Debian as development VM right now, which does show the problem when I use IceWM. Works fine with Gnome and KDE, haven't tried with anything else.

I might, however, qualify for the most stupid idiot reward. I had problems getting the new patch to work (the svn checkout doesn't compile for me, so I'm adding patches to a 19.2 startup archive during the build). I didn't get the new patch to work, so I added compiletime errors to see if it breaks the build, which it didn't. So I removed the new patch, added a compiletime error to the previous one... and it still builds.

So right now I'm back to the drawing board trying to figure out what works and what doesn't.

Kargor <kargor>
Thu 06 Mar 2008 06:23:39 PM UTC, comment #15: 

For what it's worth ... I'm running debian 64bit intel and have just downloaded the icewm package and installed it.
I don't see the described problems running gnustep apps under icewm... everything appears fine.
This is with version 1.2.27 of IceWM dated August 6th 2006

Richard Frith-Macdonald <CaS>
Project Member
Thu 06 Mar 2008 05:53:20 PM UTC, comment #14: 

Thank you for your feedback.

Again the values have wrapped around. We need to find out how this could happen.
Could you please replace the line 1058 in XGServerWindow.m with the following:

          if (r < window->xframe.size.width + l)
              NSLog(@"Invalid border values r = %d l = %d b = %d t = %t rep.x = %d rep.y = %d w = %g h =%g", r, b, t, repx, repy, window->xframe.size.width,  window->xframe.size.height);
              r = 0;
              r -= (window->xframe.size.width + l);

You could do something similar with the next line, but for now I am only interested in the results printed, not the workaround itself. As my machine doesn't reach this code, it is untested. I may have gotten the type of some of the variables wrong.

Fred Kiefer <FredKiefer>
Project Member
Thu 06 Mar 2008 11:08:34 AM UTC, comment #13: 

Now, that's a simple job :-)

stieber@debian:~/MacOS> xprop -root _GNUSTEP_FRAME_OFFSETS
_GNUSTEP_FRAME_OFFSETS(CARDINAL) = 2, 65534, 22, 65514, 2, 65534, 22, 65514, 2, 65534, 22, 65514, 2, 65534, 22, 65514, 2, 65534, 22, 65514, 2, 65534, 22, 65514, 2, 65534, 22, 65514, 4, 65532, 24, 65512, 4, 65532, 24, 65512, 4, 65532, 24, 65512, 4, 65532, 24, 65512, 4, 65532, 24, 65512, 4, 65532, 24, 65512, 4, 65532, 24, 65512, 4, 65532, 24, 65512

Also, if it helps, this is for the window that I screenshotted:

stieber@debian:~/MacOS> xwininfo

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0xc00055 "Contacts"

  Absolute upper-left X:  289
  Absolute upper-left Y:  241
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 450
  Height: 330
  Depth: 24
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0xc00001 (not installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +289+241  -285+241  -285-197  +289-197
  -geometry 450x330+287+219

Kargor <kargor>
Wed 05 Mar 2008 05:46:57 PM UTC, comment #12: 

I reopened this case as some errors still persist.

Could you please report the values that get stored on the root window for the property _GNUSTEP_FRAME_OFFSETS?

Fred Kiefer <FredKiefer>
Project Member
Tue 04 Mar 2008 03:46:03 PM UTC, comment #11: 

Ok, here we go. I was able to locate the patch, applied it to the 0.19.2 "startup" archive. Cleaned out everything, made sure the source is current etc.

So, so it works a bit better. I removed the properties from the root window, started the app and called up one of the decorated windows. No more huge white empty window.

It's still not correct, though. Unless I completely messed up and still have some old testing stuff in the code that I can't find anymore, let me show you the same window on MacOS (Cocoa) and Linux (GNUstep, with IceWM):


They both come out at almost the same size, but the Linux window is clipped off at the bottom, and maybe the black border at the right side isn't entirely intentional either.

Note that this is the same code, so it's not just a matter of making the NSView larger. I hope :-) There's the occasional #ifdef LINUX and #ifdef APPLE, but...

And last but not least, even with your patch, it has exactly the same problem that I had when I played with the XGServerWindow.m code: after quitting the application and starting again, I'm back at negative values and huge white empty windows. Which wouldn't be a major problem, as I could just system() the xprop remove, but that's probably not the intended way, and it causes that ugly window flashing at startup...

Kargor <kargor>
Tue 04 Mar 2008 11:22:26 AM UTC, comment #10: 

I can't seem to build off an svn checkout, and since compile-all uses configure it's next to impossible to even guess what the problem might be.

I guess when I find the time I'll try to find the changes in the svn repository. My application build includes a script that can patch and build a gnustep-startup-*tar.gz package...

Kargor <kargor>
Tue 26 Feb 2008 12:36:40 AM UTC, comment #9: 

I just put some code into SVN that looks correcter. I don't have a window manager old enought to test this code. Could you please do this and report the result back?

Thank you.

Fred Kiefer <FredKiefer>
Project Member
Fri 15 Feb 2008 12:06:02 AM UTC, comment #8: 

Thank you for your in depth analysis of this problem. To me it seems that there are multiple issues that come together. I would say that the code in the loop that does the l, t, r, b computiation is wrong. It should only take the wattr.x and wattr.y values into account for the next lower window, not for the current one. These values give the postion of the window relative to its parent, so we should only use them, when the width, heigth also refer to the parent.
But this still does not explain your issue. For you it seems as it the loop is stopped after the first parent, although we are rather sure there should be at least two. Why does this happen?

I hope to find time to play with this code over the next few days, still I would need somebody to test any change, as I cannot reproduce the problem.

Fred Kiefer <FredKiefer>
Project Member
Mon 11 Feb 2008 01:59:27 PM UTC, comment #7: 

It's probably not an IceWM problem as in "IceWM bug" since other programs work fine, just GNUStep messes up. And only with decorated windows, so that's always a workaround-option :-)

I've been working on this for 2 days already; finally found the time to figure out the Windowmanager and found this bug report right away :-) So at least the problem is known already. I switched my development-VM over to IceWM now, because...

The problem for me is that the Asus eeePC comes with IceWM preconfigured, which means my GNUStep based stuff doesn't work properly on that box :-( Still haven't figured out what the problem is, though... I see the place where the border size values are trashed, but I can't make out the reason since it works with other window managers.

In _checkStyle, we finally get to line 999 in XGServerWindow.m,
and go into the "special double parent" case (ReparentNotify
gave 0/0).
Upon entry, the r/b/l/t are all 0, and wattr is x=4 y=30 width=100 height=100.
After the first run through the loop it's l=4 r=100 t=30 b=100, wattr unchanged.
The loop terminates, and we get negative offsets.

The problem for me is that I don't know what things are supposed to look like --- I've never worked with X11 on that level. My guess is that it's a misunderstanding --- the values given above suggest that 'r' and 'b' are not offsets or coordinates but the window size, so the subtraction a bit later screws up. But I guess I'll have to play around with this a bit longer... seems you people don't have a fix yet :-(

I tried a little quick hack --- if r is negative, make it the same as l; if b is negative, make it the same as l (not t, because that includes the title bar). It helped a bit, but not much --- now the window clipping is wrong (clips off the bottom "t" pixels, estimated from the looks of it), and apparently does the same on the right but that's just a few pixels, and it still stores the 65K values into the root window property.

Kargor <kargor>
Wed 09 Jan 2008 07:08:45 PM UTC, comment #6: 

Are you sure this is an IceWM problem? Are you maybe using 16 bit window depth? I'm using WindowMaker with 16 bit depth (very old laptop who can't do better), and with both cairo and art backends I have the very same problem, huge blank windows, all GNUstep applications are unusable. Previous versions of all software ran on this laptop flawlessly for years. Using the current Debian unstable packages (gnustep-back 0.12.0-1 packages).

I don't know whether this is directly related to this bug, or to #21203, or to #20965. Looks all very similar to me. Sorry if I'm at the wrong place here.

Viktor Horvath <cato_minor>
Fri 04 Jan 2008 09:46:47 PM UTC, comment #5: 

Could you please re-run your application on that window manager with the parameter  --GNU-Debug=Offset  and report back the results? And after you run the first GNUstep program could you also report the result of

I f you don't get any exta output for the application call you may remove the stored values via
xprop -root -remove _GNUSTEP_FRAME_OFFSETS                                

Fred Kiefer <FredKiefer>
Project Member
Fri 30 Nov 2007 08:01:35 PM UTC, comment #4: 

style = 15 means NSTitledWindowMask | NSClosableWindowMask | NSMiniaturizableWindowMask | NSResizableWindowMask
that is a normal window with a title frame.
I still need to find the place where we treat these values as signed numbers, they should all be unsigned and would then be fine.

Fred Kiefer <FredKiefer>
Project Member
Wed 14 Nov 2007 12:32:54 PM UTC, comment #3: 

in seams whenever style=15 the result in line 2239 is
r=-32768, l=6, t=24, b=-32768
otherwise all 0.

Ingolf Jandt <ingolf>
Wed 14 Nov 2007 11:51:53 AM UTC, comment #2: 

Hope debug.log gives you the answer you need.

BTW when window coordinates are already in the defaults (app ran in an other WM before), the error does not happen -- you may have guessed that. But then the window is clipped wrong. I will send another screenshot when I have created that situation again.

(file #14389)

Ingolf Jandt <ingolf>
Wed 14 Nov 2007 09:16:49 AM UTC, comment #1: 

From the log file I would say that something goes horribly wrong in the way the window border sizes get computed. The window ends up with a negative size and at some point this negative number is taken as a huge positive one and your giant window is requested from X11. This step of course fails.

What we have to do now, is find the place, where the negative number gets treated as a positive one. This surely is a GNUstep bug.
And we have to find out, why a negative frame size gets reported by the backend. Here the interaction with the window manager seems to fail. As I don't think I have IceWM installed, would it be to much to ask you to debug into this?
The interesting bit is the styleoffsets::::::: method in XGServerWindow.m. Here a lot of completely different ways to get the window border sizes are implemented. Depending on what the WM supports, one of them gets called. It would be interesting to know, which one this is for IceWM and why it fails.
I promisse to look into the other part of the problem.

Fred Kiefer <FredKiefer>
Project Member
Tue 13 Nov 2007 03:33:37 PM UTC, original submission:  

When trying to run a gnustep app under IceWM the menu is displayed correctly, but other windows are
'giant' (I did not find a right or bottom edge so far inspite of shifting it up and left a lot)
and blank (blank possibly because of failing memory allocation).

Ubuntu GG, gcc 4.1, IceWM 1.2.30
-gui/-back 0.13, -base 1.15.1
backend: both -art and -cairo

(description of log output coming soon when i have access to it)

As this seems icewm specific, maybe you do not see it as a gnustep-bug. But as all other X-based apps work fine under ice, this is at least percieved as a gnustep-problem -- And it conflicts a little with the "... deploy everywhere" thesis ;-)

Ingolf Jandt <ingolf>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #14389:  debug.log added by ingolf (6KiB - text/x-log)
file #14386:  screenshot.png added by ingolf (41KiB - image/png)
file #14387:  openapp_Terminal.log added by ingolf (1KiB - text/x-log)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by kargor (Posted a comment)
  • -email is unavailable- added by cato_minor (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by ingolf (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.





    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-03-07 FredKiefer StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2008-03-05 FredKiefer StatusReady For Test In Progress
        Open/ClosedIn Test Open
    2008-02-26 FredKiefer StatusNone Ready For Test
        Open/ClosedOpen In Test
    2008-01-04 FredKiefer CategoryGui/AppKit Backend
        Assigned toNone FredKiefer
    2007-11-14 ingolf Attached File- Added debug.log, #14389
    2007-11-14 ingolf Attached File- Added screenshot.png, #14386
        Attached File- Added openapp_Terminal.log, #14387

    Back to the top

    Powered by Savane 3.9